Jump to content
  • Advertisement
Sign in to follow this  
neonic

Game engine running Really sluggish.

This topic is 4864 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 don't understand what I am really doing wrong, but something is god awful wrong with my game engine and I don't really understand it. I have a simple particle effect (based largely on the Nehe particle system, but I made it into classes) and just a large quad that is the "ground." All that I have done so far is set up the window, made a simple camera and some basic input routines. With my particle system (a 100 particle "fire") in view it runs so sluggish, I'd estimate about 20 fps and the controls are laggy too. I haven't added Collision detection or anything yet and it is absolutely horrific. Once the particle system is out of range it seems to be fine. I just don't understand what I am doing wrong. I mean looking at some of the commercial game engines run at 50 fps using 10 seperate particle systems on the screen at once (and all of them look better than mine.) I guess what I am asking is how can I optimize the effects. Is it because it is using software rather than hardware rendering? I don't even know how to tell if it is software or hardware. When you make a GL_QUAD, is it going to be rendered using hardware or software. I am sorry if this was difficult to read, I am just more than a little frustrated at this design right now.

Share this post


Link to post
Share on other sites
Advertisement
Well I haven't used OpenGL since college, but if you are rendering in software mode chances are it is going to be slow. How you check/change that in OGL, I'm sure someone else can help you.

It might be worth it to implement an actual frame rate counter, as things can sometimes be deciving. Maybe it's that the movement code for the particles is 'bad' and causing the illusion of poor frame rates.

You may also want to post some of your rendering code and some of you particle update code. I'm sure we can help you figure out where the bottle neck is.

Matt

Share this post


Link to post
Share on other sites
On a Windows-box you can check if software rendering is used, by calling:

char *renderer = glGetString(GL_RENDERER)
and check if something like GDI Generic is returned.

As to how to find out why your program runs slow, try profiling it. How to do that depends on your build environment. It should tell you in what part of your program most time is spent, and maybe identify your bottle neck.
Good luck.

Share this post


Link to post
Share on other sites
Also, remember to turn off any debugging code (logging or writing to system out) when testing performance.

Share this post


Link to post
Share on other sites
Quote:
I haven't added Collision detection or anything yet and it is absolutely horrific. Once the particle system is out of range it seems to be fine.

the problem is NOT to do with CPU etc thus col det will not affect it
heres whats happening

when the PS is close to the camera each particle takes up a large part of the screen but because depth writes are normally off the depth value is not written into the depthbuffer so the next particle u draw ignores the previous particles depthinfo + draws itself covering up the previous particle. so a high % of the pixels will get written to twice, multiply this by 100 particles + u have the chance that some pixels will get written to 100x!, contrast this with normal polygons where u have depthtesting + depthwrites on, in this case for each fragment only the closest one to the camera gets drawn the other 99 will fail the depth test + get thrown out. obviously writing the same pixel 100x vs 1 time is a lot slower.
the solution is to fade out (and eventually dont draw) the particle when it becomes to large onscreen.
check out the videos with my recent IOTD, if i didnt employ this technique the framerate would literally drop from 60fps -> 5fps when flying through explosions etc

also when u draw particles u normally enable blending (which is more expensive than normal pixels)

Share this post


Link to post
Share on other sites
You should try to freeze your simulation so that the render loop still refreshes but the code doesnt update the particle simulation to see if your bottleneck is CPU or GPU.

Share this post


Link to post
Share on other sites
Did you turn off alpha blending after you are done rendering the particle system? Why are you depth testing? They are particles, do NO depth test or Z/depth write. Turn all the depth stuff off when rendering you particles, the back on again after you are done. Also, don't forget to turn of alpha blending when you are done rendering partticles. Leaving that one will also hurt performance.

Share this post


Link to post
Share on other sites
if your texturing the particles be sure your not doing all the binding of textures into graphics cache each loop. I did this rather stupidly in one of my first OpenGL programs; once i found what was going wrong the frame jumped up to an acceptable level again.

Share this post


Link to post
Share on other sites
Another possiblity is that you are using GL_QUAD on hardware that doesn't support it. Try using a triangle strip instead, most hardware supports at least that.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!