Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

The 5millionth post on OO design principles..

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
52 replies to this topic

#21 Houdini   Members   


Posted 14 December 2000 - 08:39 AM

Original post by bogdanontanu


Take care with OOP in games...

OOP may be efficient for the programmers point of view ...but is
awensome slow so totaly ineficient for speed whatsoever...

A good game can be done with no OOP whatsoever...(besides menu systems) so use OOP wisely and only in no speed critical sections...

IMHO of course

Actually many games are written in C++ using OOP and they are very fast. Ones that I know of off hand are Unreal Tournament, Age of Empire, and Age of Kings. id Software''s next game will also be using OOP (except for the graphics engine).

- Houdini

#22 Kylotan   Moderators   


Posted 14 December 2000 - 09:26 AM

Not only is Unreal Tournament OOP, I believe it is even largely interpreted OOP. (UnrealScript compiled down to bytecode, unless I''m much mistaken.) As with any design methodology, you must know the pros and cons, that''s all. And as already mentioned, the profiler is your friend (if you can get hold of one).

#23 pax   Members   


Posted 14 December 2000 - 09:48 AM

Compiler technology has progressed to the point that OO code is NOT SLOWER THAN NORMAL CODE!!! This is a myth kept alive mostly by older game programmers (who would lead you to believe that hand-crafted assembly is the fastest, which is not always the case). Get rid of that idea.


#24 dwarfsoft   Members   


Posted 14 December 2000 - 11:11 PM

I think that the only reason that people argue that OO code is slower for them is because they aren''t using it right... That is all I think I need to say about that

-Chris Bennett of Dwarfsoft - Site:"The Philosophers'' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche


#25 Marcel   Members   


Posted 19 December 2000 - 07:19 AM

OO slower bla bla
I''ve been hearing it for years and from a low level it''s true.
But I like to bring up a few piont that are differnt
OO lets you raise the language to higher plane
this has obviously drawbacks because it''s less exact but more portable.
For example imagine a bike.
Do you think about 2 wheels a steer etc?
Well that''s your implementation of it I may think about 2 floaters and a steer. But that bike idea is portable.
My implementation my seem a little crasy but in waterworld it might be beter.
Mainly it comes down to interface. The consept of a bike is a man driven verhicle. Ofcourse you have to try things out instead of assume that it''s the normal bike and in some cases that may slow things down. If it means you can ride any bike instead of only racing bikes real fast it might be worth it.
A high level optimalisation for the bike would be taking the bus.
It would have gotten you much faster than your speedy bike
but you didn''t see it because you where glued to it.

The flyweight pattern and the lazy and eager evaluation tricks(effective C++) are examples of design level optimalisations that far outway the assembly prodding.
A twist to the famous 80 20 rule is that without design you have an 80% chance that your optimising in the 80% that gets seldom used giving only 20% of the benefits.

It''s managament and decent managament may give you a much beter product.
It''s not for nothing that strategic desicion makers get paided lots. And what else is programming than making choises?

In the end it comes down to:
Put the things together that belong together
Put the things that don''t belong together appart
and make a seperate thing of a part that gets used by multiple things.

(the last fits different object levels and Aspect Oriented Programming)

By the way this may seam a bit hazy but hasyness is a quality of high level design. It confines only what needs to be confined the rest is left to the creativety of lower levels.

Comme to think. If you want to program humans you have to be vage. Check out Neuro Languistic Programming (NLP) or other psygology for that.
Not that you should use people as computers, but knowing there interface might help

#26 bogdanontanu   Members   


Posted 22 December 2000 - 10:19 AM

Hi again

Wow i did not think that my simple (intended helpfull) remark will generate such an emotional flame

but know it did....so:

Guys, if u think modern computers dont help ASM or non OOP programming also...you are wrong...

So when a OOP compiled program runs "decent" an ASM program "rocks the sky". I know it because i do it. My whole RTS game is done in ASM....so...wanna check compiler speeds?

My whole project is now about 150.000 lines of code, about 1000 files and it re genereates an exe from scratch (compile,link with resouces add) in about 1 (ONE) second on a P2/400 computer

Of course i have no OOP (besides DirectX code i call, an the window class if u can call that OOP )

today most "optimized" compilers only make about 100% up to 300% slower programs then ASM and again OOP compiled code is about 200% slower then normal HLL code...

Yes there are tricks to make it run a little faster...but the only thing that really can be done is pump up the hardware...
(but again ASM will benefit more ...)

For the ones that think their OOP code is fast, think about it:
Are you calling hardware assisted 3D render in? Well thats not your code...is HARDWARE! Are you calling some highly optimized ASM code? (like DirectX API...)...Well that is not your code also!

I have done my whole game myself...i only call DirectX for setup ... try to do Alpha Blending Blt in OOP an let us live long to see it finish a screen redraw..

Most source code i have ever seen (the one released to the public and that compile and run fine) are at least 40% ASM (the core) and the rest of the code is non OOP not even without jumps to labels!

Yes some AI scripts (they are HLL languages them self) are written using OOP....but they rely heavyly on some optimized ASM blocks to do the interpreted tricks...and they can have o fps of about..."now and then" or "once every 2 secconds"

If the OOP ONLY disadvantages are (you say):

and let me add:
3. complicated

Then i will consider removeing it from programming totally!... ...just kidding....but guys...dont forget its all about SPEED in games....(think at AI, GFX)

Games are very demanding to a PC, and if i can squeeze even 10% more using ASM and droping OOP i will gladly do it! But i get more then 200%....

Even if OOP has decent speed today (1Ghz Micros do the trick ) you can add enormouse more AI and GFX to a game by using ASM or even non OOP code and killing some OOP...

Yes there are advantages to OOP but those are more likely to be used in database visual programming rather then fast games.

I just wanted to kindly say: take care OOP can ruin your game speed...and generated a flame...ooops...not my intention...but if u want i can give you more arguments....just dont think i have to...


Edited by - bogdanontanu on December 22, 2000 5:36:06 PM

#27 Anonymous Poster_Anonymous Poster_*   Guests   


Posted 23 December 2000 - 07:39 AM

((Even if OOP has decent speed today (1Ghz Micros do the trick ) you can add enormouse more AI and GFX to a game by using ASM or even non OOP code and killing some OOP...

Yes there are advantages to OOP but those are more likely to be used in database visual programming rather then fast games.))

IMHO most of us dont have 20-30 years for writing tons of ultra-fast ASM code. And what about debugging? You`ll surely have lots of fun looking for 5-years-old typo in thousands of lines of as code...

#28 bogdanontanu   Members   


Posted 23 December 2000 - 11:26 AM


My RTS game is full ASM and it only took about 6 months until now...(just 2ppl but esentialy one working at at time, besides the artist)

we have big Grafix FX, units AI, Patfinding, Formations, some Network,etc you can even dl a working demo at:


I wonder how many full OOP or even full HLL (no ASM) games are out there...because i am makeing the full ASM (no HLL) game

Things are easy today with ASM, modern processors and OS's make it very easy for us also...not only for OOP...

Simple fact that you think its hard to write ASM (or just non OOP) code for you dosent make it real for other people. (*but it may be true for you)

I can do (esp in games) many things in ASM..and i can do i faster than many OOP programmers (just not menus )

Told you our game compiles in a second (just one) for the whole project...didnt I ? (150.000 lines of code)

Now i just want to say that:
- both "design patterns" : full OOP and full non-OOP are still valid ones today...think about them open-minded and choose the one, or a mixture of both, that best fits your game .. ok?


Edited by - bogdanontanu on December 23, 2000 9:28:22 PM

#29 bogdanontanu   Members   


Posted 25 December 2000 - 01:56 AM

debugging? who needs debugging

You may need advanced degugging in using OOP or HLL...to check methods ona object inheritance...class etc...

but why me?

i only use about a handfull of instructions (90% 10% rule)
what can i go whorng usihg the same very simple blocks again and again...

We did not have even one hard to find error from a very long time...

i mean our hardest errors are the logical ones, but no debugger or syntax checking will help you find those..only your brain...and again because its more simple in ASM and non OOP languages we find any error very quickly...

Most of our "hard errors" are "copy and paste errors". Copy and paste is our best enemy...problem is it helps also!

And last:have you heard of Softice? we can debug the Windows Core and ring 0 rutines with it....surely your debuggers cant do that


#30 Succinct   Members   


Posted 27 December 2000 - 05:59 AM

are u nuts?

i went to Pitt for computer engineering and got a lot of hands on w/ asm... before that, though, i cloned the entire wolfenstein 3d graphics engine in asm on a i286. i''d consider that a medium sized asm background, but i still think oop is one of the most useful tools in development there are.

i''m in the school that you write code oo-ly, then tune the bottlenecks using any tricks you can, including asm.

you say that the whole program compiles in 1 sec, and that it''s 150,000 lines of code, right?

1 line of c++ >= maybe 50 lines of asm, so your code is more around 3000 in terms of complexity.

and besides, who cares how long it takes to compile? as long as you program modularly enough, you won''t ever compile the whole thing more than 2x per day!

and you say oo is more complex than asm?

what? did i read that correctly?

oo is more abstract than asm. that is all. you seem very biased against oop. have you done much work w/ oop or are you going on what other people have told you?

besides, asm is 100% the most UNportable source there is, excluding 0100111010100101101010

dunno,just my opinion...

I have no name that you may call me. I am merely Succinct.
~Succinct Demos Online~

"Hey, where''d that display list rotate off to now?"
-(Drop me a line here)-

#31 bogdanontanu   Members   


Posted 27 December 2000 - 11:24 AM


Yes ASM is much simpler than OOP
and OOP is very complex compared to ASM...

If u think you can get by just recompile your work every 2x a day...then you didnt make many games?...we do it at least a 100 times a day....and it matteres how long it takes...yes i know you can compile just the modified code and then link modules, but i just wanted to make a fair compare between compilers speed

Now you dont know how complex our game is...do you?
i really hope (for your sake) that 1 line of C/C++ dose not translate into 50+ lines of ASM...it will be too much slow

I am not against OOP...just against too much OOP in games in every position...

I also think it is a good "design pattern" to write HLL code and then speed it up with ASM....but i wanted to mention that today you can also do ALL just in ASM...esp in games...

Because in games OOP is usefully just for Menu systems and maybe some AI scripts....you will have to use a lot of ASM in a game today...

OOP also moves you away from the CORE of programming ...slowly moveing you to the USER side...if thats what you want FINE

I dont


#32 SHilbert   Members   


Posted 27 December 2000 - 06:47 PM

A few things:

1) According to Code Complete, 1 line of C translates to 1 to 2.5 lines of assembly. I imagine C++ would be about from 1 to 5 or so.

2) Umm... you compile only twice a day? I compile dozens of times, and I think I''m pretty normal...

3) Are a few extra seconds of compile time really that bad?

Visit my site!

#33 Merrick   Members   


Posted 27 December 2000 - 07:00 PM

Well, I do a lot of work with Delphi (and its inline assembler). I also use VC++ but I try not to Delphi compiles in 1 or 2 seconds. VC++ takes forever...

Edited by - morfe on December 28, 2000 2:02:02 AM

#34 Anonymous Poster_Anonymous Poster_*   Guests   


Posted 28 December 2000 - 12:33 AM

Umm go to GT interactives UT site and find out why they used OOP... Sorry folks this isnt the early eighties were a little miscoding could give you a huge perfomance hit. And we dont really need painstakingly optimized assembly code. Which in case anyone doesnt know is very different from now then it was 15 years ago. It used to be VERY processor specific, but i dont think people remember that now....

#35 Countach   Members   


Posted 28 December 2000 - 05:15 AM

Yep, C++ does compile slow in Visual C++.
But who cares?
Any selfrespecting professional programmer has a fast computer and knows how to setup their code to prevent unnecessary rebuilds.

I have my workspace of my 3D engine (650kb sourcecode spread over ~175 files compiling into 3 dll''s and 2 executables) configured as such that most rebuilds take less than 3 seconds and a complete rebuild takes about 20 seconds.

Visual C++ compile Tips:
- Use precompiled headers
- Use incremental linking
- Make static librarys dynamic wherever possible.
- Most importantly: NEVER include windows.h when you don''t have to. Also, if you really need to use it insert this code before the #include:

// Skip everything except the kernel functions
#define NOATOM
#define NOCTLMGR
#define NONLS
#define NOMB
#define NOMEMMGR
#define NOSOUND
#define NOCOMM
#define NOKANJI
#define NOHELP
#define NOMCX

This speeds up compiling a lot.

Also, buying a fast AMD Athlon or Pentium3 processor is really worth it.

I think its crazy to use assembler all the time.
You make your code unmanagable, unportable and give other people a really hard time reading it.

#36 bogdanontanu   Members   


Posted 30 December 2000 - 03:39 PM

1.Who cares that VC++ compile slow?...not me i use ASM, but i think everybody shold care

2.Buy P3 and Athlon....hmm this VC++ and OOP makes us buy again and again lots of hardware... that was the intention...

I will just like to use my P3 like a P3 and not like a 286 because of slow OOP and people''s urge to finish a project faster with less work...

3. "a little miscoding could give you a huge perfomance hit"

This is true today as it was yesterday...

Today PC''s are not so fast as they "tell" you...sure not so fast to tolerate even minor performance errors in your code...

#37 Countach   Members   


Posted 30 December 2000 - 09:06 PM


1.Who cares that VC++ compile slow?...not me i use ASM, but i think everybody shold care

If you would''ve read my post you must have seen that the difference in compile time is about a second after some tweaking.
Do you really care about 1 second?
You will lose a lot more time by doing everything in assembler instead of C or C++.


Today PC''s are not so fast as they "tell" you...sure not so fast to tolerate even minor performance errors in your code...

Thats simply not true.
Do you know how inefficient for example Unreal Tournament is with CPU cycles?
Nonetheless, it still runs very smooth because todays bottleneck is not really the CPU anymore but videomemory bandwidth.

Also, thinking about a problem in an abstract way is rather hard if your code is pure assembler. You try to squeeze the most out of the CPU but while doing so you can forget what the code was all about. That can cause you to code a tweaked algorithm that is not as fast as a nontweaked algorithm (e.g. using an optimized bubblesort in assembler instead of using a quicksort in C++ is way slower).

Anyway, arguing with you seems rather pointless because I don''t think I can ever convince you. I just don''t want newbies to think that they should forget about learning C++ and only learn assembler because ''its faster''.

#38 The_Minister   Members   


Posted 31 December 2000 - 03:08 AM

Concerning 'how many lines of C++ == how many lines of ASM' I think it really matters how you code.

My game loop looks something like (this is pseudocode, too lazy to look it up):

if (no messages)

How many lines do you think that translates to?

The point here is that there is no point. You can argue this to the moon and back because it depends how 'high' in the implementation you are. At the top level, you run the game with a function call. At the lowest you're... programming ASM?

I'd rather type


than cut and paste three pages of code.

I would be very disappointed if your ASM game took so long to compile... especially seeing that even though I cannot program in ASM (although I know how it works), I happen to know, like everybody else, that .exe's are just piles and piles of ASM. So basically, we have one massive copy.

And what was that about 'cut & paste' earlier? What decade are you living in, dude? The only good programmer is a lazy programmer; never, EVER, repeat a line of code, unless that line is calling other lines. Both are quotes. Learn them.

Have you ever played Half-Life? Unreal Tournament? Any game developed within the last five years? You guessed it: object-orientated programming.

'Big deal,' you say. Within a meagre 10+ years you could hand-crafted the entire thing from scratch. Congratulations. You're using technology dated 10 years with no hope of incorporating it.

Ever make a mod for a game? Notice how these tend to prolong the games live's by years? How popular do you think Half-Life would be without TFC and Counter-Strike? And where do the royalties go when the mods start selling?

Planning to sell your engine? Good luck. You'll need it. I'd rather make my own than try and figure out what the hell you where doing. And then when they figure out, try and work with it.

I could carry on, but I won't. I hope that you will at least take what I say into consideration.

If any of the above information is wrong, please correct me! I hate being incorrect and not knowing it.

Thank you for your time.

1C3-D3M0N Interactive

Edit: Aah screw the source tags, I prefer HTML

Edited by - The_Minister on December 31, 2000 10:14:07 AM

#39 Kylotan   Moderators   


Posted 31 December 2000 - 05:05 AM

A full rebuild of my C++ game takes 35 minutes. That is mainly due to the high level stuff I use, especially templates/Standard Template Library. I dread to think how long it would take if I moved over to the templatised iostream libraries too. I can''t use precompiled headers as I change some of the headers too often, and it needs to be portable (ie. compile under systems that may not support precompiled headers too). Compile times are perhaps the thing that drives me away from the really high level stuff and want to play with void pointers etc.

#40 Anonymous Poster_Anonymous Poster_*   Guests   


Posted 31 December 2000 - 08:06 AM

Anybody familiar with the design pattern of a troll?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.