Okay... I dont mean to start a flame war or anything, this is just a curious question. See.. I''ve built several engines in the past, ranging for q3 map loading engines, to height-mapped terrain engines e.t.c.... some in OOP, and others in a more C style. I''ve been working on my latest engine for a week now, have various model support in (3ds, md3, md2, mdl, ase) and basic sound support (wav, midi). e.t.c Its a very clean codebase e.t.c (had some stupid bugs along the way)... but even though it''s clean and well made, I''m thinking of rewriting it to try and get performance increase and hopefully even cleaner code. (seeing as it''s only rewriting a weeks work). I''m just wondering... when I rewrite this, should I write it in C style again, or in OOP form. (which I use in my engine anyway for certain things such as model loading). Just wanted to get a few peoples opinions on it before I go and restart. I''m looking for maximum performance here, as this engine has to surpass all of my old ones (and I''ll be laying the effects in a nice thick layer in this :D , its intended for machines in about 2 years from now.), gonna start working on a full game on it. e.t.c e.t.c Just really wanted to grab a few peoples opinions on whether I should stick to my more-used C form or make the entire engine OOP. Look forward to reading your opinions. ~Cobra~

I think you should mix both styles. Some parts are easier to handle with objects (real game objects like models, etc.) while others are easier with simple functions and modules. I played a lot with these ideas and now it seems to me that the best way is to avoid the "wrapper mania" but still use classes to avoid playing with hand-made this pointers...

alexk7@alexk7.com

I believe that when your project starts growing larger it really pays off to have it OOP. It makes it a lott more easy to read for yourself and for others. You don't have to work yourself through dozens of (global) functions to see the general program flow (if OOP is used corectly).
Might I suggest the book at relisoft: www.relisoft.com/book , it really changed my way of programming in c++, although I'm still reading it .

Edited by - shabaz on February 6, 2002 1:43:01 PM

Thx for the replies thus far.. just to let you guys know, this is how the engine currently is.

Main code, initialising window e.t.c e.t.c is all done in C
BMP loading all done in C.
Wav and Midi sound handling all done in C (yes I know wav doesnt need anything but a lib linked in, but I wanted to pass it through the sound system in the engine and have each bit logged e.t.c so I wrote my own functions for it).
All model loading code is OOP
TGA loading code is C.
Controls e.t.c are all done in the main window code (such as in Nehe's. they arent held within a seperate OOP based function (I've actually seen this done b4.. not sure why they bothered))
Map loading code WILL be OOP.
All font-based stuff e.t.c is done in C

So basically I'm struggling on whether to keep it as it is (mixed) or move it all to OOP.

Anyway.. keep the replies coming, this stuff is all useful.
(btw.. Shabaz, thx for the link, I'm giving it a look through at the moment, its funny that a lot of the techniques ID-Software used in their code layout e.t.c are defined as "bad" in this hehe)

Edited by - Cobra on February 6, 2002 1:43:22 PM

It''ll also depend on what you''re comfortable with. If you''re not used to thinking in OO on larger projects and designing systems with this approach, you''ll probably end up making a bit of a hash of it at your first couple of attempts and end up with a poor OO model with lots of inter-class coupling and dependencies and possibly slow code.
If straight C is your strong point, then you can do a pretty good approximation of OO in C by using static functions and variables (encapsulation) and only prototyping the functions you want others to use in your header files. OK, granted you don''t get polymorphism, but writing clearly defined C modules with clearly defined interfaces is still a good thing.

You''ve already spent time developing a codebase, review it, and if you think it will scale with your project, go with it as is for now.

Just my $0.02 ...



Slightly shrimpy smell == unsafe breadbin

In terms of pure speed, C code will sometimes be faster, depending on how you handle it. But I find OOP far neater. To make my code "clean", I use OOP. I use basically pure OOP for my latest project Literally zero global functions (besides WndProc and WinMain of course).

One interesting thing people rarely take note of is that nearly everyone prefers the syntax of OpenGL to that of Direct3D, and Direct3D is object-oriented whereas OpenGL is procedural. So the OOP approach is not necessarily the cleanest. Of course, the actual OpenGL code must be messy as hell, I''m sure, but the interface itself is very neat. But with OpenGL, you aren''t exposed to any variables at all, and that''s what makes it clean-looking.

~CGameProgrammer( );