What techniques that everyone should know?
Posted: Fri Feb 14, 2014 11:19 pm
Just wondering, what tip or technique you have to give us that most people should know? Related to programming of course.
On the other hand, for games in particular it can sometimes be much better to go with the "naïve" choice of data structure rather than one with a better-sounding algorithmic complexity. Memory access is a (relative) snail's pace compared to CPU cycles and computational speed, so having cache-friendly code is often far more beneficial than most other algorithmic factors (in terms of performance at least.)ejmr wrote:Data structures. There is truth to the warning about avoid pre-optimization, but choosing a poor-fit of a data structure can severly hurt performance and/or make said data a pain to work with, whether it’s a game or not.
I agree in a lot of cases. But I also think this is a big reason why a lot of PC games nowadays have the same performance I was getting from eight megabytes of RAM and a 33 MHz processor back in the early 90’s. People take the naïve structures and don’t take the comparatively small time up front to consider the alternatives when compared to realizing far down the line, “Oh damn, a lot of this needs to change.”slime wrote:On the other hand, for games in particular it can sometimes be much better to go with the "naïve" choice of data structure rather than one with a better-sounding algorithmic complexity.
slime wrote:You can spend days tweaking a piece of code to be as efficient as possible, only to discover that you only need to call it twice during the entire game, or you might end up changing the game's mechanics in a way which makes the code redundant and useless. Or you can spend all that time tweaking the wrong aspects of the code to get the best performance because you didn't profile and understand where the bottlenecks are before starting. Or your game might run at 60FPS on the lowest-end computer, and no optimizations were necessary at all. Or you could have huge performance problems caused by only a single line of code doing something really slow which you thought was efficient.
ejmr wrote:There is truth to the warning about avoid pre-optimization…
Actually I meant an O(N) algorithm can actually be faster in many cases than an O(log(N)) one even for relatively high values of N, if the data is linear in memory as well for the O(N) algorithm. http://www.overbyte.com.au/misc/Lesson3/CacheFun.html + http://www.slideshare.net/fullscreen/DI ... ed-design/ejmr wrote:I agree in a lot of cases. But I also think this is a big reason why a lot of PC games nowadays have the same performance I was getting from eight megabytes of RAM and a 33 MHz processor back in the early 90’s. People take the naïve structures and don’t take the comparatively small time up front to consider the alternatives when compared to realizing far down the line, “Oh damn, a lot of this needs to change.”slime wrote:On the other hand, for games in particular it can sometimes be much better to go with the "naïve" choice of data structure rather than one with a better-sounding algorithmic complexity.
True, and a great point (and useful links).slime wrote:Actually I meant an O(N) algorithm can actually be faster in many cases than an O(log(N)) one even for relatively high values of N, if the data is linear in memory as well for the O(N) algorithm. http://www.overbyte.com.au/misc/Lesson3/CacheFun.html + http://www.slideshare.net/fullscreen/DI ... ed-design/
That one is entirely subjective.Azhukar wrote:Use tabs instead of spamming spaces, the indentation they cause can be customized in text editors.
And of course there are two great videos about it. Part 1 and Part 2.Davidobot wrote:How to have clean code. Clean code is of outmost importance.
Here's a great book about clean code: http://www.amazon.com/Clean-Code-Handbo ... 0132350882