20 FPS only to draw 600 textured quad???

Performance Tuning
#1

Hi!

In my game, when I draw nothing, I get between 200 and 500 FPS. When I draw only a part of the walls, 550 textured quads, I get only 22 FPS. I don’t understand what’s wrong. I bind the textures only when necessary, I use some static VBO when available. If I put all the coordinates into one single VBO or if I separate it in several VBO, the result is the same. The textures are composed of 10241024 pixels. I only use a part of these to draw a part of wall, some example I use a 256256 square from the main wall texture to draw an “impacted” wall. I use only PNG image files. Can you give me a solution to improve my performance please?

My game (the installation is a bit long, it can take 10 minutes) :
http://membres.lycos.fr/javalution/tuer.php

#2

Even when I use smaller textures, whatever I do, when I send 557000 coordinates, I get the same results : between 17 and 21 FPS. I’m very disappointed, I don’t know how to solve this problem.

#3

My message appears when I launch the game :
libGL warning: 3D driver claims to not support visual 0x4b

I use the extension Composite on my 3D card ATI radeon 9250 Pro. I tried other image file formats for the texture, it doesn’t change the performance.

#4

Now I force the use of call lists instead of static VBO and I get 27 FPS instead of 20 FPS. But I don’t know why it is so slow only to draw 600 textured quads.

#5

How many textures are you using? A single 1024x1024 RGBA texture takes 4mb vram.

#6

600 quads seems like a bit much considering your game. Are you sure culling is working? Did you consider using a library which does culling for you (Xith3D, jME, Java3D)?

What are your system specs? On my (not so new) machine, I easily get 60fps with your game.

Did you check if fill-rate is your problem? (If so, you could try to render front-to-back).

Did you profile your code?

#7

I think that I don’t need an other library, JOGL does the last part of the culling and my algorithm gives it less data to allow the GPU to do something else.

Mandriva Linux 2007, AMD Sempron 2300+, 2 GB DDRAM 400 Mhz, ATI Radeon 9250 Pro with a very bad Xorg open source driver (my former girkfriend has better performance with a SIS 661 FX chipset under Windows XP with a proprietary driver :frowning: ).

I use backface culling through JOGL.

Profile? A liitle bit and I think I have found the main problem. Display lists are quicker than static VBO only if you handle very small pieces of data.

I’m stupid, I have split all the walls into very small pieces to implement a temporary voxel-based visibility culling and my culling compensates my stupidity of splitting all. My culling is excellent but my structures are not correctly designed, I will correct it. I use 4 textures. I think that I will regroup all the walls of a same “cell” in a SINGLE vertex set (a vertex set might use VBO if available).

#8

Ick, I bet that’s your problem. Most open source 3d drivers tend to do almost all of the work in software and only bung the final result to the graphics card for actual display. If thats the case it won’t matter what you do with VBOs or display lists 'cos it’ll be dog slow anyway.

Open source gfx drivers? Just say no. ;D

#9

isn’t there a proprietary driver available for Linux for that gfx card?

#10

Yes but I need libexpat.so.0 and ln -s doesn’t solve the problem. I’m waiting for the answer of an expert of Mandrivasoft.

No, there is a noticeable difference of performance between open source and proprietary drivers but it is not as big as you assume. Open source drivers for the NVIDIA cards are quite good but open source drivers for the ATI cards are less performant. I’m responsible for the slowdown, I really think that is mainly my fault and I will solve the problem as quick as I can.

However, the alpha blending is extremely buggy with the open source driver I use.

#11

What happens to the frame rate if you choose a lower display resolution?
If it goes up drastically then fill-rate is the problem, in which case drawing front-to-back might help.

That said, I think my system’s specs are lower than yours and I easily get 60fps. So I wouldn’t completely dismiss your video drivers as the source of your problems just yet.

#12

No your system’s specs is higher than mine! TUER mainly uses the GPU, not so much RAM. Your 3D card is better than mine.

I already draw front-to-back.

#13

When I reduce the size of data but still by putting all in a single VBO, the FPS increases ;D. I will improve it and I might have better performance in a few weeks.

#14

I had forgotten to check the maximum number of primitves that can be treated when you call glDrawArrays. Then, that’s why it worked so slow.

#15

OpenSource driveres for NVidia are only 2D, a partly function 3D driver is in defelopment but far from beeing functional or good performing. The 3D NVIdia driver (proprietary, closed source) is probably the best 3D driver/opengl-implementation available for Linux these days (when talking about consumer hardware).
I have terrible experience with the opensource 3d drivers, I’ve a intel GMA950 which is called “one of the best supported chipsets by opensource 3D drivers” and its slow as hell. I can see people playing quite good games on the same hardware on Windows-XP whereas I have to reduce resolution and details to play Tuxracer or Quake3 fluently. Really disappointing.

There is a closed-source driver for your 9250, however only old versions of the proprietary ATI driver will work fine (and maybe will cause problems with your new Xorg/kernel based distribution). Newer drivers have only broken support, latest have completly removed 92xx support (R200 as far as I remember).
However it should perform far better under any circumstances than the free part,

Good luck, lg Clemens

#16

I hope you’re right. It means that I can expect a good increase of performance with a proprietary driver. But I’m sure something is wrong in my code. I play with Open Arena, Alien Arena 2006, Cube and Nexuiz fluently on my computer.

#17

How far away are the quads from the camera? I had similar experience with Opengl before.
What I did was drawing 100 idential texture mapped polygons at the exact same position which was very close to the camera.
(each poylgon occupied 3/4 of the screen area), the frame rate was horrible.

I guess the graphic card is more sensitive to the number of pixels being processed rather than the number of polys that being processed.

#18

Some of the quads are very close and some others are very very far. Which solution did you find?

#19

My solution is always avoid drawing many big overlaping polygon,
and use smarter hidden surface removal algorithm.