Infinity X Speed issues
It seems rather odd to have speed issues already, but I’ve figured out why. I knew it had something to do with the minimaps I added, since that caused the fps (frames per second) to go down from 50-60 to 10-15. Yah, not good. At first thought it seems inconceivable for just two small parts to slow it down that much, but then I’m drawing tile per tile, so I’m drawing 64×64 (in other words 4096) tiles to create the minimap, and I do that twice. It still seems like a low number (knowing most recent games have 3d models each containing 10-20,000 polygons each), but it’s more than the 500-1000 I was thinking of. It’s been a while, so I’ve had some time to think of possible solutions, and I’ve come up with three (so far).
First is simple: Just draw the minimap occasionally. Say every 10 frames. It’s simple to implement, and effective. On the down side, of course, is that in our example you’d have 9 fast, responsive frames (pertaining to AI, mouse movement, animation), then one slow frame. The second is more complex. Since I want it to be pretty mod-friendly, I refuse to ask the modders to create a thumbnail of their map. You could, however, draw the minimap when you load the map’s data, and in theory you’d never have to draw it again. Well that would be true except the map might have various effects applied to it: darkened areas where you can’t see (not enough scan), etc. Most of these would be vastly simpler if you drew tile per tile, and some would require you to do so (in which case any performance gain you expected is gone again). So -while it’s a good idea- it’s not useful here. Third, which i’m now leaning towards, is partial updates per frame.
Partial updates per frame? Yep. Divide the minimap into squares (say four by four), and draw one square each turn. With the current map (64×64), this could mean you would draw one 16×16 tile square on the minimap every frame, for a 16 frame rotation. So first you’d draw the top left 16×16 tiles, the second frame you’d draw the 16×16 tiles to the right of those, third frame 16×16 tiles to the right of those and the fourth frame the 16×16 top right tiles. Fifth through eighth frame you’d draw the second row, and so on. Unfortunately, this method may have it’s problems as well. With the simple “map -> minimap scaling” I’m currently using, there may on occasion be a square with a ‘leftover’ pixel to the right or bottom. If it’s to the right, it would be visible for that one frame (and be overwritten by the 16×16 tiles you draw the next frame); if it’s to the bottom, it would be visible for four frames until the 16×16 tiles to the bottom of it are drawn. This only happens because the way I draw now (which turns out to be quite wasteful) is… complicated. First I calculate the amount of pixels it should be wide, then the pixel destination. Both these numbers are in floats (”real numbers, such as 2.5, 3.000, -25.1″). These numbers are then converted to longs to be applied to the screen (longs being whole numbers such as 2, 3, -25). I’m not quite sure how the 64×64 map gets mapped to the 160×160 minimap though, and I’m not really ready to test it with a different map (say 256×256 or 1024×1024).
Aside from that, I also appear to be calling the ID3DXSprite::SetTransform function for each and every minimap blit. Hell, I think I do it for every blit… I heard somewhere the SetTransform function is slow (and calculating the matrix for it each time can’t help either). I’d check it out right now but I desperately need some sleep, so see you tomorrow.
