How to determine game performance?

Newbie & Debugging Questions
#1

I’m fairly new to game programming and I was wondering how to know what a “good” game performance is.

My 2D Game consist out of a lot of tiles. With my current camera scale it would be 1400 textured tiles on screen, if the whole screen is covered in them. When that’s the case my frames per second drop from 4300 (no tiles on screen) to 1500 (screen covered in tiles). And that’s only the terrain. I’m planning to add lighting, more sprites for trees, enemies etc and all the game logic. And I’m wondering if I already lost too much performance on the terrain rendering.

I know it always depends on what kind of game, but can you say for example about 50% of the resources go to sprite rendering, 30% go to lighting and 10% each go to game logic and sound?

Any advice on performance testing / resource budgeting appreciated! :slight_smile:

#2

Wow, that’s a lot of frames lost. You don’t fetch the images for each update, do you?

If you have all the tile images loaded into a map or list at start-up, and then just draw copies of these images for each tile, you should be able to save a lot of processing power. Do you do this already?

Also, why do you have 1400 tiles on-screen? How big are they?

#3

Honestly, performance doesn’t matter (Up to a point).

If your FPS is > 60, they probably won’t even be able to notice frames at all. Only when there is a noticeable jump in FPS (Namely from around 60 to 50, or in that lower range, does it really become apparent. Note: this does depend a lot on how you’re processing input/handling animations, etc. If you’re doing it using a variable rate movement based on elapsed time between frames then probably not.

On that not, a drop from 4300 to 1500 (Almost 1/3 relative speed) is probably too much. How large are these tiles that you’re going to be displaying? Are you using a ‘sprite sheet’ or are you loading each tile image individual?

Edit: It’d be about 40x35 (Rough guess) which is 1280x1120 if using a 32x32 tile. That’s not too bad. My platformer is rendering the same (Roughly).

#4

Yeah your rough guess is pretty close. :smiley: Only I’m using 1280x720.
Another reason for me to improve performance is that I actually want to render even more at some point.

I tried different stuff with texture sheets and without, never changed much in performance. Each tile texture is only 8x8 but I have a lot of them. For example for grass: top, bottom, right, left, all the outer corners, inner corners, single double sided and so on. Plus variations. I was thinking to use an automated texture atlas to bind one big texture with all tiles before drawing the tiles but soon noticed that that would have to be a gigantic texture if I will have a lot of different tile IDs (rock, grass, stone, …)

This code runs for every block:
(in this case without texture sheet and textures 8x8 pixels)


glBindTexture(GL_TEXTURE_2D, textureID);
	glBegin(GL_QUADS);
		glTexCoord2f(0, 0);
		glVertex2f(x * Tiles.blockScale, y * Tiles.blockScale);
		glTexCoord2f(1, 0);
		glVertex2f(x * Tiles.blockScale + Tiles.blockScale, y * Tiles.blockScale);
		glTexCoord2f(1, 1);
		glVertex2f(x * Tiles.blockScale + Tiles.blockScale, y * Tiles.blockScale + Tiles.blockScale);
		glTexCoord2f(0, 1);
		glVertex2f(x * Tiles.blockScale, y * Tiles.blockScale + Tiles.blockScale);
	glEnd();

I was wondering if there is any better way to draw textures than this.

#5

Rendering more would probably not be a good idea. Either the person playing will not have a large enough screen (Like me, that’s pretty much my limit), or you’ll be giving people who play on a larger screen an edge due to exposing more tiles to them.

Gigantic image? Not a problem, bro(8x8? With say 1000 different tiles? That’s 64000 pixels, which is a 800x80 image. Which is smaller than a 256x256 image). And much better performance wise. It’s relatively costly to bind the texture each time.

As for a faster way to do it? Well, depends on what you’re using. I’m assuming that you’re using LWJGL? I’m fairly sure that it has something you could use.

#6

The number of tiles to render is a whole other story anyway, first I want to have a framework with a decent performance before I start working on anything else.

If each texture sheet for each material is 64x128 (giving me 128 different tiles for each material) and lets say I want 128 different materials. Making 16,384 individual tiles. That would be 1,048,576 pixels in a 1024x1024 texture. If I’m not mistaken that really doesn’t seem so bad.

The last time I did this calculation I had a completely different result. Must have been late at night… :wink:

So back to the texture atlas again!
(and I know the number of different tiles is high, but I would really like to have a system where this is possible)

Oh yes, I’m working with LWJGL.

#7

Honestly? That’s not too bad. It just means that you’ll have fewer discernible tiling effects if you do it right. Which is a good thing.

#8

4300 fps = 0.232 ms/frame
1500 fps = 0.667 ms/frame

So to actually paint your tiles took an extra 0.4 ms per frame. You have 16.67 ms to do everything you need to do in one frame and maintain 60 fps. I wouldn’t worry about it at all.

#9

One simple measure to test (and improve) relative performance:
Make a stress test.

Use your current renderloop, and render like a 1000 times more tiles.
(like rendering the terrain a 1000 times in a loop, preferable each iteration a little bit higher)
Somehow until your framerate drops to just a few FPS.

Also mark the current time (System.nanoTime()) at the start and the end of the loop, and display the difference.
This gives you a concrete measure of how long each frame took.
So you can compare it to any improvement you try.

Now come up with some ideas how to improve performance (precalculating some values for example, culling non visible tiles better)
You can now see clearly wich version is faster since you have a metric.

#10

Don’t measure relative performance difference when you’re just starting out. The percent difference in amount of work from nothing to something is infinite. Any minor tweak you make will make the numbers swing wildly. Good rule of thumb is that when FPS is in the four digits, it’s too early to optimize anything.

#11

Ok, I did a quick test with a 1024x1024 texture and it seems I will gain around 500 fps. So a bit better but still a lot of room for improvement. Also I haven’t tried yet to offset the texture coordinates for each different tile.

I guess my next step is to write a better debug screen to check all the ms, I already have one but it’s kinda crap. I’m not really sure if I want to use up all of the 16.67 ms, my system is fairly good and I would like it to be able to run on older machines too. But probably I should move on after implementing the texture atlas and start with the other stuff. Also sound logical that improving stuff will make more sense later on.

Another thing is, I tried using VBOs and Display Lists and didn’t really get any performance increase. The performance got even worse. Will it cost more to use those for each tile than just drawing the 4 vertices and texture coordinates directly? If there should be an increase in performance not matter what I will go back and try to fix those.

Anyway thanks for all the great help so far!

#12

As said before, don’t compare performance with ‘fps’ difference.

If you start out with 10fps, and now you get 500fps, that means it was an awesome optimisation.
If you start out with 10000fps, and now you get 10500fps, that means it was a poor optimisation.

#13

With my experience with vertex arrays it’s important to use data structures that match the ideal format that the graphics card expects. In one case using 4 bytes for color (rgba) had a huge performance advantage over 3 bytes per color (rgb).

#14

In your case I think that using VBOs is the way to go but not the way you did it. If you created one VBO per block, it’s normal that you get same or worst performance. You should create one VBO per group of blocks that share the same texture. So basically if you’re now using a single texture with all your tiles inside, you will have only one VBO ( two with the texture coordinates … :slight_smile: ) for all your terrain and this has to be built one once at the load of the map … after you just call your VBO to render the whole map. Doing this you should have a big increase in performance because you will greatly decrease the number of opengl functions calls (something like 10 instead of 1400 * 10) + data upload to the GPU.

But as you certainly guess, doing this, you should forget about a render method for each individual block but have one for the map … in fact it will force you to separate your rendering from your “model” which is a good think in my opinion.

EDIT: it’s maybe too early to try to optimize this in term of speed, but it’s maybe not too early to change the way you handle the rendering in term of design. Having one render method per renderable object in your world will be a problem later if as you say you plan to have a lot of renderable objects in your world. You should think of a way to group similar objects ( in term of texture, but also Z index ( kind of layers ) and any other property … maybe blending mode … and so on ) to be able to render them more efficiently ( using at least vertex arrays ). I went through the same path as you writing my game, I was using a render method per entity, and due to poor performance I had to refactor everything … but maybe it’s the good way to learn I don’t know :slight_smile:

#15

0.4ms for terrain rendering.
Just pick next problem to tackle.

#16

Impressed how many posts there were before someone said this.
If you use one big VBO and do it properly vs drawing quads for every tile (or one vbo per tile WTF), you will gain a HUGE performance increase.
begin & ends are taxing. As are texture binding calls - use big enough tilesheets.

[quote]one VBO per block
[/quote]
http://forum.3ice.hu/download/file.php?id=523

#17

I don’t get what the fuss is about?

He basically said “of you were to use one VBO per block, then…” and off he explains what problems it causes, and what else to do. Nobody ever said that the OP actually used one VBO per block…

Then you jump in and basically repeat everything he just said. :clue:

#18

The two most important optimizations right now:

  • Use a single glBegin/glEnd around all of your tiles (i.e. glBegin -> for loop, draw each tile -> glEnd)
  • Use a single texture for all of your tiles/sprites/fonts/etc
#19

Yea. Because tl;dr
But I was aware that this might not be the case, however its still good to make it clear.
Hey even I used a tilemap in which every tile is one QUAD, a year ago, not knowing that this wasnt the best way…