Okay, so I'm working on my texture manager. I've come to the part where I rebind all the textures and changing various texture filters on a per-texture-basis. Of course this requires the pixel data... Should I leave the pixel data in memory or should I reload the image from disk everytime I change the filter on the texture?
I don't want to eat all the memory, but at the same time I don't want to eat the disk bandwidth.
Is this for a software type rendering system or more hardware-based? The answer to that question will completely alter my advice. So before going off on a tangent I need just a bit more info.
More hardware based. I don't actually filter the textures or anything like that myself (GL does).
And I need the pixel data to generate mip-maps etc? Unless I'm missing something.
My general idea is:
Where "texture" is a structure that stores the info about the texture (GL id), pixel data, resolution, bpp, overloaded filters, etcCode:texture_load(texture, path) Which calls, texture_load_from_disk(texture, path) texture_generate(texture) <- mip maps, texture filtering etc texture_unload_pixel_data(texture)
And the manager also tracks all the textures, so when it comes to rebinding all the loaded textures are reloaded from disk and texture_generate() called on each again. Or should I leave the pixel data in the struct? ie don't call texture_unload_pixel_data()?
Last edited by zacs7; 07-03-2008 at 07:58 PM.
Ok I'm not used to OpenGL. Direct3D and the D3DX library pretty much hold your hand through most of this process.
I would try to keep the data in memory and would avoid calling anything that would necessitate memory be de-allocated and/or re-allocated. Once you have the data in memory I would make every attempt to keep it there. The mip-map chains will not change as long as the texture is constant. Pre-filtering the textures is a good idea and I would store them in a simple linked list in the texture class. I would not recommend hitting the drive at all once you have started the engine unless it's absolutely necessary. It cannot be avoided completely since everything cannot fit into memory but the less you access the better performance you will get.
I've noticed in XP if the drive has been idle for some time and then you attempt an access there is a huge hit during drive 'spin-up'. This seems to happen even with power-saving disabled on the drive.
Hmm thanks, perhaps I'll give the user an option.
I've also noticed the drive spin-down and spin-up. Rather annoying. What I was thinking is, when you play a game like... FEAR for example. Then you go to options, turn off texture filtering etc, it then rebinds the textures (without filtering)? Would they be left in memory or pulled from disk. I might answer that for myself
Thanks for your help. Are there any books that actually teach you such guidelines? I've got plenty of books, that teach the API, engine design, collision detection, real time rendering etc... But none mention the little things as you have, otherwise I guess it comes with experience
And semi-related,
Would that not reduce disk life?I've noticed in XP if the drive has been idle for some time and then you attempt an access there is a huge hit during drive 'spin-up'. This seems to happen even with power-saving disabled on the drive.
Last edited by zacs7; 07-03-2008 at 10:15 PM.
Most books don't touch on this because it's not the flashy graphics that are fun to program. Yet every game must have some type of resource management system or it will fall apart very quick. The only book I've found so far that even touches this is Game Code Complete, 2nd ed. I wish there was more talk about this important topic but most just assume they can write a robust system. When you actually begin to design and then implement you begin to realize just how complex it can get. I finally had to create a custom templated array that always had O(n) access b/c none of the STL containers offered exactly what I needed.... Are there any books that actually teach you such guidelines? I've got plenty of books, that teach the API, engine design, collision detection, real time rendering etc... But none mention the little things as you have, otherwise I guess it comes with experience
It might but I disable it on all my drives. My 20GB Maxtor is still kicking. I'm about to kick it out of my box but it has been a great drive. With power save enabled on the drives I was noticing that games were throwing exceptions during loads and caches. One would have thought the game or the OS or both would account for the delay but apparently not.I've noticed in XP if the drive has been idle for some time and then you attempt an access there is a huge hit during drive 'spin-up'. This seems to happen even with power-saving disabled on the drive.
Would that not reduce disk life?
I think the swap file kills drives more than anything since it usually hits the same area during swaps. This can significantly affect the platters at this location. Windows still has this problem as evidenced by Diskkeeper's drive map. The swap file is contiguous and in the same relative area on all my drives. It probably has to be contiguous to be efficient but it's hard on your drive.
Last edited by VirtualAce; 07-03-2008 at 10:44 PM.
Well thanks for your help. Perhaps you'll write a book one day?
I will check out the book you mentioned, sounds like it could be helpful.
I certainly do not have enough knowledge or experience to even think about such a thing. I've learned from other books and don't have one single released game under my belt. The Gems series of programming books for games and graphics have some of the professional advice and algos. Other than that most of what is known in the industry is kept in the industry. IE: The real algos that make money and make the games we play usually aren't discussed on the internet.Well thanks for your help. Perhaps you'll write a book one day?
