Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Efficient tile map rendering and editing in different OpenGL versions


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
No replies to this topic

#1 Chananya Freiman   Members   -  Reputation: 140

Like
0Likes
Like

Posted 12 December 2012 - 04:00 PM

I am starting to work on a 2D tile map editor (and yes, I know there are existing ones), and wondering about techniques to make both rendering and real-time editing fast and efficient.

With OpenGL 3+ I don't have a problem.
A combination of instanced rendering, texture buffer and texture arrays, means I can efficiently render only the visible tiles in instanced mode (which I believe is damn fast) and every tile only takes 1 byte, for the texture index (assuming 256 textures are enough), which is amazing for memory consumption.
Editing-wise, changing tiles is merely changing a byte per tile in the texture buffer, which should be very fast (I can't imagine tiny changes like these take much time, yes?).
So all in all, OpenGL 3 is amazing for big tile maps rendering and editing.

OpenGL 2 (assuming the features needed are not available in extensions) is a little more problematic.
The texture array can be replaced with a procedurally generated texture atlas, which is a bit more work, but fine.
The lack of instancing, though, is a problem - do you store the whole vertex data per tile, or do you store indices into constant vectors in the shaders?
The first approach is more straightforward and relies less on shader tricks, the second takes far less memory and bandwidth.
The second way uses the fact that every tile is just a unit-sized rectangle, so it can be stored in a constant 2x4 matrix (or an array, not really sure if it matters), and the actual tile data given from the buffers will be formed of an index of the tile (this emulates instancing), the index of the vertex itself in the tile (0, 1, 2 or 3), and the index of the texture - 6 bytes per vertex, or 24 bytes per tile. The texture coordinates are also a unit-rectangle, so the same data is used for them, but with some additional uniforms that give information about the texture atlas, you can easily calculate the real coordinates to get the right texture.
In the first more obvious approach, every vertex is 16 bytes (x, y, s, t), for a total of 64 bytes per tile.
Editing is where another big bonus of approach 2 is - to edit a tile you need only edit 4 bytes (the texture index in each vertex). With the first approach, you need to edit the actual texture coordinates, so 32 bytes per tile.

OpenGL 1 has no shaders to begin with (again, assuming the extensions aren't there), so I am wondering if it's even better to use buffers in the first place, rather than just old and slow glBegin/End. Buffers in OpenGL 1 will work the same way as approach 1 in OpenGL 2 would work.

If you have other neat suggestions for any GL version, feel free to suggest Posted Image

Also I realize this question isn't very realistic, since I would probably need gigantic tile maps (hundreds of thousands and more tiles) to actually notice a difference beside how easy it is to code each approach, but I am kind of interested in this anyway.

Thanks for any answer!

Edited by Chananya Freiman, 12 December 2012 - 04:04 PM.


Sponsor:



Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS