[Seiko]

Guys, I'm switching over from VB/.Net to VC++ and wanted some general opinions on what most people prefer in terms of general approach for game programming in terms of class usage etc. I've never really enjoyed the OO approach for games as I think it can often limit a design and end up requiring more code. In short how are people splitting the use of classes and general generic functions etc? I appreciate this is a little vague but the whole argument for and against OO is huge but hopefully limiting to what styles people are using for games I'll be able to garner a safe direction. Of course I'll tailor this as I progress but I'm very reluctant to start creating millions of classes and methods etc as opposed to a few well chosen generic gaming functions?

Look forward to the comments?

[Ostsol]

My own framework is almost totally object oriented. I find that it makes it easier to keep the engine versatile. I do have a bunch of stand-alone functions linked through their declarations in header files, but these are for -really- generic things such as text file reading and vector/matrix math.

[NeARAZ]

I'd say it's best to do whatever comes out the best Really, it's up to you (and those who are working with you, or who'll be using your code) - what's convenient and what's not. I've seen really bad "OOP" code and really good "procedural" code (and vice versa, ditto with "generic" (C++ templates) code).
Good code design can be done using any of the programming techniques, be it OOP, procedural, generic or functional. Good design also comes with experience, so it's better not to try do uber-design when you really don't know what that is... It will all come with time (or won't come)...
On ZillionsOfClasses vs. FewGoodFunctions - nothing forces you to do zillions of classes - few good classes are better than zillions

[Seiko]

Thanks guys, thats sound advice. I kind of aimed this question in the wrong area really as I should have clearly illistrated as to where the classes would be used. i.e. game entities etc. Anyway, thanks for the responses. OOB is appears fine for the mechanics of the game although the dereferencing is a pain but as for he entities data models etc I think I'll stick with regular data arrays and lists etc.

[Chalnoth]

Well, if you want an example of how OOP is used in one game engine, you can take a look at the scripting in any of the Unreal-engined games.

[Dio]

I'd give one definite recommendation: implicit new and delete are the bane of efficient games code. You can read most issues of Game Developer and find 'good memory management' or 'bad memory management' on one of the two sides of the postmortem.

[Chalnoth]

Originally Posted by Dio

I'd give one definite recommendation: implicit new and delete are the bane of efficient games code.

Just curious what you mean by that, specifically.

Do you mean not making proper destructors and constructors? Or using, for example:

Vector v1;

instead of:

Vector* v1 = new Vector();

[darkblu]

Originally Posted by Chalnoth

Just curious what you mean by that, specifically.

Do you mean not making proper destructors and constructors? Or using, for example:

Vector v1;

instead of:

Vector* v1 = new Vector();

i believe what Dio means (and what is a common sense among gamedevs) is that you should not use the generic CRT heap allocation/deallocation mechanism dully every time you need something on the heap, since the CRT is just that - generic. point is you know your data and structures to a point where you can efficiently apply some heuristics whereas the CRT is deprived of such knowledge. point being you must pick the best suitable container that would most efficiently handle your data in terms of both allocation and access.

ps: of course you can add to the above the necessity to pay tibute to the hw caching mechanisms and stuff.

[Chalnoth]

So, are you talking about storing data in byte arrays, using custom memory management techniques?

[darkblu]

Originally Posted by Chalnoth

So, are you talking about storing data in byte arrays, using custom memory management techniques?

includingly, but not only. a blatantly obvious example would be vertex arrays - you never allocate vertices on the heap on a one-by-one basis, and you almost always use an empty default constuctor (in OOP, that is).

maybe first to bring some basis in; data can be generally classified into two categories:

• uniform data (generally any kind of massively-instantiated classes, e.g. vertices)
• non-uniform data

where those two categories are subjects to entirely-different allocation/instantiation tactics.

whereas the latter category in the most abstract case can be considerd as exhibiting 'gaussian' distribution from the perspective of a memory allocation scheme, and is best left to the care of the general CRT allocation scheme (which as a rule is tailored exactly for that - to find space on the heap for arbitrary data, which can be carried out only so quick), the former category exhibits 'patternisation', thus is susceptible to 'statistically smart' allocation/instantiation schemes (at design time, that is). the criteria for a 'smart' allocation scheme when targeting performance are: minimal maintenance overhead (i.e. allocation and/or deallocation, depending on what are the needs) and access-friendly placement (i.e. cache- and/or busses-friendly -- here usually pops up the question of array-of-structures vs. structure-or-arrays, when arrays are used, that is)
..doh, i feel i'm drifting away in CS basics. ok, to conlcude with something more on the practical side of things, in OOP one must always think of instantiation as a two-fold process - allocation and initialisation -- both of those are subject to tailoring for each specific class and purpose at hand.

[Snyder]

This probably won't apply to something as "low-level" as 3D programming (especially because the shown examples will mainly use non-uniform data, I guess), but renowned German computer magazine c't has started an interesting article series about performance comparison between C++ and managed languages (Java and C#) in their latest issue. While the first part only compared simple constructs and programs (and showed that Java and C# lose by a surprisingly low margin), they promised a surprise for the next issue when they will compare a more complex piece of software (using lots of dynamic allocation, complex object hierarchy etc. etc.).

Sorry if this is offtopic.