[DeveloperX]

So I find myself needing to learn my way around OpenGL once again, and I'm just seeking some guidelines from anyone who has been down this road before.

The choice is completely out of my control; I need to use SDL and OpenGL.

I've got my textures loaded and my GL_QUADs rendering and textured...but what I'd like to know about are what are the _right_ ways to approach building a 2D game with OpenGL?

What are some tips and tricks that you may have hidden up your sleeves?

Absolutely any help is greatly appreciated. :)
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[Jon Alma]

I've been using OpenGl for Legends ... here performance is critical as it is using full blown 3D graphics, but roughly the same things should apply for a 2D game ...

• Create some kind of texture manager - swapping textures can hit performance quite hard so either group 'game' textures together into the same OpenGL texture or only swap textures when you need to (rather than systematically swapping textures regardless).
  
• Related to this if you don't have any need to use transparent textures then possibly draw all Quads with the same texture at once (to reduce texture swapping). If you are using textures with an alpha channel then do a two pass draw algorithm where you as quickly and efficiently as possible draw the solid quads and then in the second pass draw the alpha channel quads in order from the furthest away to the closest (will that actually happen in a 2D game ... suppose it could if you have tile layers?)
  
• I created a wrapped layer between my game code and most of the OpenGL calls which made enhancing the code less painful. It also means you can swap out the OpenGL and replace it with something else.
  
• I imagine you are using glBegin ... glQuads ... glEnd type code. This might be fast enough for a 2D game, but eventually you may need to consider display lists or vertex buffers to get more speed out of your engine (see point above to ease the change!)
  
• Not drawing something is faster than drawing it ... for a 3D game this is critical as it really is worth culling any graphics not visible. For a 2D game this should be easy to do (you will probably be doing this anyway but you never know ...)
  

I hope some of that's useful - in the end most of this is not particularly specific to OpenGL but it certainly helped me.

I found that once I got the basic setup running and stable the rest is pretty easy - however if you have problems them PM me and I will see if I can help.

Jon.
_________________
Legends from the Lost Realms

[Ninkazu]

With regards to point one: this technique is called creating a texture atlas if you want to look up any literature on it. I think NVIDIA released some articles on it.

[DeveloperX]

Thank you to both of you. :)
Indeed it does help; especially now knowing what to search for.
And amazingly enough...I already am using a single texture and deciphering the UV coordinates for each 'tile' sub-texture. :)

Anyone know how to color-key in opengl? I've got a ton of sprite files that are already setup for 0xFF00FF color-keying and I haven't turned up anything on the topic yet.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[Ninkazu]

Unfortunately, color-keying is not supported in any modern 3D hardware. You're going to have to use the alpha channel for that (0 alpha for transparent part, 1.0 for solid)

[Mattias Gustavsson]

It's not as easy to make an optimized 2d-using-3d renderer as one might think. To get it working efficiently, you need to take care to batch things properly, just like you need to for normal 3d. If you don't batch things up right, a software-only 2d renderer is likely to be faster than one using 3d hardware.

Most of the info I've read on this is for DirectX (as that's what the mainstream games industry use), but all the concepts are applicable to OpenGL as well. Look at Nvidia and ATI's developer websites - lots of useful stuff there

This one is a good start: http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

I wouldn't want to go over 300 draw calls per frame for a game, and I'd guess you would want more than 300 sprites/tiles/particles on the screen, so you're going to need to batch things together.

Using texture atlas is essential, as is rendering as much as you can in each draw call. Make use of the z-buffer, so you can draw all opaque surfaces in one go, and use alpha-testing (rather than alpha blending) if you have hard-edged sprites, as that allows you to draw those along with opaque surfaces.

To get big batches, especially for dynamic surfaces like sprites and particles, you probably need to transform vertices on the CPU, and send them along to the graphics card each frame - by using the right type of dynamic vertex buffer (maybe that's VBO's in OpenGL?), you'll be able to do that with little performance hit, at least compared to changing the rendering matrix between each surface. But if you have a lot of static surfaces though (such as tile maps maybe), you obviously won't have to stream those (but make sure it's big enough, like several hundreds of vertices, or you're better of doing software transform).

Sort batches on renderstate, such that you reduce the number of expensive state switching as much as possible. For directx, look at the end of this page: http://msdn.microsoft.com/en-us/library/bb172234(VS.85).aspx where it lists costs for each state change - not sure if there is a similar list somewhere for OpenGL, but would likely be similar.
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine