Thu
06
Nov 2014

Last week I talked with a colleague about optimizing performance of his game project. It's written in Scheme (functional programming language, dialect of Lisp), using SDL and OpenGL. The bottleneck was GUI rendering.

When analyzing code, we found that the function for rendering text renders TTF font to a new surface with function TTF_RenderUTF8_*, then creates another SDL_Surface to convert format, then creates and fills OpenGL texture with glTexImage2D. The texture is then used just once for rendering... to another freshly allocated SDL_Surface, to perform clipping. All this happens for every GUI control, in every frame! Finally the objects are freed by Scheme garbage collector.

He then asked me whether we should find a way not to render the GUI part of the screen every frame, but only when something changes. He also cited the famous and often misused quote of Donald Knuth: "Premature optimization is the root of all evil".

I explained to him that modern GPU-s are able to render millions of triangles every frame and redrawing whole screen every frame is a standard practice. It's resource creation (allocation and filling of surfaces and textures) what should be avoided and not done every frame. If using SDL_ttf for text rendering, a final texture/surface should be prepared once and used to do just rendering in every frame, until the text changes. Additionally, calls like glViewport or glDisable(GL_DEPTH_TEST) also don't have to be made for every object in every frame.

When thinking about it now, the general rule of game optimization could be:

• Don't calculate per pixel what you can calculate per vertex.
• Don't calculate per vertex what you can calculate per object.
• Don't calculate per object what you can calculate for a group of objects or once per frame.
• Don't calculate per frame what you can calculate every X time, once per several frames, or only when it needs recalculation.
• Don't calculate in real-time what you can calculate only once, when loading a game.
• Don't calculate in game what you can precalculate offline in editor, build system or on your server farm and just store in files.

About functional programming and stuff like that, I think such high level concepts are good for software development as long as they are accompanied with understanding of what's under the hood. Some principles of functional programming, like avoiding side effects and just transforming one list of items to the other, are similar to the idea of DOD (Data-Oriented Design), used in game development for efficiency and scalability. But I don't agree that thinking about efficiency should be avoided until necessary or that optimization makes code complex and unreadable. Quite contrary - I believe simple code is both readable and efficient.

As I have little experience with functional programming, for me it was also fascinating to learn basics of Scheme. It's based on simple principles yet it is so powerful. I'm now thinking about how a language like this could be applied everywhere, from program configuration and as a description language, to game scripting and procedural media generation :)

Comments | #functional #optimization Share

Comments