OpenGL + Allegro - Lag - Trouble with VBO

OpenGL OpenGL: Basic Coding
1

Hey guys =)

I’m moving from slow software rendering to nice OpenGL for speedy hardware acceleration goodness, but I seem to be having trouble, as when I start drawing lots of items to the screen, it slows down and lags - a lot.

Coming from libraries that used X 0-Screen Width Y-Screen Height, I made my own classes to load sprites and draw them at X and Y on a 1024x768 window, but I used the glBegin()/End() calls which after a bit of research, are old, slow and soon to be removed altogether.

So I need to use a VBO, for all Sprites? Problem is, is that I cant work them out, I dunno what I’m missing. But I was hoping you guys could take a look at my sprite class, and maybe some hints of how and even IF it can be implemented into it. I like the idea of just being able to do:

Sprite Cat;
Cat.Create(“Cat.bmp”);
Cat.Display(etc)

But yeah, it’s slow =( And ANY information is appreciated =)

Heres my Sprite class: http://pastebin.com/Kb1cgsqr

2

Firstly, the compatability profile is not going any where just yet. nVidia have openly pledged support for it and will continue with it propably for ever as removing it would break a huge install base of CAD applications and the like as well as all known older games (eg Doom).
AMD would be in a similar position too - and between them that’s 95% of the OpenGL PC market.

So you can continue with the compatability profile and easily speed up your sprites by using another ‘depreciated’ function - Display Lists. These little beauties wrap your draw calls and move them upto VRAM where you’ll gain the highest possible performance. Creating VBOs for your sprites is possible but will actually be slower (slightly) than the DLIST method.

3

Hmm ok. But I was reading about display lists not being able to be altered during run-time without reloading the entire list. So, currently for lets say, buttons, I do:

glColor4f((double)glColor4ubR/255, (double)glColor4ubG/255, (double)glColor4ubB/255,(double)Alpha/255);

and that changes on mouse-over, does this disable that?

Thanks =)

4

Not that it matter for performance, but your glColor line is quite convoluted. Try this instead :

glColor4ub(glColor4ubR, glColor4ubG, glColor4ubB, Alpha);

Then, before trying any optimization technique, you have to better know what makes it slow :

  1. number of pixels drawn ? Try to reduce the scale of the window to say 10 per 8 pixels (reducing most sprites to less than a pixel) and compare performance. If it goes much faster (a handfull millisecond per frame) then you have to try more optimized texture sampling, ex. GL_LINEAR_MIPMAP_NEAREST instead of plain GL_LINEAR, and make sure anisotropy if off. What is your hardware by way ? Size of textures ? How many ?

  2. If no change, then yes, try display lists / batching textures (render same sprites in sequence to reuse same texure without rebinding it) / VBO etc.

5

Hey thanks for reply. Probably around 50 quads with 24x64 textures, and one background quad at 1024x768.
Hardware:
E8400, giga HD6950

Allthough ill try the mipmap setting thing as soon ad i get home and get back to you =)

Thanks

6

Nup no change. Should I really bother learning display lists or just go with VBO’s? Although back to my original question, they seem pretty hard to work out =/

7

Are you sure that you are loading the .bmp from the hard disk only once, and not every frame?

8

Yes lol I’m not that bad =)

9

Edit:
I decided to make a texture atlas. Good idea?
Just trying to work out how to scale a sprite from one texture…
Not sure how… If the entire texture is 1440x1440 and I want to texture a quad from x50, y50 to x100, y100, how would I go about that…

10

Display lists are very simple in fact. Think about it as a “record” once and “play” lots of times but for GL commands.

Texture atlas could be good because there is no switch of texture binding. Just be careful about the texture coordinates to select each texture.
But beforehand try to nail how to improve you performance before doing something complex.

Reducing the window size dramatically did not improve the rendering speed at all ?

Try using the same sprite for all quads, even the background. Speed change or not ?
Try removing brackground, try disabling blending and alpha testing, try enabling depth testing, try drawing front to back to reduce overdraw, …

11

I tried most of that but no performance boosts, so I just went straight ahead and started a Texture Atlas class. It loads bitmaps individually and builds the atlas in ram before binding it and stores the X, Y, Width and Height of all bitmaps in vectors. The trouble I’m having now is drawing the individual bitmaps, without the whole atlas or getting weird results:

glTexCoord2f(PosSX,PosSY); glVertex3f(-1, -1, 0);
glTexCoord2f(PosEX,PosSY); glVertex3f(-1, 1, 0);
glTexCoord2f(PosEX,PosEY); glVertex3f(1, 1, 0);
glTexCoord2f(PosSX,PosEY); glVertex3f(1, 0, 0);

PosSX Being the startx of the sprite on the atlas.
But yeah I’ve just been playing with values. What also confuses me is why is 0,0 the bottom left and not the top left? :s

Anyway thanks =)

12

Why ? Probably to be consistent with GL drawing coordinates.

Beware that if using the same texture for all quads did not improve perf, texture atlas will not either.

You seem to have a different problem.

13

Uh sorry no, removing all of the re-binds actually made it really nice and smooth =)

So yeah, now I just have to figure out this Texture Atlas thing…

It’s kinda like whenever I try to set coordinates of a specific texture in the atlas, it just shrinks the texture to the size… I need to crop (I think =p)

14

Amazingly, It’s working now. Really smooth using the Texture Atlas. Class loads individual sprites into ram, builds a bitmap and then binds it after its all done perfectly =)
I’ll post it tomorrow after I clean up some junk code for those that may be interested.

Thanks for all the help :smiley: