LÖVE

Just wondering, what tip or technique you have to give us that most people should know? Related to programming of course.

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. This page contains some information on data structures and algorithms used throughout various software:

http://cstheory.stackexchange.com/quest ... 9773#19773

And this is a much more comprehensive reference:

http://xlinux.nist.gov/dads//

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.

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.)

I think knowing when and what to optimize is one of the most important things to learn, aside from more specific stuff.

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.

http://blogs.msdn.com/b/shawnhar/archiv ... aggis.aspx
http://blogs.msdn.com/b/shawnhar/archiv ... guess.aspx
http://blogs.msdn.com/b/shawnhar/archiv ... rking.aspx
http://blogs.msdn.com/b/shawnhar/archiv ... ation.aspx
http://blogs.msdn.com/b/shawnhar/archiv ... thing.aspx

(I love his blog )

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.

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: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…

ejmr wrote:

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.

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.”

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/
I guess my comment also applies to premature optimization too though.

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/

True, and a great point (and useful links).

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

Use tabs instead of spamming spaces, the indentation they cause can be customized in text editors.

Don't obfuscate your variable/function names just to make them short, it won't make your code any faster or clearer to read.

love.physics is your friend, don't be afraid of the big bad sticker on wiki.

Azhukar wrote:Use tabs instead of spamming spaces, the indentation they cause can be customized in text editors.

That one is entirely subjective.

Tabs vs spaces isn't important enough to warrant any religious debate (it is the ultimate form of bikeshedding). Any non-trivial advantage one way of indentation has over the other is rendered void by using any text editor that isn't notepad or nano.

Personally I prefer to use whatever is idiomatic for that language, unless the project I'm working on has a code guideline, then I follow that.

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

And of course there are two great videos about it. Part 1 and Part 2.