Post news RSS Fixing performance issues

I'm still busy implementing Glux. In this blogpost, I tell you how I fixed a performance problem.

Posted by on

Hi everyone! The last two weeks, I've continued implementing Glux. In fact, I've spent almost all of my free time doing that. My feelings about it are mixed: at the one hand, it's all taking much longer than I wanted. I'd hoped to be finished by now, but the game as it is right now still looks far from what we had before Glux. The biggest suprise here was, like I told you last time, textblocks, which all had to be recreated by (my) hand. At the other hand, so far I'm not at all getting desperate. In fact, I'm making good progress: every time I stop working on it, the game clearly looks more like the old game than before I began. Slowly, step by step, I'm recovering Olvand, and that of course feels rewarding.

Performance issues
Last time, I told you I had recreated the menus. At the moment, I am busy with the main world of the game itself. The first time I really got something main world-like on the screen, I was surprised to discover that everything was super-slow. Huh, I thought, wasn't OpenGL (which Glux uses) supposed to be much faster? After two hours of checking the usual reasons for slowness (do I per accident calculate one thing several times? do I leak memory somewhere?), I suddenly got it: the problem was in the fundamentally different ways in which SDL (the old system) and OpenGL (the new system) render something to the screen.

With SDL, I could keep the FPS high by only drawing as little as possible on the screen. For example, when the player walked one step to the right I only redrew the player, the tree and the background (the grass):


Everything else I left the same. This of course leads to some trouble sometimes. For example, if there's another tree next to this situation which is NOT redrawn, it will have some background on top of it, like this:


I fixed this by simply not refreshing this part of the screen. That is, only for a very small part of the screen (the red triangle below) the players could see what I redrew, the rest of the screen just showed the old situation:


The problem was, with OpenGL, you can't refresh parts of the screen; you always have to refresh the whole thing... which means I always have to redraw the whole scene AND then refresh the whole screen around 50 times a second. The game wasn't optimized for that at all! The 50 trees or so that are on the screen most of the time aren't really that problematic (Glux is more than fast enough for that), but the fact that the game most of the time has loaded hundreds of objects in memory is: for each object, the game has to check whether it has to be shown on the screen or not, and in which order, and that 50 times a second.

How I solved it
The working solution I finally came up with was to divide all objects into a grid with cells of 64 by 64 pixels. Each time the screen has to be refreshed, I calculate which cell is in the center of the screen at that moment, and draw all objects I put in these cells on the screen. Then, I look at all other cells that are within in a certain distance of the central cell, and draw all objects in these cells a well. With this approach, the game no longer has to consider ALL game objects each time the game has to be refreshed; it only considers the objects that are likely to be on the screen. This of course are a lot less objects (only about 50, usually, instead of hundreds), thus making everything much faster. Here is how everything looks right now:

Zoom in (real dimensions: 1000 x 600)Image

What you see here is a trick I'm using to debug the system I described above: I've not yet told the game it has to include the cells at the edges of the screen. That's why you only see objects in the middle of the screen. As you walk, you can now see objects pop up on one edge of the screen and disappear at the other.

Next up: the GUI
Next up is rebuilding the GUI, which I mostly turned off for now. I plan to bring all elements in the GUI one by one, see what goes wrong, fix that, and then add the next thing. I do expect the perfomance issues to return when I've fully rebuilt the GUI, by the way, as it consists of roughly 200 smaller images that have to redrawn 50 times a second. To fix that, I'm currently thinking of freezing the GUI into a static picture most the time, because it rarely changes, and only update this frozen picture when needed. Next time, I'll hopefully tell you this worked indeed :).

If you want more development, see [twitter] or [facebook]. If you want to be a tester, you can subscribe on [].

notaclevername - - 522 comments

I want to take another foot in the OpenGL pool. I've only taken a tutorial on writing a custom tga importer for openGL mixed with SDL, then went straight back to lonely SDL. Its simple that way. You don't get anything fancy, like lighting effects, or the ability to change the game window size(without cutting into performance).

Reply Good karma Bad karma+3 votes
BlackMoons - - 121 comments

Congrats on moving to opengl. Yes in opengl you just render the entire screen. Don't try to revive your old system, opengl is more then fast enough to redraw everything every frame, you just need to structure your game data correctly as you have found out.

Grid approaches work well for small areas with consistent object density. Look into Quad trees if you want to learn of a system to do it for larger areas with big variations in object density.

You will also find the way you store objects by location to be essential in speeding up path finding, weapon collision, interactions, etc.

Reply Good karma Bad karma+2 votes
Woseseltops Author
Woseseltops - - 250 comments

Yeah, of course, there must be other people with my problem; I didn't even think about that. Also, thanks for your pointer, I'm definitely going to look into that!

Reply Good karma+1 vote
BlackMoons - - 121 comments

Rendering is a very well researched field. Whenever it comes to rendering realize someone has already figured out how to do it and likely knows a much better (And often easier) to implement method then the naive approaches. Its not cheating to go research what others have discovered about rendering.

Focus on making your game play unique instead, copy every little rendering trick you can find that you think will help.

Reply Good karma Bad karma+1 vote
Swyter - - 664 comments

You should probably learn about OpenGL scissoring:

In other words, yes you can. But a sorting tree helps.

Reply Good karma Bad karma+1 vote
dsimphony1 - - 1 comments

qui ero jugar un juego de estos

Reply Good karma Bad karma+1 vote
Brian253 - - 11 comments

WOOOOOOT! Keep it up, man! :D

Reply Good karma Bad karma+2 votes
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.