EPTOn March 08 2012 19:17 e-Goh wrote:
Hi ShadowWolf,
I'd pretty much agree with you. For those starting out, it doesn't matter what language you pick, be it C, C++, C#, Java, Python or whatever. You can write, object-oriented C, or non-object-oriented C++. It's up to the programmer how he executes his algorithms. Much like how exact build orders don't matter all that much to bronze leaguers, if the code is bad enough, the nuances of language architecture don't matter.
However, that being said, it's pretty obvious you're not a beginner, but are nevertheless looking for something more to chew on. Game programming, as opposed to application programming, largely focuses on how much performance you can eke out, oftentimes at the cost of convenience for the programmer or elegance of the code. The way modern computer architecture has been progressing, the main bottlenecks we generally face are not the speed in executing algorithms (cpus are quite fast), but memory accesses and management.
If you are writing for the PC, it doesn't really matter because gamers have humungous amounts of memory and caches the size of whales. It only becomes more of a concern when dealing with consoles, or mobile devices where the hardware is much more limited.
The reason why game developers are not the biggest fan of STL is because it does a huge amount of alloc/deallocs on the heap during runtime. I've seen a single std::string initialization make 20 small allocations at once! This causes memory to fragment and results in less memory being available. Imagine memory pockmarked with 16kB holes while trying to allocate 4MB. All that memory in the holes aren't available because they aren't big enough to accomodate the new allocation. We much prefer pre-allocated fixed-size memory pools/containers when possible.
Lately, there's also been a movement against inheritance in general. The strength of C++ has always been that it naturally causes data that gets used together (i.e. in an object) be located close together in memory. However, when working repetitive operations on a set of many objects (e.g. updating the x, y, z position of all game objects), it thrashes the cache with all the superfluous data. Instead of one memory fetch retrieving 16 sets of useful coordinates, it now only retrieves one, simply because of the way memory is arranged.
The name of this new movement is dubbed data-oriented programming (as opposed to object-oriented though they are not mutually exclusive), and is by and large championed by a fellow called Mike Acton. Google him to find out more, but just be warned he can be a wee bit overzealous. It just so happens that straight C lends itself more to this style of programming, though there's no compelling reason why it can't be accomplished in C++ as well. It is a non-intuitive approach though, which can be unsettling for a generation of programmers brought up on pure OOP, myself included.
I hope that gave you some food for thought. Programming is like a never-ending learning adventure!
Hi ShadowWolf,
I'd pretty much agree with you. For those starting out, it doesn't matter what language you pick, be it C, C++, C#, Java, Python or whatever. You can write, object-oriented C, or non-object-oriented C++. It's up to the programmer how he executes his algorithms. Much like how exact build orders don't matter all that much to bronze leaguers, if the code is bad enough, the nuances of language architecture don't matter.
However, that being said, it's pretty obvious you're not a beginner, but are nevertheless looking for something more to chew on. Game programming, as opposed to application programming, largely focuses on how much performance you can eke out, oftentimes at the cost of convenience for the programmer or elegance of the code. The way modern computer architecture has been progressing, the main bottlenecks we generally face are not the speed in executing algorithms (cpus are quite fast), but memory accesses and management.
If you are writing for the PC, it doesn't really matter because gamers have humungous amounts of memory and caches the size of whales. It only becomes more of a concern when dealing with consoles, or mobile devices where the hardware is much more limited.
The reason why game developers are not the biggest fan of STL is because it does a huge amount of alloc/deallocs on the heap during runtime. I've seen a single std::string initialization make 20 small allocations at once! This causes memory to fragment and results in less memory being available. Imagine memory pockmarked with 16kB holes while trying to allocate 4MB. All that memory in the holes aren't available because they aren't big enough to accomodate the new allocation. We much prefer pre-allocated fixed-size memory pools/containers when possible.
Lately, there's also been a movement against inheritance in general. The strength of C++ has always been that it naturally causes data that gets used together (i.e. in an object) be located close together in memory. However, when working repetitive operations on a set of many objects (e.g. updating the x, y, z position of all game objects), it thrashes the cache with all the superfluous data. Instead of one memory fetch retrieving 16 sets of useful coordinates, it now only retrieves one, simply because of the way memory is arranged.
The name of this new movement is dubbed data-oriented programming (as opposed to object-oriented though they are not mutually exclusive), and is by and large championed by a fellow called Mike Acton. Google him to find out more, but just be warned he can be a wee bit overzealous. It just so happens that straight C lends itself more to this style of programming, though there's no compelling reason why it can't be accomplished in C++ as well. It is a non-intuitive approach though, which can be unsettling for a generation of programmers brought up on pure OOP, myself included.
I hope that gave you some food for thought. Programming is like a never-ending learning adventure!
Pretty interesting post, thanks for taking the time to write this!
