Jump to content
  • Advertisement
Sign in to follow this  
rudeness

OpenGL Ultimate 2D tile rendering.

This topic is 4538 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, If I wanted to render a static collection of 2D tiles (fixed grid, orthographic) in OpenGL, what would be the ultimate way of doing this? I'm using quads or point sprites if available. I have several questions; 1. Is there any point in using display lists, VBO's etc? 2. I'm currently binding a new texture for every tile. This means I also have to glBegin/-end for each tile, which seems kind of silly (and the constant texture changing eats performance). If it's my lucky day, there exists a glMagicalFunction(textures[0]) which accomplishes this. 3. As it is now, I'm calculating what tiles are currently viewable based on the viewport. This means that the number of tiles that are looped through each frame is the number of tiles required to fill one screen. Is this the best way of doing it? Is it possible to push all that work on the GPU as well? And a completely unrelated question: 4. Is there any library that can read and render SVG using OpenGL? Good resources about 2D development i OpenGL would be highly appreciated. Thanks! PS. Please spare any "omg search the forum n00b"-replies, as I have searched the forums, and I did find a lot of 2D threads/articles, but none that answered my specific questions.

Share this post


Link to post
Share on other sites
Advertisement
1' Immediate mode is slow. Very slow. Very very slow. Display lists and VBOs are much faster. It's a matter of performance - immediate mode should only be used to render unimportant stuff or for tests.

2' Simple: store all of your tiles in the same texture. If you use 32x32 tiles, you can have 256 tiles in a single 512x512 tileset.

3' This ties in with question 1 - you could create display lists to hold various tile structures and only call the structures currently visible, instead of going through what could be thousands of tiles each frame. But this probably won't be much of a performance hit either way, seeing as a few thousand "if"s each frame isn't too heavy.

Alternatively, you can hold your map in an array and only render the necessary tiles instead of looping through all of them. There's no need to test if a tile is onscreen or not, just to find the range of tiles to render.

4' Sorry, dunno about that...

PS: omg search the forum n00b! :o ...kidding. :)

Share this post


Link to post
Share on other sites
1. Yes

2. You should store all the tiles on one big texture, bind it once at the beginning, and *not* use glBegin/glEnd.

3. Looping through all the tiles is normal, if you use display lists, you might not have to (I haven't experimented with this).

Share this post


Link to post
Share on other sites
Unless you have the most complex game ever, a simple 2D system wouldn't need much more optimization than a display list. I'd suggest taking your tiles (all in one texture), combine that with your map data and create the whole terrain at load time. Store this in a display list and just draw it each frame. You could take it one step furthur and actually combine all the tiles and create one large texture from that and then simply draw a single quad each frame for the entire ground. This will take more computation, but give better in game performance.

Share this post


Link to post
Share on other sites
You are most likely going to be fillrate limited, so a lot of this might not matter.

Share this post


Link to post
Share on other sites
Thanks for replying!

Are you telling me you can compile textures into display lists?

I have considered drawing all the tiles on one big quad (if that is what you meant). This means I'll basically have to create one massive texture at load time, right? Will this really speed things up if the map is really huge? I though that would require an horrible amount of memory.

Oh, and yes: It's true that one can afford to be sloppy when dealing with 2D in these days, but I'm still curious.

Share this post


Link to post
Share on other sites
Quote:
Original post by rudeness
Thanks for replying!

Are you telling me you can compile textures into display lists?

No, a display list can contain many primitives (probably quads or quad strips) all using the same texture object containing a whole tileset.
The only way to use a fixed display list is putting the whole level (all tiles) into it, relying on clipping to kill offscreen tiles and using transformation matrices to perform scrolling.
If the level is too large for that you can have a display list (or immediate calls) to draw one screenful of tiles, with a VBO containing texture coordinates and possibly vertex coordinates.
Quote:
I have considered drawing all the tiles on one big quad (if that is what you meant). This means I'll basically have to create one massive texture at load time, right? Will this really speed things up if the map is really huge? I though that would require an horrible amount of memory.

You need to create a large and constant texture object, not to draw large quads: the texture contains each tile in the tileset at a specific interval of texture coordinates and each tile of the screen is drawn as a small quad (or two triangles) with texture coordinates corresponding to the desired tile.


Share this post


Link to post
Share on other sites
Aha! So you just change what portion of the texture object you want to render to each quad/tile?

Until now I actually extracted the relevant pixels and created individual texture objects for each of them, and it never occurred to me that texture coordinates could start somewhere else than (0,0). (^-^)' Ehehe.

Thanks a lot!




Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!