PDA

View Full Version : [OpenGL] Optimizing Ortho Graphics with DLs and VBOs



WILL
15-01-2009, 07:50 PM
Hey guys, I'm looking at optimizing some of the graphics in my games. I'm using OpenGL with minimal optimizations. Actually, I'm not using a single Display List or Vertex Buffer Object at all.

The graphics are all displayed in ortho mode so all my optimizations will be required under that context. I have some static graphics (don't change) and other graphics that are much more dynamic. (changes only often OR changes very frequently) Do you guys have any tips on how to go about including DLs and VBOs into my routines in such a way that they will actually be of a speed benefit to my drawing speed?

Thanks. :)

arthurprs
15-01-2009, 09:51 PM
vb is instant nitro for particle systens :)

try looking into phoenix, i think it uses vb for the particle system

WILL
15-01-2009, 11:03 PM
Oh I just realized something... what if I had a scrolling map? Would that kill my use of Display Lists? I mean everything moves so would I then have to move the camera or...?

Traveler
16-01-2009, 09:01 AM
I can't offer any real tips on improvements, but I do wonder if your game needs any optimizations at this time. I seriously doubt if at the end you'll see any improvements. That said, I do support the arthurprs' comment about Phoenix. I use it too and so far I like it a lot. It's very easy to work with and can be extended in any way you like .

chronozphere
16-01-2009, 03:21 PM
I think the best way to improve performance, is to make VBO's or DL's for different parts of the map, and render the visible ones. It's much faster than rendering the tiles one by one (That's what you are doing now, right?). But this requires your map to be preprocessed at the beginning. It requires some work, and i don't know if it's worth your time.

I can't tell whether phoenix is good or not. But it might be quite some work to port all your graphics code to Phoenix. It might be very beneficial though. I suppose you do some research before you try to apply any drastic changes to your code. :)

User137
16-01-2009, 03:35 PM
Vertex buffers work when it's all organized somehow. Particle system (where all particles look similar) or tile map where only thing you would change when scrolling is texture coordinates.

Example of scrolling tilemap with vb:
Say your map is 256x256 and screen shows 30x20 of it, and allows smooth scrolling with floating point coordinates.

Actual rendering area would be 31x21 that is 1 extra rows reserved for scrolling. That makes a vb to be filled with 651 quads (2604 vertices without indexes) or 672 vertices on solid triangle strip.

So map is actually always in same place, X,Y moving between 0 to -1 (glTranslatef() here, don't modify vertex coordinates) and texture coordinates changing based on tile on that spot in map array.

Andreaz
16-01-2009, 04:22 PM
Dont use display lists, they are deprecated from the OpenGL API and never really been a good solution, use Vertex Buffers, or even better Vertex Buffer Objects.

As chronozphere and others have mentioned you can check the Phoenix particle engine for example on how to use vertex buffers. There's also the tile engine source that uses vertex buffers. (http://www.phoenixlib.net/files/phxTiles.zip)

Also to note, that for certain things, like static backgrounds, gui's and other stuff, intermediate mode (glVertex etc) is fast enough. For things like particle systems, fonts, tile engines and so forth VB/VBO's will be faster.

But as always, every vertex you don't render is alot faster, so use frustum culling and other technices to determine what need to be rendered and what can be skipped.

The one thing i feel is better using VBO's and VB's is that it is easier for the driver, the intermediate mode causes some headaces sometimes due to bad driver support (Intel someone?).

I'm rewriting the core of Phoenix to use vertex buffers for all the rendering at the moment as a part in making it more streamlined and to be able to support D3D, it is turning out quite nice.

jdarling
16-01-2009, 09:56 PM
Hey Andreaz, while your in there can you do a bit of work on the Linux and Mac support :). I'm still using a hack version and don't remember where all I had to hack it to get it to work on Mac :D .

I'd be happy to test anything you get as it will make my life easier in the long run.

WILL
24-01-2009, 09:13 PM
Thanks for your advice guys. :)

Those of you that know me know that I've stopped using high level Game/Graphics libraries since well ages ago. ;) Not that I think they aren't good, actually my reasoning is simple. I have fun doing it myself and learning how it's all done at a low level. Plus it gives me the illusion that it's faster because I can tweak it here and there. :lol:

That said, I've decided to go with Display Lists for the reason that it's a simple solution and I've figured out that I'll still get a lot of speed-up out of it from the way I'm doing things right now. VBO though great for more complex 3D geometry, just seems way too much for a simple 2D sprite who's actual dimentions don't change much at all.

I also figured out how to make use of the DLs too. :lol: Threw me for a loop for the first 5 mins. (No pun intended. :P) I'm not noticing much of a increase in performance much right now, but then again I'm on a faster machine than my usual development platform. I'll double check when I get back on that machine.

User137
25-01-2009, 11:53 AM
You should try vertex arrays, they should perform faster than display lists any day. (If not counting a vertex array that is put in a display list...)

JernejL
25-01-2009, 04:35 PM
But how does VBO help where you render a lot of particles which have different textures? there's a lot of texture state switches there, and you can only render about a quad per sprite, does using VBOs in that case help at all?

chronozphere
25-01-2009, 07:29 PM
VBO's can definitely increase your game's performance. To minimize texture changes, you should merge your small textures together and make a few big ones that contain different rectangles for animation-frames and particles (Tilesets). These are especially effective when you want to render particles and terrain tiles. I suggest you make one big texture for all your particles and render them all at once after you rendered the rest of you scene. This would avoid redundant texture changes and make your game alot faster. :)

Use a quad with appropriate texture coordinates to "select" a tile from your tileset and render it.

User137
25-01-2009, 07:47 PM
But how does VBO help where you render a lot of particles which have different textures? there's a lot of texture state switches there, and you can only render about a quad per sprite, does using VBOs in that case help at all?
That is a design issue. Using lots of textures is always slowest way to go. If there is tens or hundreds of different particles you might consider drawing them all in a bigger bitmap in memory first and using that as 1 texture.

JernejL
25-01-2009, 10:16 PM
I don't think you guys realise how complex it becomes to implement image atlas in a particle system that advanced as the one i have (think different pixel formats and sprite resolutions and include the per-gpu image size limit), and pretty soon managing all that becomes harder and the speed increase ends up being neglectible.

Do not say that the design is wrong, i was just pointing out that sometimes the VBOs don't go well with a existing system that was made to be something more than just sparks.

Andreaz
26-01-2009, 07:06 AM
I don't think you guys realise how complex it becomes to implement image atlas in a particle system that advanced as the one i have (think different pixel formats and sprite resolutions and include the per-gpu image size limit), and pretty soon managing all that becomes harder and the speed increase ends up being neglectible.

Do not say that the design is wrong, i was just pointing out that sometimes the VBOs don't go well with a existing system that was made to be something more than just sparks.

Well, everything is a design question, i've implemented texture patterns for the particle system in Phoenix, i made the design choise to keep it simple, only allowing for a rectangular particle grid of 2x2 4x4 or 8x8.

See the source:
http://phoenixlib.net/files/phxParticles.pas
http://phoenixlib.net/files/phxParticleAffectors.pas

What was the problem with the different pixel formats? That really shouldnt matter if you're using OGL or D3D

And jdarling, yeah better MAC support would rock, i have no access to a mac or a linux distro through ;p