2 ms·

Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance)

by psyklic 17y ago

Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance) can eliminate this problem. Even if each function call does take 10x longer, I would argue that in 99% of the cases you wouldn't even notice the difference, practically speaking. Shipping high quality games, developed as fast as possible. If this is what you care about, then you should care about optimizing AFTER you write the initial version and identify hot spots. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? Sloppy code vs. "slow" code are vastly different. I would much much rather have slow code, since 99% of the time it isn't even noticed by the user. Hence, it was worth not thinking about how to improve it. most high-performance items are not on the GPU. I agree that you want to take load off the GPU. However, CPU speed has not been the limiting factor in games for a LONG time. In fact, in conferences such as the GDC it is rarely discussed any longer, only in the context of using more CPU if available for non-engine tasks such as AI. And no, the 95%/5% rule does not hold true in game development. There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game. If you look at modern games, do you think it is a waste that they are based on interpreted scripting languages? They can do this because as I said above, CPU isn't as limiting a factor as before.

groby_b 17y ago
_Sloppy code vs. "slow" code are vastly different._ Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues. While you can optimize them after the fact, it's more time you're spending. _CPU speed has not been the limiting factor in games for a LONG time_ Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage. _There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_ Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En... And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well. But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top. The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world. So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.) If you look at modern games, I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)

by psyklic 17y ago

groby_b 17y ago

_Sloppy code vs. "slow" code are vastly different._ Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues. While you can optimize them after the fact, it's more time you're spending. _CPU speed has not been the limiting factor in games for a LONG time_ Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage. _There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_ Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En... And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well. But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top. The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world. So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.) If you look at modern games, I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)