Textures and Memory
Hi gang,
Okay, I don''t understand something. I need 2048 textures. Each one is 200x200 texels. The bit depth of these textures will vary with the user''s current mode, but, in the worst case, at 32 bpp, this is a total memory requirement of 327,680,000 bytes, or 312.5 MB! Even at 16 bpp, that''s still going to be 156.25 MB.
Now, that''s insane. Of course, when I try to set this up, the computer thrashes the hard drive something fierce, and the frame rates drop to a crawl.
Is trying to set up such a large number of textures at once unreasonable? I didn''t think so. Don''t other games do this all the time? If so, how do they do it?
Ron
What exactly do you need that much texture for? Well, whatever the reason, in a single frame hopefully you won''t need to display all of the textures you''re trying to allocate all at once. So perhaps you could just allocate the textures you need for a particular frame(s) and then deallocate, reading in and allocating the textures depending upon the requirements of your current scene.
- Pros
http://codepost.com/interact
- Pros
http://codepost.com/interact
isn''t real-time texture allocation going to slow down the game anyway? I man to allocate and dealocate textures every frame....that would (theoretically) slow down the game...I could be wrong on this.
But I was going to ask this same question...my short term solution is to just check the level of my game and allocate the textures that are needed for that particular level.
But if you need all 2000 textures in the same level, then that''s a problem...hope someone can answer this one. I''m curious
But I was going to ask this same question...my short term solution is to just check the level of my game and allocate the textures that are needed for that particular level.
But if you need all 2000 textures in the same level, then that''s a problem...hope someone can answer this one. I''m curious
![](smile.gif)
Only load the textures that will be needed for the current level. If you need them all, you have to sacrifice some of the textures. You''ll have to make the smaller and/or use less. When I start a project, I work with the artist, and set resonable limits. We sit down with a calculator, a pen, and a sheet of paper and then based on the minimial requirements, we split up memory and the artist have to work with what they are given. They complain at first, but since they have input, they know I''m doing the best that I can, and we all work with it.
Domini
Domini
Domini Miracle Man Studios
I once tried to tackle a similar problem, I had about a few hundred MB of textures in a single level.
However, the actual number of textures in view was quite a bit less.
I handled it by creating a texture cache in memory. This cache used straight LRU for texture replacement. While this caused it run smoothly, there were still annoying jerks when a batch of textures had to be loaded from disk.
I handled this by creating another cache, for textures that I predicted would be needed. This cache was filled by a background thread.
When I got a miss in my primary texture cache, I checked the speculative cache, and if that missed, I went to disk.
However, the actual number of textures in view was quite a bit less.
I handled it by creating a texture cache in memory. This cache used straight LRU for texture replacement. While this caused it run smoothly, there were still annoying jerks when a batch of textures had to be loaded from disk.
I handled this by creating another cache, for textures that I predicted would be needed. This cache was filled by a background thread.
When I got a miss in my primary texture cache, I checked the speculative cache, and if that missed, I went to disk.
You may also want to try compressing some of the textures in memory. A simple compression algorithm like the RLE used in PCX files may be able to decompress fast enough.
Domini
Domini
Domini Miracle Man Studios
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement