How fast is sprite rotating?
BlitzMax Forums/BlitzMax Beginners Area/How fast is sprite rotating?
| ||
| I know in the past, rotating a sprite seemed to cause real FPS problems, but it doesn't seem to be much of an issue on a modern PC. I'm working on an overhead shooter where every sprite is rotated, every frame, and am wondering if I should optimise that? The only way I can think of is to make 360 copies of each image and pre-rotate them at the start of the program, then use those images instead. I'd test this myself and check the FPS, but I don't actually know how to make the pre-rotated images. Presumably I take the initial image, draw it, rotated, to some buffer, then grab it from there? Been looking through the docs but can't find the correct commands. I suppose the question is, is it worth it, or is rotating so fast now that it won't even speed up the program? |
| ||
| Rotating is so fast now that optimizing it won't even speed up the program. If you're curious as to "why", each image in BlitzMax is represented by a 2D, pixel-perfect quad geometry that is supplied to the GPU (i.e. the graphic card). The GPU doesn't care what shape you supply to it, so sending something that is completely rotated or completely aligned poses no difference. The same for scaling*. What does pose a difference: • The amount of shapes you send (relates to the amount of 'drawcalls'). • The quality of those shapes (relates to bandwidth, the amount of polygons in the shape and the cost of pixel and vertex shaders). • Other state changes (having hundreds of different blend modes used every frame, or changing texture for every single sprite - texture size doesn't impact performance but the changing from one to another does). So you can rotate and scale as much as you will. Post that shooter later on, on the Blitz Showcase! :) (and listen to this.) *One could argue that scaling does affect performance in that it can potentially affect the fillrate - a big sprite covering the entire screen with some sort of blending is much more expensive than a sprite scaled down to a single pixel. Last edited 2012 |
| ||
| Thanks Kryzon, good answer :) Lol at the link, not sure why you wanted me to listen to that, but it's very nice! (Fun games too) I am very interested in the details. I like programming little games just for fun, and I've had an idea which I think will be quite fun to play, so as a project, I'm going to try to program it on BMAX and Monkey at the same time - mostly as a learning project for myself. I have noticed in recent years - especially since I got this new PC, which is very powerful, that throwing huge amounts of sprites at the card doesn't seem to bother it at all. In my BMAX test, I had 10,000 small sprites spinning around without dropping below 60fps. Even with 100,000, it's still running at 28 fps. For someone who remembers programming on a ZX Spectrum.... well this just makes me feel old xD I should read up on the way new 3d cards work, because I'm probably making mistakes in trying to avoid slow-downs. For example, for a scrolling starfield, would it be faster to have a bunch of tiled images (say 256x256) or just have 1000 pixels/small star images moving around? I had the idea that tiled images would be faster since it's only printing 10 or 20 of them, but when you consider the size of them, compared to a pixel, maybe the pixels are faster? This might be a slightly different issue though, where it's less work for the 3d card but more for the CPU? |
| ||
| Maybe you don't need to use BlitzMax. Monkey can build for desktop too. Don't have several images for the stars - even with them being small, each one would need a draw call which is very expensive. You're better off using big square textures, like a combination of 1024 and 64, so you can reach a vertical resolution of 1080 with minimal waste of memory (like you would waste if you went straight with 2048). Consult the GPU's "max texture size" value: In case it's lower than your biggest texture (say, 1024), you can downscale the image through software and then load that buffer as a texture that's appropriately sized. |
| ||
| It doesn't matter if it rotates or not, the rotation is handled by matrix multiplication on the graphics card no matter what the angle is. |
   |