Hi.
I'm working on a small game project on sourceforge called Spindizzy, which is a remake of the 80s game of the same name. Part of the project is developing the game engine, called the DizzyEngine.
The engine has been designed to be platform indepenant, i.e. the same game code could compile into a PC game or PSP game, by linking with the PC or PSP port of the engine. The engine and game is written in c++ and making heavy use of of OOP in its design.
The game, Spindizzy, itself would be an ideal PSP game, but I would like the game engine to be ported to as many platforms as possible, including PSP and PS2.
The code currently is at a very VERY early stage with only a simple 3d engine running (which also means that getting a new port of the engine up to speed with the specs should be quick). If you wish to participate in the project, a windows installation with Visual Studio 2005 b2 would be helpful, as the current code is written in that tool.
http://www.sourceforge.net/projects/spindizzy
Code and documentation can be obtained from pserver cvs access at
cvs.sourceforge.net/cvsroot/spindizzy
Code is in the module "Dizzy". Docs (on docbook format) in the module "docs".
If you wish to help, reply to this or msg me through sourceforge https://sourceforge.net/sendmessage.php?touser=1335721
C++ and OOP knowledge required.
Regards,
Pete
Help wanted for multi-platform game engine
Moderator: cheriff
-
peterstroeiman
- Posts: 11
- Joined: Fri Sep 16, 2005 3:18 am
- Contact:
"heavy use of of OOP" is generally a bad thing for console games
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
I was going to cite that templates can be horrible, but I suppose thats not OOP exactly, though it does seem to be that code that heavily uses OOP tends to heavily use templates as well, but that may be a skewed observation from the particular OOP stuff I've gone through.mrbrown wrote:Can you please cite specific examples?Drakonite wrote:"heavy use of of OOP" is generally a bad thing for console games
I seem to recall virtual methods can be quite bad at times, if thats a good enough example for you.
Funny thing, I seem to recall you listing off 4 or 5 things in c++ that were quite horrible on the psp compilers.
I suppose part of the issue is that I may see something different in my head in reference to "heavy use of OOP" than what you do because I've been around bad c++ coders far too much.
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
I used to be anti-C++ (especially for PS2 and PSP), but that was because I hadn't used C++ enough.
It's true that virtual methods can be detrimental to CPUs with crappy instruction caches, but that can be minimized depending on what you're doing. You usually use virtual methods when you really need an abstract base class (for example GameObject).
Templates are good in a lot of specific cases, and bad in others. The problem with templates comes from templated member functions that can't be inlined, so if the template gets a lot of use over different classes this can lead to a lot of code bloat. If you're smart about inlining your template methods, they can be a big win. We've mostly used them for memory allocators.
The STL that ships with GCC is probably one of the worst implementations around. I have no idea why it's so crappy, but it just is. If you're going to be using STL on PS2 or PSP, it had better be STLport.
If you don't go overboard and start trying to do obscure crap like template metaprogramming (or whatever is hot this week), pay close attention to the code generated by templated classes, and limit your use of virtual methods you should be sitting pretty.
I wrote a sound driver for the IOP in pure C++. I didn't use any classes, no new or delete, and no inheritence - instead all of the "OO" bits were just structs with member functions. The compiled code was equivalent to something you would write in C if you were passing around a struct pointer as the first argument to each function (see GTK+). But I had the convenience of C++'s typing and syntax. It made things go a lot smoother.
It's true that virtual methods can be detrimental to CPUs with crappy instruction caches, but that can be minimized depending on what you're doing. You usually use virtual methods when you really need an abstract base class (for example GameObject).
Templates are good in a lot of specific cases, and bad in others. The problem with templates comes from templated member functions that can't be inlined, so if the template gets a lot of use over different classes this can lead to a lot of code bloat. If you're smart about inlining your template methods, they can be a big win. We've mostly used them for memory allocators.
The STL that ships with GCC is probably one of the worst implementations around. I have no idea why it's so crappy, but it just is. If you're going to be using STL on PS2 or PSP, it had better be STLport.
If you don't go overboard and start trying to do obscure crap like template metaprogramming (or whatever is hot this week), pay close attention to the code generated by templated classes, and limit your use of virtual methods you should be sitting pretty.
I wrote a sound driver for the IOP in pure C++. I didn't use any classes, no new or delete, and no inheritence - instead all of the "OO" bits were just structs with member functions. The compiled code was equivalent to something you would write in C if you were passing around a struct pointer as the first argument to each function (see GTK+). But I had the convenience of C++'s typing and syntax. It made things go a lot smoother.
well... isn't gtk+ is one of the examples what happens if you take the theoretical concepts too serious? Common stack depths well over 100 function calls and minimum binary sizes in the megabyte range due to interdependencies aren't really convincing in a psp-alike environment...
For sure you can code in C++ just for the convinience of typechecking, but some languages make it much easier to obscure what the compiler will actually generate out of the code you wrote.
peterstroeiman: If you build your game engine on portable libraries like OpenGL/GLUT and the POSIX/ANSI libc, you don't need to spend much time writing platform-specific backend code. Both can be very small in code size, if you link only the parts you really need, some 100k binary size should in most cases be possible (right now pspgl is about 35k, a typical simple demo application less than 100k including data).
For sure you can code in C++ just for the convinience of typechecking, but some languages make it much easier to obscure what the compiler will actually generate out of the code you wrote.
peterstroeiman: If you build your game engine on portable libraries like OpenGL/GLUT and the POSIX/ANSI libc, you don't need to spend much time writing platform-specific backend code. Both can be very small in code size, if you link only the parts you really need, some 100k binary size should in most cases be possible (right now pspgl is about 35k, a typical simple demo application less than 100k including data).
Wow, I didn't know GTK+ had hurt you so bad :). I was referring to passing structs around to simulate classes, and GTK+ is one of the more prominent examples of doing this in C, which is why I mentioned it. I would never advocate using GTK+ for anything embedded (or anything at all really, use wxWidgets for cross-platform GUI dev :P). GTK+'s bloat doesn't come from using a struct as the first function argument - that gives much better codegen (and locality of reference) than using global variables.holger wrote:well... isn't gtk+ is one of the examples what happens if you take the theoretical concepts too serious? Common stack depths well over 100 function calls and minimum binary sizes in the megabyte range due to interdependencies aren't really convincing in a psp-alike environment...
well... gtk+ and other approaches of OOP-in-non-oop-languages are just forcing you to write down what otherwise the compiler would autogenerate for you, so these approaches are actually a good case-study of some academical (mis?-)conceptions; and I honestly recommend everyone to take a closer look on this code, even if only for learning from other's mistakes. But it hurts to see talented beginners to repeat the same, mostly religious fought fruitless discourses like the generations before... but maybe that's just like the world works.
(if I have the choice between wasting resources for some opaque object and type checking runtime system, or for some nice and detailed pictures and textures, audio/video tracks encoded at higher bitrate - well... I think you know how I would decide ;)
(if I have the choice between wasting resources for some opaque object and type checking runtime system, or for some nice and detailed pictures and textures, audio/video tracks encoded at higher bitrate - well... I think you know how I would decide ;)
-
peterstroeiman
- Posts: 11
- Joined: Fri Sep 16, 2005 3:18 am
- Contact:
well... I've been occupied for a bit, and now the thread became a bit off-topic :)
By using OOP I mean abstract class inheritance is used to create abstractions. E.g. I have defined a Model. The model is a container of geometrical data. You can ask a model to render on the screen. A windows implementation would have a WindowsModel. A ps2 implementation would have a PS2Model etc.
Maybe calling it "heavy use of OOP" is a bit of an exageration.
Of course, using OpenGL would help out a lot in that department because it is implemented on virtually every platform. But then there is sound, and input.
Regarding templates, I use templates for two things: smart pointers, and type-safe collections.
Class abstractions are also using in building up a scene hierarchy.
I know that calling virtual functions has an overhead, and maybe a flatter API could perform better. But I'm not trying to build Doom4 or MGS4.
Instead I focus on making the engine, so that the game code can be as simple, easy to understand, and easy to port, as possible.
By using OOP I mean abstract class inheritance is used to create abstractions. E.g. I have defined a Model. The model is a container of geometrical data. You can ask a model to render on the screen. A windows implementation would have a WindowsModel. A ps2 implementation would have a PS2Model etc.
Maybe calling it "heavy use of OOP" is a bit of an exageration.
Of course, using OpenGL would help out a lot in that department because it is implemented on virtually every platform. But then there is sound, and input.
Regarding templates, I use templates for two things: smart pointers, and type-safe collections.
Class abstractions are also using in building up a scene hierarchy.
I know that calling virtual functions has an overhead, and maybe a flatter API could perform better. But I'm not trying to build Doom4 or MGS4.
Instead I focus on making the engine, so that the game code can be as simple, easy to understand, and easy to port, as possible.
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
Typically when people do this (at least in pure C) they will write something like DrawPixel(x, y); and DrawPixel is in something like BaseGraphics.h (possibly an inline function or macro) and the file changes with each differant platform. I've never heard of anyone using templates for cross-platform code. Although I'd like to see an example of how that would work (and still compile).
w00t
-
peterstroeiman
- Posts: 11
- Joined: Fri Sep 16, 2005 3:18 am
- Contact:
It's not the templates that are the base of cross-platform code. The templates are just helper classes, e.g. smart pointers.ChaosKnight wrote:... I've never heard of anyone using templates for cross-platform code. Although I'd like to see an example of how that would work (and still compile).
It's the class hierarchy that provide the base foundation for platform independance
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
Sounds overly complicated. But that's just my opinion. In my experiance the more complicated it sounds the worse it is to manage and pick up. OpenGL has been around for so long because it is really simple. Most concepts convert easily to code, so if you read a book talking about points and texture coordinates and the like glPoint and glTexCoord make a lot of sense, and more than that they are not complicated.
Again, just my humble opinion. Take it with a grain of salt.
Again, just my humble opinion. Take it with a grain of salt.
w00t