Spring RTS Engine

Hey. \o

I noticed that I get a hefty FPS drop as I zoom into an unit or a building that is under construction. While I normally may have an FPS of 150-200 with luaui and luarules enabled, it goes down to 30-60 when my whole screen is filled by the building project and especially when the one-color texture starts to fill the wireframe mesh.

When I disable luaui and luarules, framerate does get a considerable increase, but the ratio of FPS difference between zoomed in and zoomed out remains roughly the same - that is, from 3 to 5.

Putting /debug on, I noticed that the time spent in SwapBuffers gets a considerable increase. I'm unsure how relevant this is, though, since in an reproduction of the issue by one other person, SwapBuffers staid lowish.

I'm using Spring 0.95 and running Linux with nVidia GTX 650. Drivers I use are the latest stable nVidia propiertary drivers.

If I were to throw a guess, I'd imagine the culptrit to be a heavy fragment shader.

EDIT: I was going to be proactive and go have a glance at the fragment shader. But quite frankly, I can't figure out which it is, and wouldn't know if I can replace individual shaders in the installation without compiling whole thing from source..

In your spring install, there is a base/springcontent.sdz, inzip it springcontent.sdd. You will find all the shaders in /shaders. You can then modify these in place.

More info at: CUnitDrawer::DrawUnitBeingBuilt

If you are unsure of what preprocessor directives get passed to it, and you are on windows, then I recommend getting nvemulate.exe from nvidia, which will allow you to dump all the shader sources and assembled assembly files to the root of your spring install.

Edit: the way the under construction seems to work is that is draws the model up to 3 times based on buildpercent left, and uses clipping planes. This easily explains the 3x drop compared to having just one unit in your full view.

Combination of factors:

1) part of the nanoframe is rendered through the FFP and in GL_LINE mode which may not be implemented in hardware
2) another part is drawn with FFP clip planes which don't mix well with vertex shaders

Okay, I'd go and make an educated guess that the fixed function pipeline and GL_LINES doesn't have proper support on the current Linux nVidia drivers - that would also explain why some other games are oddly heavy that aren't on many others and shouldn't be on this hardware.

Thanks anyhow.

Could you test with the config setting atihacks enabled? That seems to disable the clipping planes, and you can then see if its caused by the clipping planes or the 3x overdraw.