Bit of a pain really and would have been easier to implement from the start. I'll know in the future [smile].
The problem is that because I need to lock the textures to load my sprite file format, I have to create them with D3DPOOL_DEFAULT, not D3DPOOL_MANAGED, so I have to reload the textures when I reset the device.
Due to the lack of foresight on my part, I've now had to duplicate a small amount of code. I've now ended up with stuff like LoadClasses() and ReloadClasses(), where if I'd planned this from the start, LoadClasses could have probably called ReloadClasses() as part of its implementation.
I'm considering an alternative at the moment. Once a texture has been fully loaded at the start (which involves placing loads of smaller textures on a big one, for those of you not following this journal), I'm wondering if it would be worth giving the texture class a CreateBackup() method, that writes the texture data to a temporary file somewhere in Orc's directory structure.
When resetting the device, the texture could restore itself from this temporary file, circumnavigating the need to do all the texture atlas processing and recreating the texture co-ordinate vector. The temporary files could then be registered with a system that deleted them when the game exits.
Actually, I quite like the sound of that. I'm going to go and see if I can implement that instead.