Rendering pipeline advice needed.

Hello, I’m developing a little game and wanted to get a bit of advice. I have something playable, the game engine is already working, but I’m rendering everything using immediate mode calls (glBegin…glVertex…glEnd), particle systems included.

In my latest game I’ve noticed that rendering particles this way was not very clever, because it had such a huge performance impact.
I want you to recommend me about how should I render (vertex arrays, display lists, fence, etc) the geometry in the game. Let me describe what I need to render:

  • Game world: the game world is composed by cells (15x15, 25x25 are common sizes). The game world is static, but some wall textures are animated (therefore I cant use display lists). I still don’t know how many polys could I use. Right now I’m using an OpenGL light no illuminate the surfaces, but I think I will later use precalc lightmaps.
  • Particle Systems: dinamic particle systems (non precalc)
  • Other geometry: player is animated (non lighted) using vertex interpolation (in software). PowerUps are rotating objects ala Quake 3.

Its not a big project, but I want it to run as smooth as possible. Please, point me to other threads/replies if you consider this has been answered before.


Look into the vertex_buffer_object extension.
If you are not familiar with extensions (and don´t want to take the time to learn it), you should use plain vertex-arrays.
With simple vertex-arrays it shouldn´t even be a problem to update particles. If you use VAR (nVidia stuff) or vertex_buffer_objects such dynamic stuff can be trickier to implement.
Using texture-animation is not a problem with that.
If you don´t know much about extensions, you should get the extension-loading-library, which makes all that stuff a lot easier: (Nehe has a tutorial about extensions, too).

Hope that helps you.

You can animate textures with display lists, by using the texture coordinate matrix (set it up before calling the list).

Thanks. I’ve used extensions before, but I need to learn those you mentioned. Is there an advantage over using vertex_buffer_object instead of VAR?
I suppose vertex_buffer_object is like an Direct3D implementation of a vertex buffer.

Is there an advantage over using vertex_buffer_object instead of VAR?

Well, it let’s drivers manage data storage. And, considering the non-NV-specific nature of it, it’s highly likely that nVidia will spend more of their time optimizing VBO’s than VAR. Indeed, with the new AGP-like memory protocol coming out, VAR may not even support it correctly. VBO will.

I suppose vertex_buffer_object is like an Direct3D implementation of a vertex buffer.

Kinda. Only significantly improved in both performance and functionality. They similar in that they hold the same kind of data.

VBO is new, VAR is old. So VBO is better (i think). Also VBO is an ARB-extension, which means it is available on all (current) hardware, VAR is only on NV hardware available.
I only used VAR up to now, but some time ago there was a thread, where some people said VBO would be even faster than VAR (since the new drivers were released).
Also i can tell you, VAR is not such a nice thing to work with, it only gives you a chunk of memory, i had to write all the object handling by myself. VBO does already give you some form of object management, if i am correctly informed.