I noticed something odd recently: while a (very) simple level might run at well over a hundred frames-per-second, my combat mechanic’s separate “world” ran at only around seventy frames-per-second, despite being very simple itself.
I did some profiling (hence my recent desire for a copy of PStats), and saw additional time spent in both “*->Bounds” (I think that it was) and rendering.
After some experimentation, I found that a single object seemed to be responsible for most of my trouble: the floor.
If I edited its shader to simply output pure white, the frame-rate jumped up to well over a hundred frames per second.
Curiously, a similar effect could be achieved simply by changing the texture-scale applied to it: it seemed that the more often the textures were repeated, the lower the frame-rate became. (Albeit that it never dipped below sixty, as I recall.)
The floor in this case is a simple model of thirty-three vertices (I think that it was). It has binormal- and tangent- vectors, and a material, albeit with no textures applied. Vertex colours cause it to dim at its edges, so that it fades into the black background colour.
When the combat “world” is shown, this floor is assigned two textures via calls to “setTexture”: a colour-texture, and a normal-map. It’s scaled, because for whatever reason I made the original model huge. A texture-scale is applied to the default texture-stage–the value is chosen for the given textures so that they tile as intended.
I also apply a shader-input called “texTransform”, which takes the result of “floor.getTexTransform(TextureStage.getDefault()).getMat()”, and which is updated each frame. This, alongside per-frame alterations of the object’s H-angle and texture-offset, is used to produce a floor that, while always centred beneath the player, nevertheless shifts its texture to represent the player moving about an ostensibly-larger surface. (Thus allowing a pretty-much unlimited “combat area”.)
The shader itself is for the most part pretty simple, save for applying “texTransform” to the uv-coordinates.
I’ve tried using a simple card for testing purposes, but with mixed results. (For one thing, I didn’t get normal-mapping to work; I’m guessing that generated cards lack binormal- and tangent- vectors.) However, what results I did get seemed to support the idea that repeating the texture resulted in poorer performance.
I could really use some help in figuring out why this is a problem, and what to do about it, if anyone has any thoughts.