Undoubtedly shonky.

Cirian · 2002-06-18T22:52:38

I''m currently about to optimise my engine, and am hoping to get some suggestions from the all powerful members of this forum The fact of the matter is: my engine code produces some terrible framerates. I''m at a loss to know exactly where to start optimising it -- and the entire engine architecture is to blame in some respects. Out benchmarking program generates 500 static objects, and one particle emitter of 500 objects. The all share the same texture. This, it should be noted, is a 2D engine. All the objects are quads. The framerate is calculated right at the end of the program, and although marginally lower than the actual fps, it is pretty accurate (successful calls to render loop / engine uptime). Framerate with all bells and whistles on: 19 fps Framerate with no alpha blending: 22 fps Framerate rendering with glPolygonMode(...,GL_POINT): 25 fps Framerate with no drawing code (everything other than glCallLists/glBegin - End): 85 fps Framerate with nothing on the screen: 300+ fps I have forayed into the world of vertex arrays (for the particle system), but the framerate when rendering as a vertex array is 3-4 fps less. I have disabled vsync, and although my 3D card (a TNT2 Ultra) is a bit on ye olde side, I do get about 120 fps in Quake III arena. As I said before, the engine architecture is, in many ways, to blame; static objects each have their own display list, and between 4 and 8 operations are carried out on each of them, per frame. The particle array is drawn in immediate mode, simply because it gave a silly performance boost over vertex arrays. Objects are held in std::list containers, and each object executes its own Draw() function. A partcle array is a single object with multiple polygons. The app is not running in software mode, and I have the latest drivers. I know that something very screwy is going on, and I am going to do a complete overhaul of the rendering subsystem in the next few days. I would request any ideas for improving performance, although it is undoubtedly hard for you to contribute without any source code, please do try... Also, I will answer any questions about the rendering loop that you want, and will post code snippets if asked (I''m not posting all ~5000 lines in one go, sorry =) --Cirian

Graphics and GPU Programming Programming

Started by Cirian June 08, 2002 08:41 AM

28 comments, last by Cirian 21 years, 10 months ago

Yann L

1,806

June 09, 2002 09:31 AM

quote:
Remember the image is being drawn 500 times, if that makes any difference.

If you use a higher texture resolution, then it will get slower (due to cache misses), but a 64² texture is virtually nothing for a 3D card. I would expect a larger performance drop when going from 32² to 2048², but not in his case. It will of course affect fillrate, but since his app is far from being fillrate limited, the problem is somewhere else.

freshya

122

June 18, 2002 02:47 AM

Umm.. here is some alarming evidence that would _suggest_ the app is fillrate limited:

500 objects (quads) are being drawn. Four tests are shown here, each with exactly the same number of objects, calculations, etc. The only difference is tests 2 and 3 have a call to glScale(4.0f); and tests 3 and 4 use a texture with transparency. Frame rate is measured here in Hz.

1.
tex => flame.bmp (square image, no transparency)
size => 16x16
Hz: 134

2.
change size => 64x64
Hz: 34

3.
change tex => lumiere2.png (square image, with transparency)
change size => 16x16
Hz: 127

4.
change size => 64 64
Hz: 30

Is this much of a jump _really_ to be expected?

Cirian

122

Author

June 18, 2002 02:51 AM

We also completely converted the Particle Arrays to use glInterleavedArrays / glDrawElements. Our framerate is identical to immediate mode. To see if there was a bottleneck within the particle update calculations, I disabled updates after 200 frames. The framerate changed marginally, getting us an extra two fps when no operations are performed other than the glDrawElements code.

[edited by - Cirian on June 18, 2002 3:58:29 AM]

CaptainJester

523

June 18, 2002 06:35 AM

Are you using lighting? If so, turn it off to see what happens.

---
Make it work.
Make it fast.

"Commmmpuuuuterrrr.." --Scotty Star Trek IV:The Voyage Home

"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]

Cirian

122

Author

June 18, 2002 08:23 AM

Nope, no lighting.

Dark Rain

157

June 18, 2002 09:56 AM

I remember that a friend of mine mentionned he had horrible FPS in a similar projects because Quads werent HW accelerated on his card. Might want to check that out.

Indie MMORPG developer blog

ANSI2000

122

June 18, 2002 01:29 PM

Are you calculating your fps correctly?

Neosmyle

144

June 18, 2002 05:58 PM

quote:Original post by ANSI2000
Are you calculating your fps correctly?

LOL...that would be the funniest thing ever, but I doubt it, as anyone can tell what 20 fps looks like -- HORRIBLE, among other reasons.

freshya

122

June 18, 2002 07:11 PM

The frames per second is simply a counter that increases once per frame, and then if 1000 mseconds have passed, it saves that result as the current Hz and resets the counter. Very simple stuff, but easy to implement.

EDIT: oh, and converting from Quads to Triangle Fans or Triangle Strips did not result in any change in frame rate.

[edited by - freshya on June 18, 2002 8:16:35 PM]

Cirian

122

Author

June 18, 2002 10:52 PM

There is also a second counter that logs *all* the frames rendered and divides it by the uptime when the app closes.

Undoubtedly shonky.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Undoubtedly shonky.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines