Custom texture manager and advanced texture cache handling

Currently it is not possible to override/enhance any of the TextureManager functionality. This makes texture cache handling unnecessarily complicated, as you have to populate and maintain another texture cache (or patch the engine locally).

It would make texture handling much easier if the texture manager was not a static object but a singleton and could be swapped for a custom texture manager.

For example:

a static method TextureManager.get() that returns an instance of the TextureManager class. And a static method TextureManager.setManager (TextureManager m) that allows to replace the default texture manager with whatever you want.

Writing and using a custom texture manager would allow for full control oven what textures are loaded into and unloaded from the video card and the main memory and when.

I'd suggest a generic resource manager with all of it's components modular with multi-threaded loading loading support and other features…

In fact I already made such a resource manager for my project  :slight_smile: If you want I'll post the code.

I would be intereseted in it Momoko_Fan

That too… still doesn't hurt to allow for swapping of the default texture manager with custom built one. I'm sure you had to patch the engine to make your TextureManager work. With what I'm proposing you wouldn't have to patch any of the engine files.

(And yes, I would love to have a look at your TextureManager too)

Certainly it would be a very useful to more closely manage the resources in the GFX memory - for instance the current TextureManager is mostly useful for loading textures rather than figuring out when it is possible to unload them etc.

And I'll surely join the group of people interested in Momoko_Fan's resource manager - always nice with some good ideas on how to face the problems posed in many of the larger projects.

If your game consists of a simple spinning box, then yeah forget about textures - not important.

How do you do it if your game is a little more complex ??? You dont want dead textures hanging around hogging memory on the GPU or RAM.

What are the needs of Textures - should there be cache states like remove never - remove when not referenced ??

A > A cursor for instance - the game may temporarily remove the cursor whilst loading up a scene and displaying a scene loading screen - but you as the developer know you will use the cursor again.

B > A billboard texture above a player character - when you are not in the area of that player - you as a developer do not want to cache that texture anymore and are happy to accept the overhead of recreating the texture if the player comes back in view.

C > A Tree, there may be more further down the road but is to expensive to calculate and that data isnt at hand.

In A > a state of never remove works.

In B > It unique - a simple remove state works

In C > Bit tougher, almost like you want to register components that use the texture - only remove the texture if there are no more components registered with it