Jump to content
  • Advertisement
Sign in to follow this  
medevilenemy

Display Lists, other ways to speed up code

This topic is 3836 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

Hi, I've recently been working on a new game project (a full 3D space shooter/adventure game) and I've been noticing some relative slowness in the engine... As of right now, the program draws one 3D model of ~500 vertices and 20,000 "stars" in the starfield (they are rendered way out in the distance as small untextured quads). I have just put the starfield drawing code into a display list and yielded a boost of ~8 to 10 fps so i'm getting around 45fps at the moment. I have a single point light and some ambient light being applied to the 3D model (only one model at the moment for testing of ship control code). Are there any good ways to boost execution speed? My Dev Machine Specs: Thinkpad T61 2.0 Ghz Core 2 Duo 1GB DDR2 Intel Integrated Graphics

Share this post


Link to post
Share on other sites
Advertisement
Quote:
20,000 "stars" in the starfield (they are rendered way out in the distance as small untextured quads).


Is that 20,000 individual draw calls or a single draw call with 20,000 quads?

If it's 20,000 individual draw calls, that's likely to be what's sapping your performance. Each draw call has a CPU overhead inside the graphics API and the device driver for the GPU. Depending on the driver (AFAIK, OpenGL isn't my main area), each entry in the display list can still equate to an individual draw. Each time you recreate the display list there is also CPU overhead (to translate from the generic OpenGL command into the hardware specific command).

But that's still a guess - the only way to know for sure is to profile your application with both a CPU and a GPU profiler to find where the bottlenecks are.

Share this post


Link to post
Share on other sites
Wow, I really should have noticed that earlier. It was 20,000 different draw calls each one with a glColor4d() call. I just changed it into one draw call with one glColor4d() call for a speed boost of about 10fps. Its not pretty consistent around 60fps (which means a system with a reasonable graphics card will probably get far more -- I'll test on my desktop and check).

Thanks a lot for that suggestion. I probably never would have noticed that myself. Any other suggestions?

Share this post


Link to post
Share on other sites
Wow, Just for anyone who doubts the value of a proper vid card over integrated graphics:

Execution Speed on Dev Machine: ~60fps
Execution Speed on my Desktop: ~280fps

Desktop Specs:
Athlon XP 3200+
1GB DDR
Radeon 9700 pro

Share this post


Link to post
Share on other sites
Quote:
Original post by medevilenemy
As of right now, the program draws one 3D model of ~500 vertices and 20,000 "stars" in the starfield (they are rendered way out in the distance as small untextured quads).

If they are rendered "way out in the distance" then why not just use a texture? Or is the distance not big enough that the stars effectively form a background? Then perhaps it would make sense to draw a map with stars very far out and only render 10% as quads?

Share this post


Link to post
Share on other sites
I've thought about that, but for that to actually work (if I'm imagining this right) the starfield would actually need to be a huge textured sphere in order to get a proper view of the starfield (I have a 6dof camera). Also, I wanted to capture that really nice "twinkling" of the stars as you move and turn, which my current method provides. I may at some point switch over to a textured system if I decide to make the starfield more complex (nebulae and such) as those would require some rather complex particle effects to look good if rendered dynamically. Thanks for the suggestion, though.

Share this post


Link to post
Share on other sites
Quote:
Original post by medevilenemy
Wow, Just for anyone who doubts the value of a proper vid card over integrated graphics:

Execution Speed on Dev Machine: ~60fps


Have you ruled out vsync?

Share this post


Link to post
Share on other sites
Why didn't you use glPoint? If they're far away it could work well, and it's gonna be 3 less calls... Or you can use triangles too, it's only 1 call less but it's free, and if they're small you won't notice any difference.

If you plan using extensions, take a look on vertex arrays, they are way faster. And you can try the point sprite extension too, it's only 1 call (glpoint) and you get a full textured quad ;)

Share this post


Link to post
Share on other sites
I think I'll start by changing them to triangles and seeing what kind of impact it has. I may look into glpoint as well if I can find the time. Thanks for all the great ideas everyone! I'll post the results here for reference.

Share this post


Link to post
Share on other sites
RESULTS: With triangles instead of quads, framerate is up to ~65fps with the ship in the camera scene, and ~75 with the ship out of the scene.

[EDIT:] Could someone perhaps post a link to a reference for glPoint? I can't seem to find it.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!