Jump to content
  • Advertisement
  • entries
  • comments
  • views

Restoring devices

Sign in to follow this  


I've just managed to implement device resetting in Orc. You can now alt-tab out and back in again.

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.
Sign in to follow this  


Recommended Comments

I don't get why you can't just lock a managed texture, build the sprite page in there and then not care about device resetting? You only need default pool textures if you're using them as render targets or updating them on the fly. If you're constructing everything up front then managed pool is the way to go.

Share this comment

Link to comment
Well, I initially tried changing the D3DPOOL_DEFAULT to D3DPOOL_MANAGED but when I did that, something failed in my texture initialisation, which I assumed was the LockRect call. Maybe I've got the wrong end of the stick somehow.

I create the textures like this:


I believe I need the dynamic flag in order to be able to lock and write to the surface. When I changed POOL_DEFAULT to POOL_MANAGED, it stopped working. If you can suggest where I was going wrong, I would be interested to know.

It's not a problem. I've implemented the second idea above now, saving a temporary copy of each texture and just loading them on device reset, then deleting them when the program terminates.

The way my sprite engine works, Orc only needs to create and manage two textures anyway, one for the tiled backdrop and just one other texture for all the other graphics in the game, so it is not a major issue here.

Share this comment

Link to comment
Right, I see. If you create a dynamic texture then you need to specify the default pool for efficiency's sake. However, if you just need to create a resource at application startup then you could create it in the managed pool and not specify the dynamic flag. Although it might be a bit less efficient on startup, it would mean you could use managed resources and not have to worry about the device lost situation.

Additionally, it would benefit you if you could arrange things so that you only lock the resource once and fill in the data for the entire resource in one go rather than using multiple locks. In the case of filling in a sprite texture page your best option would be to lock the entire surface, copy all the sprites for that page across, then unlock.

I hope that's clear and helps you some. Depending on your application it might not be appropriate, but it seemed to be from your description of the problem.

Share this comment

Link to comment
Oh, and to clear up another thing, your assumption:

"I believe I need the dynamic flag in order to be able to lock and write to the surface."

That's not the case. The dynamic flag is a hint to D3D/the driver that you're going to be updating the resource often at runtime, and the default pool indicates that you don't want a system memory copy (because otherwise d3d or the driver would have to ensure consistency between the vram copy and the system memory copy when you lock the surface, which could involve a slow readback from vram to system memory).

If your resources are only changed at application startup, or changed infrequently, then I'd recommend using a non-dynamic, managed pool resource. It will save you loads of hassle when you're handling the device lost issue.

Share this comment

Link to comment
Thanks. You're right. That all works fine and saves a lot of hassle. Rate++ for you.

I couldn't find anything to replace D3DUSAGE_DYNAMIC with so used 0. Is that correct, do you know?

Share this comment

Link to comment
Yes, passing in zero for the flags is perfectly valid.

Glad it works and makes things easier for you, thanks for the rate++ :-)

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!