These changes should increase performance dramatically. In the profiler, the framerate more than tripled when I toggled the eliminate draw calls option! This means that at least 2/3rds of the frame time was spent in openGL calls!
Eliminating the background/foreground calls entirely (aside from the FPS tiles) left the FPS unchanged at 46 for me on a 200x150 grid map. I don't doubt it would help some people with cards worse with OpenGL than my laptop's Radeon X600 or other OpenGL trouble with drivers and all of whatever else, but I think it's important not to overstate the case here.
A lot of my FPS issues depend on what part of the grid is being viewed, which points to map drawing issues prior to the OpenGL code (fixing some of these yielded the 17 -> 36 change I mentioned up on dev for today). In the 46 FPS map I mentioned, it hits the 30s when I view the sky, since the display of tiles showing through from a level below are apparently a bit clunky. I'm running this on a single core AMD 2.59 GHz processor of some sort.
edit: (this is with the FPS displaying properly after fixing the bug that was causing render function call rates to be displayed instead)
That said, I can change some of the OpenGL calls around, though I'm not yet sure how to handle the bind calls. I've leery of the texture atlas -- DF's OpenGL text started with that, but it would always double up pixels at the edges of letters for some tiles in some BMPs and not others regardless of how I tried to fiddle with the texcoords and wrapping, though it has been years since I've tried. What I did today was some dirty rectangle stuff that cuts virtually all of the calls if the screen isn't changing much, though hopefully that won't introduce display artifacts (haven't seen any yet, but of course there will be trouble somewhere on some or all setups), and it's likely to become more expensive if layering is introduced as more 2D tiles come in, since it has to verify tens of thousands of tiles in the buffer (on large grids) or else track the world for changes closely and annoyingly. Again, I didn't really notice a change here, since the OpenGL calls aren't a bottleneck for me, but hopefully some people will be helped by it.
I guess I failed to go to bed at 6:30 like I wanted to... dammit.
Another big factor concerning OGL performance is likely how many of us are using Windows Vista, since the changes they made in the driver architecture which make OGL act as a wrapper for DirectX. Hence the question, how many of us with framerate problems are running Vista? I know I am.
Concerning your display artifacts with texture atlases, I feel your pain! texCoords are strange things, mostly because of the way they actually refer to the corners of texels, rather than the centers of the texels. If you were to just use the coords for these corners, you get unpredictable aliasing simply from rounding errors when the rasterizer is determining which texel is the correct one. The key thing here is to offset the texcoords by .5 texels inward from the outer edge of the bounding rectangle.
Hence, your texture lookups should look like this:
xCoord1 = (xTile*tileWidthInPixels+0.5)/atlasWidthInPixels;
yCoord1 = (yTile*tileHeightInPixels+0.5)/atlasHeightInPixels;
xCoord3 = ((xTile+1)*tileWidthInPixels-0.5)/atlasWidthInPixels;
yCoord3 = ((yTile+1)*tileHeightInPixels-0.5)/atlasHeightInPixels;
.....
In this case, I'm just showing the coords of the upper left and lower right vertices. The other two are done the same way.
Author
Topic: [39f] FPS drops with increased screen size (Read 4697 times)