3
\$\begingroup\$

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:

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 ?

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
3
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
5
  • \$\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, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 19:39
1
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
5
  • \$\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, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 7:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .