Hi
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
Bogdan
The 5millionth post on OO design principles..
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?
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?
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
Edited by - morfe on December 28, 2000 2:02:02 AM
"NPCs will be inherited from the basic Entity class. They will be fully independent, and carry out their own lives oblivious to the world around them ... that is, until you set them on fire ..." -- Merrick
December 28, 2000 06: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....
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:
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.
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 WIN32_LEAN_AND_MEAN#define NOGDICAPMASKS#define OEMRESOURCE#define NOATOM#define NOCLIPBOARD#define NOCTLMGR#define NONLS#define NOMB#define NOMEMMGR#define NOMETAFILE#define NOOPENFILE#define NOSERVICE#define NOSOUND#define NOCOMM#define NOKANJI#define NOHELP#define NOPROFILER#define NODEFERWINDOWPOS#define NOMCX#include
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.
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...
obysoft
quote:
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++.
quote:
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''.
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):
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.
The_Minister
1C3-D3M0N Interactive
Edit: Aah screw the source tags, I prefer HTML
Edited by - The_Minister on December 31, 2000 10:14:07 AM
My game loop looks something like (this is pseudocode, too lazy to look it up):
if (no messages)
{
GameC.Main();
}
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
pObjectC->Move();
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.
The_Minister
1C3-D3M0N Interactive
Edit: Aah screw the source tags, I prefer HTML
Edited by - The_Minister on December 31, 2000 10:14:07 AM
[email=mwronen@mweb.co.za" onmouseOver="window.status='Mail The_Minister'; return true" onmouseOut="window.status=' '; return true]The_Minister[/email]1C3-D3M0N Interactive
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement