Jump to content
  • Advertisement
Sign in to follow this  
ade-the-heat

running out of ways of going faster fps

This topic is 5052 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
Advertisement
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
I gotta second what Palidine said. Profile then optimize. You may find that you've got some huge performace problems in areas that you wouldn't even think to look at otherwise.

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!