Proper Storing/Loading of Textures?
Author
I've been searching the net and having a lot of trouble tracking down information on proper storing and loading of texture files.
I'm currently working on a non-3D isometric game, but am having very slow load times with large animation sprite sheets. A single unit uses 6 sheets (front,back,left-front,left,left-back,poses) sized at 2048x2048, ~2.0mb PNGs. It's possible that I can cut the size down a bit, but not by much without losing frames of animation.
Not only are they slow to load, but the sheets also seem to take up a very large amount of running system memory--I'm worried that having more than a few units loaded at a single time will create an unplayable environment (Task Manager reports something like ~350,000 memory usage with just 4 entity (24 sheets) loaded).
My method of storage and loading is placing all textures as embedded resources in a .DLL. I pass a hashtable to a static function in the .DLL which loads all of the textures (using Texture.FromStream). The hashtable is then refrenced for all draw calls so that they may find their required texture.
What is the best method for me to use with these texture files? I feel as if my current method is at the heart of the trouble, but cannot find any solid data out there on .PNG storage and loading.
Thanks in advance,
Cyric
Well I would switch to .dds if I were you, there are various DXT formats providing various amounts of compression (look at the DirectX texture tool with the SDK) and you can use freely available plugins for Photoshop. One of the great advantages with these formats is that they are compressed by the video card hardware as needed so the compression advantage is maintained right up to the final part of the pipeline.
What's happening is that you're loading the PNGs, but they're being decompressed upon loading. This means that 24 2048x2048 textures will take up about 384MB of memory if kept in an uncompressed, 32-bit-per-pixel format.
Try using texture compression. 24 2048x2048 textures are big, no matter how you look at it, but using compressed textures (such as DDS - there is a DirectX Texture Tool that comes with the SDK that you can use to convert to compressed DDS) can drastically reduce the amount of memory consumption. Most video cards handle hardware compression very well.
Dammit, trip beat me to it! :)
Try using texture compression. 24 2048x2048 textures are big, no matter how you look at it, but using compressed textures (such as DDS - there is a DirectX Texture Tool that comes with the SDK that you can use to convert to compressed DDS) can drastically reduce the amount of memory consumption. Most video cards handle hardware compression very well.
Dammit, trip beat me to it! :)
Are there any optimizations you can use? For instance, use the same sprite for opposite frames and just draw it backwards. That would cut up/down left/right to just up and left. Same with diagonals. How about reducing the quality? Maybe you don't need frames as large as they currently are (I don't know how large they are, but maybe you could stretch them).
Author
Quote:Original post by Supernat02
Are there any optimizations you can use? For instance, use the same sprite for opposite frames and just draw it backwards. That would cut up/down left/right to just up and left. Same with diagonals. How about reducing the quality? Maybe you don't need frames as large as they currently are (I don't know how large they are, but maybe you could stretch them).
I'm already flipping Left, Left-Front and Left-Back to get Right, Right-Front and Right-Back; that's why it's only 6 sheets instead of 9. Each cell is 128x128, which fit the world dimensions perfectly, so I really want to avoid shrinking the image and scaling it up on the fly.
I'll try the .DDS today--I have a feeling this will solve the majority of my problems. I had heard people speak casually about .PNG compression and such, but never any mention of textures and .DDS together. Must be one of those things that is assumed to be known, but new DirectX users have trouble picking up on.
Author
I converted 30 of my animation sheets to .DDS, and they appear to work okay (load quickly and do not take nearly as much system memory), but it did hurt the graphic quality some when I converted (used DXT5 format--is this the best choice for this sort of work?).
After fiddling around, I discovered that I could actually load the original .PNGs with DXT5 compression (using TextureLoader with Format.DXT5) without having to convert them to .DDS first. It appears that they actually use about 25%-30% less system memory with this method, but for some reason there is quite a lot of constant background processing going on, even when the game is idle.
Could anyone explain this background processing (and what appears to be a small memory leak) that comes with loading the .PNGs as compressed textures? Is there any way to avoid this problem besides changing to .DDS, as it would be very nice to simply load .PNGs without having to convert all my textures to .DDS files?
Cyric74
After fiddling around, I discovered that I could actually load the original .PNGs with DXT5 compression (using TextureLoader with Format.DXT5) without having to convert them to .DDS first. It appears that they actually use about 25%-30% less system memory with this method, but for some reason there is quite a lot of constant background processing going on, even when the game is idle.
Could anyone explain this background processing (and what appears to be a small memory leak) that comes with loading the .PNGs as compressed textures? Is there any way to avoid this problem besides changing to .DDS, as it would be very nice to simply load .PNGs without having to convert all my textures to .DDS files?
Cyric74
Letting the driver compress the textures results in worse image quality than doing it as pre-process offline.
My guess is that the driver first just converts the textures to 16 bit uncompressed, and then compresses the textures in the background when you ask for compressed textures, because the compression process is pretty slow.
You might want to ask yourself if you really need sprites that are that large (128x128), and if you really need as many animation frames as you're using. If the answer is "yes" to both, then you probably want to look into loading and rendering the models as true 3D models, rather than use pre-rendered sprites. The memory usage is very easy to calculate, and if someone has a 32 MB graphics card, of which 8-12 MB goes to desktop and back/front buffers, well, ...
My guess is that the driver first just converts the textures to 16 bit uncompressed, and then compresses the textures in the background when you ask for compressed textures, because the compression process is pretty slow.
You might want to ask yourself if you really need sprites that are that large (128x128), and if you really need as many animation frames as you're using. If the answer is "yes" to both, then you probably want to look into loading and rendering the models as true 3D models, rather than use pre-rendered sprites. The memory usage is very easy to calculate, and if someone has a 32 MB graphics card, of which 8-12 MB goes to desktop and back/front buffers, well, ...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
