Does it take longer to draw mipmapped images?
BlitzMax Forums/BlitzMax Programming/Does it take longer to draw mipmapped images?
| ||
| I've got an image that I want to show shrinking on screen and normally I load my images with the default flags of MASKEDIMAGE and FILTEREDIMAGE (for scaling up) but the docs say I should also use MIPMAPPEDIMAGE if I want to draw it scaled down. I recall hearing that one of these flags greatly increases the Video RAM used for a texture. Also I was wondering, would a MIPMAPPEDIMAGE be slower to draw than a normal image or is the "hard work" all done when it's first loaded? Also I draw a lot of my particles smaller than normal scale so perhaps I should use MIPMAPPEDIMAGE on them to make them look better, but not if it will slow them down... I know I could test this but just wondered if anyone had a quick answer. Thanks! |
| ||
| Mipmaps consume some memory, but can actually be faster to render. This is because they are more texture cache friendly. If you're drawing a scaled down mipmapped image, texels are frequently fetched from the same/similar areas of vram. But if you're drawing a scaled down non-mipmapped image, texels reads are much more 'scattered', resulting in poor cache performance. |
| ||
| Use mipmaps. Not using them is not only unlikely to result in any kind of perceptible speed increase in any realistic scenario, but is very likely to slow things down. That is, if you were rendering detailed 3D scenes with lots of textures. You're rendering some particles. You'll never see a difference in speed. But you will see a big difference in image quality. |
| ||
| OK thanks guys. So basically I should make all my particles mipmapped and anything else which is being scaled down. At some points I do have a lot of particles and my FPS drops from 400 to 200 so I'll see if the mimapped particles change that. |
| ||
| Grey: Your framerate probably drops when you have a lot of particles for the same reason it did in Blitz3D. State changes. State changes are things like telling the 3D card to change the texture being used to render polygons. I am not very knowledgeable in this area, but I think pretty much anything that changes the appearances of polygons counts as a starte change. Changes in color, alpha, or blend mode could all trigger a state change. And for all I know Max itself could strigger a state change for each image drawn on the screen regardless of whether or not you draw two identical images one after the other. But the point is, state changes, have in the past, when I was using Bltiz3D, been really expensive. I don't know how expensive they are on modern cards, but "I have lots of particles and my framerate dropped a lot" sounds exactly like the issues I was having with my old particle system in Blitz3D. 200 particles onscreen at once, and the framerate would drop to like 30fps. Of course this was on a card from six years ago. So 400fps down to 200fps might be the sort of speed change you see on modern cards for that. Something else to keep in mind is that if your framerate drops to half with X number of particles, then doubling the number of particles will make it drop by only half again. And you'd still be getting 100fps at that point. So that's something to seriously consider if you already have as many particles as you need. The rest of your graphics probably won't be nearly as gpu intensive as that initial batch of particles. Also, the difference between 400fps and 200fps may sound like a lot, but it's only 2.5 milliseconds per frame difference. That's 2.5 out of say 16 total available per frame, if you want to stay over 60fps. In short, you should mipmap them cause it will look better, but you're probably worrying needlessly about speeding things up at this point. |
| ||
| If you want to avoid state changes try using the TAnim code on these forums (somewhere). It uses a single texture with texture coordinates to display images (single-surface). |
| ||
| Thanks sswift. I basically don't know much about 3D cards you see, I just use BMax and hope that it's doing a good job (it seems to be). I actaully ran some tests on my game and got these results: 1) Game idle = 401FPS 2) non-mipmapped particles = 180/198 (2 tests, picked lowest FPS) 3) did not draw the particles = 323/329 4) mipmapped particles = 205/228 So basically my particle code costs around 75 FPS. That's OK though because my TParticle is a very flexible object and I don't want to lose the flexibility for speed. This 75FPS could of course go up on slower PCs.... The drawing costs around 135FPS or 110FPS when mipmapped. So that would appear to prove that mipmapped may be faster, it certainly doesn't harm performance. On some slower graphics cards this may drop. It's very easy for me to change the number of particles in the particular sequence I was testing so if it turns out to be too many for lots of slower PCs then I'll tame it down. OR I might actually run a little test when the game first loads to see the speed of the machine and then tune the particles accordingly, this would be cool, and a nice addition to the framework :-) My machine is 3 years old now, a P4 3.2 and a radeon 9800XT. So it was good in it's day and may still be better than a lot of budget PCs but it's certainly not up to date. Even if on some crappy laptops the odd frame is missed so FPS drops from 60Hz (I'll be using Flip1) to 30HZ it won't look bad due to the fixed rate logic and delta code catching up. |
| ||
| So how MUCH more memory do mimapped textures take? Should I load everything as mipmapped? |
| ||
| Mipmapped textures take approximately 1.33x as much space as a regular texture. 1 + 1/4 + 1/16 + 1/64 ... = 1 + 0.25 + 0.0625 + 0.015625 = 1.32815. It approaches 1.33x as you use larger and larger textures, but will never exceed that. And yes, you should, there is no reason not to, unless maybe you had a huge image to display and video memory was really tight, and you never planned to scale the image down, or was trying to get a retro look or something very special case like that. |
| ||
| Ah I understand now! Thanks very much, your wisdom knows no bounds (at least with regards to this subject ;-)). |
| ||
| There is another reason why particle systems actually can slow the whole thing down especially when use on regular office like systems which are assumed to be the "casual gamer market": Its overdraw ... if you draw again and again over the same spot, which is something that tends to happen with particle effects, this can cause some serious performance break ins on lower end cards and especially Intel GMA 900 and 950 with their inexistant fillrate. |
| ||
| yeah. But it's hardly worth writing a dirty rects system for them, I did that before in BlitzPlus and it was a pain. |
| ||
| Definitely :-) Its simpler to design particle effects with textures that have more than a single "blob" on for example and make it look like it has more particles than it has ... Gives double advantage: less overdraw and fewer particles to update That was one of the things where I think Indiepaths R2T module is of very large help ... updating a few different particle textures in pseudo realtime (tick based) and use them to create larger particle effects combining those dynamic textures. As the module renders to the texture instead of the backbuffer, the main bottleneck of regular Max2D dynamic textures is removed: grab and convert from pixmap to texture. (i just called it clustered particle system, don't know if this kind of effect has already a name ... sadly the system is of not much use anymore as I never updated it to newer BM especially since the DX side broke the R2T module by removing some needed functions) |
| ||
| Ah I see, sounds cool. |
| ||
| Dreamora's right. This is why even high end games often use big flame images for fire effects instead of making a fire out of many small particles. It's not just the updating, it's to cut down on the overdraw, and hence the fillrate requirement. Ever walked up close to a particle effect in a game and seen the framerate plummet? That's why. Because you haven't got more particles to update as you get closer, so it's not that. But you have got more overdraw and cranking up the fillrate. I think I'm right in saying that fillrate is the single biggest problem on modern videocards ( because the old state change problem is slightly reduced on modern videocards. It's why multipass shaders can be so expensive. |
| ||
| fillrate has ALWAYS been the problem even on old games, that's why dirty rects were so important, and every other trick in the book. Nowaways it's less relevent but you gotta watch the particle use for sure. |
   |