Sign in to follow this  

running out of ways of going faster fps

This topic is 4863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a large terrain with multi texing and it's an airplane fighter game. I have done the following: 1. split the terrain up into smaller chunks 2. only render the chunks that are in the frustum 3. for terrain a larger distance away I draw much lower resolution versions (ie one third of the width and length or the original chunk) 4. I'm using Compiled Vertex arrays - I don't have VBOs on my card and nor do my friends ! The CVAs sped things up by 50% 5. the aircraft are drawn using display lists 6. the aircrfat are frustum culled 7. I have a skybox each texture is 512x512 8. I have yet to do any collision detection or AI 9. The terrain textures aren't that detailed - what I mean is I'm not tryign to render 700k textures into a tiny part of the ground - I spread the textures out over the terrain. For most of my game if I can see the terrain then I'm at 16 FPS Even if I make the whole terrain LowRes (ie instead of 180x180 height map I in effect make it a 60x60 map by taking every third vertex) then it can go up to say 18 FPS which is a bit better. Without using VBOs is there any other ways I can speed things up ? (I tried putting the CVAs in Displaylists but that wouldn't work for love nor money !) cheers

Share this post


Link to post
Share on other sites
the first thing i'd suggest is to run a profiled build so you can see which part of your program is actually eating up all the time. from there you can try and work out different algorithmic approaches. for generic starters, i'd suggest looking at quad-trees or oct-trees for starters; they'll allow you to cull huge portions of your world with a single frustum check.

-me

Share this post


Link to post
Share on other sites
Just a little suggestion i lately got baffled by, have you tried display lists containing glVertexX calls and such instead of VAs? As strange as it might seem, it might make a difference.

Quadtrees are indeed a good optimisation, it might give you a framerate of 160 or more instead of 16. Also, what texture filter are you using, mipmapping could speed things up.

And about the optimizing after profiling, yes that would be best although adding quadtrees will certainly speed things up a lot so they can be added anyway IMO.

EDIT: typo, i said VA instead of quad tree.

Share this post


Link to post
Share on other sites
Profiling an OpenGL application is not that rewarding, since the OpenGL calls are asyncronous.
Anyway, post some info:
1. What terrain size
2. How many triangles do you render, on average.
3. System specs.
4. Resolution, color deepth, fullscreen/wiondow.
5. Vsync on or off?
6. Video card settings (such as FSAA, antisotopic filtering, etc.)

Share this post


Link to post
Share on other sites
>>For most of my game if I can see the terrain then I'm at 16 FPS
Even if I make the whole terrain LowRes (ie instead of 180x180 height map I in effect make it a 60x60 map by taking every third vertex) then it can go up to say 18 FPS which is a bit better.<<

u send 1/4 of the geometry to the card, yet the fps goes up ~10% (and not ~400%)
sounds like youre filllimited
-to see if u are make the window small eg 256x192, does the framerate increase heaps?
if so then using DL's VBO' CVA's etc are not really gonna help u old that much, as others have said find the bottleneck first

Share this post


Link to post
Share on other sites
The 60x60 map should have 7200 polys, right? Even with a brute-force rendering approach, this should be managable even on older graphics hardware (GF2 or so). Even if you don't have quadtrees, it should not be so slow.

VBOs wouldn't probably speed it up too much since the amount of graphics primitives is not too high. VBOs pay off if the transfer of grapgics primitives to the GPU is the bottleneck, but it sounds like the fillrate is your problem.

What graphics card do you have?

Share this post


Link to post
Share on other sites
I got a huge performance improvement in my engine when I eliminated all divisions in my time-critical code (well as much as possible) and replaced them by multiplications.

Things like normalizing i.e:

float len = sqrt(a*a+b*b+c*c);
a /= len;
b /= len;
c /= len;

are significantly faster if done that way:

float len = 1 / sqrt(...)

a *= len;
b *= len;
c *= len;

so search fpr divisions, especially in time-critical code.

Share this post


Link to post
Share on other sites
What's fillrate ?

I have an Intel 82865G - I've downloaded the latest drivers for it - it's at opengl version 1.4

I'll try a (my) version of octree processing - I can't see how it would speed things up too much anyhow - I mean I've divided the terrain (180x180) up anyhow into a ten x ten grid where each grid contains 18x18 vertices and I only draw each 'square' if it's in the frustum.

Share this post


Link to post
Share on other sites
Fillrate is the number of pixels the GPU draws every second. Test if your frame rate increases if you lower the resolution to - say - 640x480 or even 320x240. If this is the case, you're fillrate limited. It means the GPU just can't draw things fast enough.

Share this post


Link to post
Share on other sites
Fillrate is the speed with which pixels can be processed. in optimal conditions you draw at most screenw*screenh pixels, but as polys overlap eachother there are probably a bunch of pixels drawn twice.

To optimize fillrate usage draw objects from front to back (once a pixel is tested to be behind an earlier drawn pixel at that location the process is stopped, at an early stage) and a few other optimisations listed in this (which has already been posted by _the_phantom_ in this thread) document.

Share this post


Link to post
Share on other sites
firstly everyone thanks for your time;

My spec is:

1.9 Gz,
128MB ram
Xp home,
Intel 82865G card 64 MB shared (at version 1.4 of opengl)
the Z buffer is at 24 bit (previously 16 bit - maybe I should move back to 16 bit)

VSync - I could never find this on my pc - I'm guessing it's on the control panel->device manger someplace - I'll check tonight - Apparently you can set vSync in opengl altough I don't remember seeing it in the red/blue books.

What's FSAA ?
What's antisotopic filtering ?
What's trilinear filtering ?
What should they be to speed things up ?

I'm at work at the mo' so can't do much till tonight, but keep the ideas coming.

So here's a list of things I'm going to try after checking the pdf given as well as your mails:


1. octree
2. occlusion - ie huge parts of my terrain maybe hidden as the camera can't see *into* the crator although it can see *past* the crator.
3.check no. of state changes
4.check use of doubles/floats
5.vertex rendering to be done sequentially (at the moment in order to get to the second row of vertices in my 'square' I need to add on the total number of vetices in a row to get to them)
6.sort objects front to back - and do occlusion culling
7. cut down on resolutions of textures if possible (although in my game for a test I removed the skybox and it didn't make a difference.


































Share this post


Link to post
Share on other sites
I realize that profiliing the actual OpenGL calls may not accurately reflect the time spent drawing; however, just because a particular application uses OpenGL doesn't make profiling it useless.

It will show you how much time is being used by the other portions of the program. Perhaps there is a function in the code that is using an inordinate amount of time due to a design flaw or a looping bug. Profiling will help you localize these types of inefficiencies. Maybe his terrain "chunker" or frustum culler is getting oout of control. Maybe he left a nasty debugging loop in there somwhere. Profiling will help you find these types of things easily.

I still stand by my reccomendation, profile then optimize, no matter what graphics API you're using or how well you think you know your code.

Share this post


Link to post
Share on other sites
No, I just create the D.L.s on intialisation then call them when I need them.

So I need to do the following:

1. VSYNC - can't find this parameter on the control panel->display either on my work pc or my home pc. Can you set it in opengl ?

2. What's FSAA and antisotopic ?? couldn't find them after searching here.

3. How do I do a profile build without spending $400 on the Intel thing. There seemed to be little on profile builds anywhere on the web for opengl.

4. forgot to say - the game runs well (double the speed) at work but then it has 1GB of ram !

cheers


Share this post


Link to post
Share on other sites
VSync won't do that much if your framerate is 16, FSAA and Anisotropic filtering slow down everything but i don't think that's something to care about, your app is too slow for what it does anyway, optimize elsewhere first.
Have you added any sort of quadtree alogrithm yet?

And what gfxcard do you have at work?

Share this post


Link to post
Share on other sites
Tree Penguin is right, I think, but here are some links anyway:

Quote:
Original post by ade-the-heat
1. VSYNC - can't find this parameter on the control panel->display either on my work pc or my home pc. Can you set it in opengl ?

wglSwapIntervalEXT

Quote:
2. What's FSAA and antisotopic ?? couldn't find them after searching here.

FSAA=Full Screen AntiAliasing
anisotropic filtering

Share this post


Link to post
Share on other sites
from what I can work out I have an Intel Extreme 82865G card at work and a pretty hot pc 2.7Ghz 1GB ram (I get 32 FPS in the places where I get 16 at home)- I can't work on the game at work as it's a personal game !

I'll have to try the Octree thing tonight.



Share this post


Link to post
Share on other sites
Do you use quads or quad/triangle strips? Triangle strips need the least AGP bandwidth, so use them if possible and if you aren't already using them.

Then try backface culling, so that polygons that face away from the camera don't get drawn. Using vertex dot products you can calculate the angle between the poly's normal vector and the vector from the camera to the poly. If it's over 90 degrees, it's facing away -> don't draw it.

glCullFace() (or something like that) can be used for backface culling too, but that happens after the vertex data has been transferred to the GPU -> won't help you with AGP bandwidth issues.

Hope this helps,
Richardo

Share this post


Link to post
Share on other sites
Quote:
Original post by RichardoX
Do you use quads or quad/triangle strips? Triangle strips need the least AGP bandwidth, so use them if possible and if you aren't already using them.

He uses display lists so that won't help much for bandwidth. However drawing will be much faster using triangle strips, especially when you draw a quad of terrain optimized to one triangle strip.

Quote:
Original post by RichardoXThen try backface culling, so that polygons that face away from the camera don't get drawn. Using vertex dot products you can calculate the angle between the poly's normal vector and the vector from the camera to the poly. If it's over 90 degrees, it's facing away -> don't draw it.

glCullFace() (or something like that) can be used for backface culling too, but that happens after the vertex data has been transferred to the GPU -> won't help you with AGP bandwidth issues.


Backface culling won't help much if the terrain is flat or near-flat, in fact it could hurt performance (using fragment programs or pixel shader or whatever it will certainly give you a speed increase as the cost of culling is easily outnumbered by the cost of unneccessery fragment operations).

If there are many back facing triangles it might be worth enabling it, anyway you can always try it.

Share this post


Link to post
Share on other sites
Can you post a screenshot of your program, or even an executable showing the problem? It doesn't sound like you're doing anything too taxing on the graphics card. However, you could be doing several things wrong in the rest of the program. For example, not using a quadtree could be a problem, if you're frustum-culling each chunk of terrain. Do you remember the last change you made before noticing low FPS?

Share this post


Link to post
Share on other sites
Well, I stuck loads of trace in with time got from
GetTickCount() which is rudimentary time thing from windows.
I found the following:

1. Terrain, even at it's most slowest only took 16ms to draw-I could speed up more so will do so.

2. bitmapped fonts took a few ms a frame to write a few things like bullets remaining/ direction/position/health which surprised me.

3. The big slow ups were in doing the DISPLAY LISTS.
I'm hoping this was because the timer is too crude although it does all seem to add up, eg if I add all the times up I get about 16 FPS

eg to draw a rather ordinary "machine gun nest" took 16ms if it was in the frustum - but sometimes it took virtually zero ms.
I took the time just before the display list call and just after - soemtimes it was zero ms and sometimes 16ms.

I think it's the timer that's wrong as whenever I do anything at all it's either 16ms or nothing at all.

Know any better timers anyone ?









Share this post


Link to post
Share on other sites

This topic is 4863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this