aclysma

I am trying to figure out exactly what the content manager does and does not do for you. Here's what I've found.

The content manager caches resources
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=886913&SiteID=1

The content manager does not help you load resources in a background thread
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=966705&SiteID=1

And, from what I can tell, though I've not found anything very conclusive, the content manager will take care of device resets. I've not been able to get this to happen though. Right now, I can move my game from one monitor to another and a texure is invalidated.

This is how I'm making the texture..

tex = env.Content().Load<Texture2D>(@"content/tex/white_pixel");
ResourceManagementMode m = tex.ResourceManagementMode;

m is "Automatic" after execution. The ResourceManagementMode property is read-only.

Any clue on why it's giving me a problem Do I need to call something on the content manager when the reset happens Or link it to the event of the GraphicsDeviceManager

Thanks


Re: XNA Framework ContentManager questions about device resets

BlueG

The content manager does cache resources. It does load the resources using the thread you call it from.

If you're careful and smart about it, you may be able to do this from a seperate thread, but doing so is risky seeing as how many of the resources need to make calls to the graphics device while buidling themselves.

The content manager does not deal with device resets. Device resets are handled by the graphics device. It recreates any resource that is assigned to the automatic pool.

I believe that the reason you can't move a resource from one monitor to another is that the device is associated with an adapter and monitor. You would have create a new device on the new monitor and reload the content.






Re: XNA Framework ContentManager questions about device resets

Shawn Hargreaves - MSFT

This post has some good info on the difference between automatic and manual resource pools, and what happens when the device is reset versus recreated:

http://blogs.msdn.com/xna/archive/2006/09/18/761355.aspx





Re: XNA Framework ContentManager questions about device resets

aclysma

From the docs:

"Resources are copied automatically to device-accessible memory as needed. Managed resources are backed by system memory and do not need to be recreated when a device is lost. Managed resources can be locked. Only the system-memory copy is directly modified. Direct3D copies your changes to driver-accessible memory as needed."

The docs make it sound like xna magically handles whatever train wreck the graphics device gets itself into, in particular that the resources don't have to be recreated when the device is lost (which, I assume, is the same as having to be recreated). But this sounds contrary to what you say and what Shawn's link appears to say. Am I getting confused on terminology




Re: XNA Framework ContentManager questions about device resets

Shawn Hargreaves - MSFT

Device lost and device recreated are different things. Automatic pool resources will survive device lost, but need to be recreated any time the device is recreated.

Device lost happens in many places: when you change resolution, tab away from a fullscreen app, lock the terminal, etc.

Device recreated only happens in extreme circumstances, like dragging a window onto a different monitor (which as far as the driver is concerned might as well be a totally different graphics card so it has to start everything over from scratch).





Re: XNA Framework ContentManager questions about device resets

aclysma

Thanks, that's exactly what I needed to know. I really appreciate that you guys take the time to help out on the forums - it's very good to know that there's help not too far away!

I'm very curious to know why the device recreate is not handled when the device lost is. It seems like it wouldn't be that hard to implement both if you already have one implemented. I'd be curious to know why the decision was made to support one and not the other. Is it because the recreate is expensive It seems like you'd be forced to pay for it no matter what, at least in the vast majority of situations.

Thanks again!




Re: XNA Framework ContentManager questions about device resets

BlueG

When you ask why the device recreate is not handled when the device is lost, you're talking about two different things.

When a device is lost, you don't have to recreate it, you just have to restore any data that it had on the graphics adapter. That's basically what it means when a device is "lost": it's data was overwritten on the graphics adapter because the graphics adapter was needed for something else. So, to remedy this, the application has to recreate that data in the graphic adapter's memory. When you use the Automatic memory management mode, XNA hides this from you by creating a copy of the data in system memory and then copying that data back to the graphics adapter if the device becomes lost.

What's important to understand here is that a device is associated with a particular graphics adapter where it stores the data to be rendered. That's why moving from one adapter to another is difficult (even if they are really the same adapter with two monitors, they behave as two seperate adapters). Of course, that doesn't answer why the copy in system memory can't be used to recreate the data on the new adapter. I suspect (from my C++ programming in DirectX) the reason for that is that there is no guarantee that the two adapters support the same formats and, even when they do, there may be differences in how they are stored in memory.

Although, usually this isn't a huge issue if you want to recreate your resources manually, it may be fairly complex to implement in a general API such as Managed DirectX and XNA, due to the shear number of formats available. Though, the MS guys could probably speak to that point better than I can.






Re: XNA Framework ContentManager questions about device resets

Jon Watte

In the DirectX based framework I was noodling around with before deciding to check out XNA, my framework handled device-lost and device-recreated the same way. The game code would just specify what kind of content it wanted ("a texture size XXX" or "a model named YYY"), and the framework would provide a handle to it. Whenever the device changed, the necessary resources would be de-allocated and re-allocated/re-loaded as necessary -- even when the device was totally re-created.

Some API nazis might say that "if you ask for an fp16 texture on one device, and it works, it may not work on the other device, therefore your approach is not workable," to which I reply "if you try to do something that doesn't work, it won't work -- but the user will notice, and move the window back as necessary. Meanwhile, the game code is still blissfully unaware."

It's too bad that XNA didn't move up to this level of abstraction, but you can't get everything.





Re: XNA Framework ContentManager questions about device resets

BlueG

It is a maybe scenario that the in system texture would need recreated as well

Personally, I never had a problem with it. But, then again, in C++ I always stored the textures in memory in a generic format and then did the conversion necessary to move them into device memory as needed. But, mind you, that was always with games that were small enough that the textures could all be stored simultaneously in device memory so I didn't need to recreate them in device memory for other reasons. I'm not sure that I'd want Microsoft to do the same in thier API, though. I suppose it wouldn't matter too much since manual management is always an option if it created a bottleneck...

Who knows, though Maybe it'll be in XNA 1.1






Re: XNA Framework ContentManager questions about device resets

aclysma

The c++ wrapper for dx that I used wrapped all resources in smart pointers. It handled losing and recreation of devices, and cleared resources when all instances of the same cached texture went out of scope. I very much valued deterministic loading/unloading of graphics resources without me having any direct envolvement. It also handled loading in background threads.

I'm very disappointed that XNA is a step backwards from what I had in directx in this respect. In fact, I really consider that device recreates aren't handled when device lost is handled as a defect. I see very little benefit to having device lost handled for me when device recreate isn't. Once I have my resource in a variable, I don't want to care about it anymore.

Recreates are only, as you said, in extreme cases like moving from monitor to monitor. Someone who has dual monitors is probably a power user anyways and if the game drew weird textures, they'd probably do the obvious thing - move it back to the monitor it worked on. There might be other cases where recreate would have to be handled, but it just seems like so little extra work to make it handled automatically when device lost is.

If the next xna release handled this, I'd be absolutely ecstatic. It would mean one less thing for a beginner to grasp when first starting out and one less thing for me to worry about in the future.