Tweaking for speed.

OpenGL Development
#1

This is my first venture into game/opengl programming, so bear with me.

I’ve got my engine setup and working. My goal in writing was to limit the amount of overhead needed to initialize the engine- essentially, I wanted the main entry point of the game to have as little clutter as possible (main entry point being the ‘driver class’, or whichever class has the static main). With less clutter, setting up sepecific game rules would be easier and more efficient as they are commonly written at the first point of entry. The result was the creation of utility classes to do work outside of the driver class. However, I havn’t been able to figure out how these classes should be written. Which leads me to my first question:

Singleton Class vs. Class with static methods/data members- Which is faster to deal with? The class which manages entities (things to be drawn to the screen) is currently a singleton. Therefore, whenever I wish to spawn a new entity, I must do something like this:


EntityManager.getEntityManager().spawnEntity(new FakeEntity());

If the class had static methods/data members, I would do something like this:


EntityManager.spawnEntity(new FakeEntity());

I understand that for security reasons the singleton would be the best choice, as you can guarantee that only one instance of the EntityManager would exist at a time. Still even, when dealing with massive numbers of entities, something tells me things will be faster using the latter method. To better help describe things, here’s a link to a file which speaks in code: http://www.funkapotamus.org/Singleton.java

My second problem deals with drawing images to the screen. I get severe slowdown when I throw a few hundred up there.

When I look around on NeHe’s website, I see many great c++ demos of particle engines which boast 3k+ particles on screen with no noticable slowdown on my machine(which by today’s standards is low-end). Is it unrealistic to expect these kind of results with LWJGL? I ask because I am unable to get more than 750 96X96px images on the screen without dipping below 60fps. I imagine it has to do with how I’m initializing OpenGL and how I’m drawing sprites to the screen. Could flipping between blending/no blending many times hurt fps?

Here’s my GL init and sprite draw code:

GL Init


GL11.glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

GL11.glEnable(GL11.GL_BLEND);                                    GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);
GL11.glEnable(GL11.GL_TEXTURE_2D);                                    GL11.glDisable(GL11.GL_DEPTH_TEST);                              

GL11.glViewport(0, 0, Globals.width, Globals.height);            
GL11.glMatrixMode(GL11.GL_PROJECTION);
GL11.glLoadIdentity();
//  2D Game
GL11.glOrtho(0.0f, Globals.width, Globals.height, 0.0f, Globals.minDepth, Globals.maxDepth);
GL11.glMatrixMode(GL11.GL_MODELVIEW);
GL11.glLoadIdentity();

Sprite Draw:


GL11.glBindTexture(GL11.GL_TEXTURE_2D, textureID[0]); 

GL11.glColor3f(1.0f, 1.0f, 1.0f);
GL11.glEnable(GL11.GL_BLEND);
if(!blend)
   GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);            
else
   GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE);
if(alpha > 0.0f)
   GL11.glColor4f(1.0f, 1.0f, 1.0f, alpha);
            
GL11.glLoadIdentity(); 
GL11.glTranslatef((float)origin.getX(), (float)origin.getY(), 0.0f); 
GL11.glBegin(GL11.GL_QUADS);
            GL11.glVertex3f(-width / 2, -height / 2, 0.0f);            GL11.glTexCoord2f(0, 0);            //Bottom Left
            GL11.glVertex3f(width / 2, -height / 2, 0.0f);            GL11.glTexCoord2f(1, 0);            //Bottom Right
            GL11.glVertex3f(width / 2, height / 2, 0.0f);            GL11.glTexCoord2f(1, 1);            //Top Right
            GL11.glVertex3f(-width / 2, height / 2, 0.0f);            GL11.glTexCoord2f(0, 1);            //Top Left
GL11.glEnd();

To close, here’s a pic of the game’s action thus far:

http://www.funkapotamus.org/crs2.jpg

Edit: I hit save when I meant to preview… everything should make sense now.

#2

GL11.glBegin(GL11.GL_TRIANGLE_STRIP);
GL11.glVertex3f(-width / 2, -height / 2, 0.0f); GL11.glTexCoord2f(0, 0); //Bottom Left
GL11.glVertex3f(width / 2, -height / 2, 0.0f); GL11.glTexCoord2f(1, 0); //Bottom Right
GL11.glVertex3f(-width / 2, height / 2, 0.0f); GL11.glTexCoord2f(0, 1); //Top Left
GL11.glVertex3f(width / 2, height / 2, 0.0f); GL11.glTexCoord2f(1, 1); //Top Right
GL11.glEnd();

#3

My particles engine’s been proven to be ubber fast
http://www.realityflux.com/abba/ShowSRC/showsrc.php?src=../Lwjgl/BlinnLighting/source/GeomUtils/GLParticles.java

#4
  1. Batch up the geometry and use vertex arrays.
  2. Minimise the number of glBindTexture calls. If a sprite uses the same texture as the previous one, then there is no need to bind it again.
#5

[quote]GL11.glBegin(GL11.GL_TRIANGLE_STRIP);
GL11.glVertex3f(-width / 2, -height / 2, 0.0f); GL11.glTexCoord2f(0, 0); //Bottom Left
GL11.glVertex3f(width / 2, -height / 2, 0.0f); GL11.glTexCoord2f(1, 0); //Bottom Right
GL11.glVertex3f(-width / 2, height / 2, 0.0f); GL11.glTexCoord2f(0, 1); //Top Left
GL11.glVertex3f(width / 2, height / 2, 0.0f); GL11.glTexCoord2f(1, 1); //Top Right
GL11.glEnd();
[/quote]
That’s a nice particle engine. Setting it to 1250 particles, I get 50-80fps depending on whether or not it gets really close to the screen. Just curous, what do others get?

One question though:
When it reaches the hardware, doesn’t a quad autmatically get cut into a triangle strip anyway?

Also: Why are vertex buffers faster? In the end, I still have to use geometry to find each vertex. It seems like more work to make an array and shift the data into a buffer. In fact, I never quite understood buffers anyway- they feel like a poor man’s attempt at C++'s arrays- which you can traverse using a memory address rather than an index.

#6

I would scrap the glTranslatef() and merge the translation into the glVertex calls.

  • elias
#7

[quote]Also: Why are vertex buffers faster? In the end, I still have to use geometry to find each vertex.
[/quote]

Vertex arrays are faster because it allows geometry to be sent to the card useing fewer gl calls. It allows you to draw all of your sprites with only a couple of calls.

[quote]It seems like more work to make an array and shift the data into a buffer.
[/quote]
You can put the data directly into the buffer. No need to create an array first.

[quote]In fact, I never quite understood buffers anyway- they feel like a poor man’s attempt at C++'s arrays- which you can traverse using a memory address rather than an index.
[/quote]
The benefits come from the fact that direct buffers is located in system memory wich can be accessed directly by the opengl driver. With a normal glVertex3f call the data first is passed to native side threw JNI. Then its sent to the driver threw a call to a dll. It’s expensive, and it adds up. With vertex arrays you store the data in the buffer, wich is as fast as storing it in an array. The data is later pulled in by the driver. There is no function overhead.

#8

Thanks for clearing that up tom.

Besides pestering people for everything, I think I’ve exhausted all my resources on the interent. I have many examples from NeHe, but they never really allow me to learn why I should do something. This doesn’t sit well with me. I feel the need to reinvent the wheel at almost every turn- there’s a part of me that says “screw LWJGL, write your own binding!” Though, the sane part of my brain keeps me from attempting such a vast project.

I figure I should start looking into books. But I don’t know where to begin. Do you have any recommendations?

#9

Here is a better source than any book.

A really good way to start thinking about OpenGL is to imagine your data as passengers on a bus. Imagine that the bus has a route between the CPU and the graphics card.

Now, imagine the bus being a single OpenGL call. Every time the CPU wants to make an OpenGL call to the graphics card, it has to put some passengers on a bus, and the bus has to drive down the road and the passengers get off at the other end and do something in the graphics card.

It doesn’t take long to realise that a bus journey will be much more efficient if it takes more passengers with it!

There’s only so far you can really stretch this analogy but it’s a good grounding in the first principle of client/server programming (which is what OpenGL is all about).

Cas :slight_smile:

#10

Useing VBO buffers will put the arrays onto the gfx card memory for even faster speed. (needs a modern gfx card thought)

#11

[quote]Useing VBO buffers will put the arrays onto the gfx card memory for even faster speed. (needs a modern gfx card thought)
[/quote]
This is true if the geometry is static. With a particle system all the data is sent to the card every frame anyway, so vbo’s won’t help much.

#12

oh right, That should teach me to read the top post :-/

#13

Not strictly true :stuck_out_tongue: VBOs come in different flavours. You can get VBOs that are designed to stream data to the card over high-bandwidth buses (eg. AGP). Like NV_vertex_array on steroids.

Cas :slight_smile:

#14

you mean NV_vertex_array_range?

  • elias
#15

Actually NV_vertex_array_range2, smartypants :-*

Cas :slight_smile: