In the game I'm making, I need an isometric view with some altitude, which means players can go behind a hill, and be partly or totally hidden. To avoid re-drawing the whole view tile after tile every time a player moves, I decided to put each horizontal line of tiles in cache and draw each line, one after another from top to bottom. This works pretty well, I think FPS are correct and everything, but memory usage could soon be a problem: a 50*50 map means 99 lines resulting in 98Mo, a 100*100 map means 199 lines and 388 Mo.

Here is a line:


The memory consumption will grow even bigger if I allow higher altitude (each line will be stored in a higher Surface object).

I'm wondering if this cache system was really a good idea... I could code a bit better so that lines are stored in the smallest possible Surface, but there will still be a big memory consumption.

Do you have any advice, any feedback on my system? Is it worth optimizing, or should I forget this cache-idea ?


From my experience in making a isometric engine in PyGame (using the same tileset even) I think you'll get better performance by keeping track of which sprites are where on the screen. Then, when rendering, you only update the regions of the screen that've changed since the last rendering and when you do this only redraw the sprites that are actually in this space.

My solution to this involved keeping an interval tree with all the visible sprites together with a bounding rectangle that was updated whenever a sprite changed state or position. During rendering the draw could then be clipped to this bounding rectangle and the interval tree queried for sprites requiring redraws.

That said, I'm not sure it's an optimal approach but it worked fine for my hobby projects.

  • \$\begingroup\$ I guess I could rely on a layeredDirty. Update() return for these rectangles. But with altitudes on the map, updating just those zones could result in errors... I'd have to extend those rectangles to the bottom of screen, to prevent such problems \$\endgroup\$ – CGGJE Feb 25 '12 at 18:28
  • \$\begingroup\$ @CGGJE No. You keep track of where and what draws are made to the screen. Why something is drawn to somewhere (such as altitude etc) is irrelevant. \$\endgroup\$ – Anton Feb 25 '12 at 18:48
  • \$\begingroup\$ I'm not sure I get what you mean... Let's say a player moves behind a hill, he has to be drawn, but the hill has to be drawn too, and then a tree covering the bottom of the hill (and not the player) will have to be redrawn too, and a house, which is hiding the roots of this tree should be redrawn too... You keep track of all those interactions? \$\endgroup\$ – CGGJE Feb 26 '12 at 8:21
  • \$\begingroup\$ @CGGJE Ok, the player moves behind a hill. He has to be redrawn, as does the hill in front of him which is in the same rectangle on the screen. And maybe the top of the tree is just inside the boundary so that needs to be redrawn to. But the house is below the boundary and does not. And since the drawing is clipped (important point) to the bounding rectangle of our update region, the drawing of the player, hill and tree does nothing to how the house looks. Because everything outside our update region looks like it did before. \$\endgroup\$ – Anton Feb 26 '12 at 9:20
  • \$\begingroup\$ Oh god, I didn't understand what "clipping" was (my English isn't that good) ! Thank you very much, this solves my problem! Now, I 'll just have to implement this... :) \$\endgroup\$ – CGGJE Feb 26 '12 at 19:39

In the game I'm making, I need an isometric view with some altitude, which means players can go behind a hill, and be partly or totally hidden.

Then you may as well cut this, and just call it a 3D engine with a funny camera angle, because that's what you're realistically implementing here.

And 3D engines use depth buffering to achieve this effect, which does mean re-drawing every vertex and pixel every frame.

  • \$\begingroup\$ I see your point. But I'm a real hobbyist, and even engines like panda3D look very hard to me, so I'd rather stick to my 2D api (pygame) and look for the best solution... I don't think redrawing every tile each frame is feasible... Thank you for your answer \$\endgroup\$ – CGGJE Feb 25 '12 at 14:51
  • \$\begingroup\$ I don't think this answers the question. Sure you can make an isometric game with a 3D engine. But you can't easily convert a tile based game into a 3D one. \$\endgroup\$ – muhuk Feb 28 '12 at 18:29
  • \$\begingroup\$ @CGGJE: "I don't think redrawing every tile each frame is feasible..." Every game does that. It's standard procedure. \$\endgroup\$ – Nicol Bolas Feb 29 '12 at 3:44
  • \$\begingroup\$ @muhuk: Maybe not, but it's a lot easier to do hidden surface elimination with a 3D renderer's depth buffer than in a purely 2D engine. \$\endgroup\$ – Nicol Bolas Feb 29 '12 at 3:45
  • \$\begingroup\$ @Nicos Bolas: I don't think it is the standard procedure for pygame (and probably sdl in general). I know it's what you do with directx or openGL, but it seems necessary in pygame to only update the display for the modified zones. \$\endgroup\$ – CGGJE Feb 29 '12 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.