Hello all First let me rumble a little around something that is bothering for quite a while now. The MDX docs are ...well... to be nice.... non-existant. Have you read the IsUsingEventHandlers page? It is probably one of the biggest changes on the summer update, and microsoft has not bothered to properly document it. Now that i have that out of the way, let me tell you a little story about a guy who spent the best part of 5 days to pinpoint a little (big) error that happened on his game, when he went to fullscreen, out and then back again. Everything would crash with an "invalidcall exception". Nice. The debug information was even better. "You must release all state blocks". Great! As soon as i use one, ill be sure to release it! Now, that guy went on and started commenting out pieces of code, until he commented out a nice Sprite interface part, and it suddenly worked. So the problem MUST be sprite related. After trying and turning and setting flags like DontSaveState and such in the sprite interface, to no avail, that guy started looking elsewhere. He found something related to an event he must catch with a "cancel" parameter: protected void CancelResize(object sender, System.ComponentModel.CancelEventArgs e) { e.Cancel=true; } and a Device.DeviceResizing += new System.ComponentModel.CancelEventHandler(CancelResize); somewhere. Nice! Everyone said that was it. And it must work! N O T ! So, to make a long story short, i had Device.IsUsingEventHandlers=false, it crashed whenever i used the sprite interface complaining about a state block not release when i had none, and it ignored my event handler. As soon as i changed IsUsingEventHandlers=true, everything worked out flawlessly. So world, do yourself a favor and set your Device.IsUsingEventHandlers=true. Microsoft should really document this stuff better. And the Sprite interface too. It appears some state blocks are used, and then they arent released properly when alt-tabbing into the app. The change relating to IsUsingEventHandlers introduced in the Summer Update broke my program, and i had to set it to false to make it work again. I had forgot all about it since then, since i use mostly managed stuff i dont want to care about recreating. It was probably the last thing i looked because it was inside a #region directive, and i overlooked it for quite some time before trying it. <\NewRumbling> I hope someone can learn from my mistake. Sorry for the time taken, Peace, Joao Correia correia _A*T_ irc d_o_t ubi d_o_t pt

IOW, the not-managed resources (POOL_DEFAULT) like textures, sounds etc., are lost. You have to call Device.Reset() and/or Sprite.Reset() and then reload the resources.
This is also in C++.

There will be a new/updated version of the Managed DirectX documentation when 9.0c comes out. (I think)

--
You''re Welcome,
Rick Wong
- Google | Google for GameDev.net

quote:Original post by DrunkenHyena
....
OnLostDevice - This method should be called whenever the device is lost. Before the object can be used again, the device must be reset and the Sprite.OnResetDevice method called.

Also, on that same page:
"Releases all references to video memory resources and deletes all state blocks."

What is vague about this?
...

Ok. I might have not made my point clear enough on my first post.

There is nothing (well, actually there is ALOT) wrong with *that* documentation in particular, but regarding the Device.IsUsingEventHandlers property, its mostly non existant, plus there are no (have i missed any?) examples regarding it.

And nowhere is said that the sprite interface uses state blocks.

Plus, the error i had was regarding those same state blocks wich are not mentioned to be allocated.

Plus, even if i made things "the micro$oft way" and used an event handler to deal with a Device.Resizing event (just to cancel it!), that "micro$oft way" is ignored because the Device.IsUsingEventHandlers was set to false. Looking back now, i probably should have checked that first, but i didnt. And the debugger complained about the sprite interface. If i commentend out the sprite interface part entirely, it would work just fine! So what is not correctly documented is the D3DXSprite + Device.IsUsingEventHandlers interaction. (or is buggy, because if you set Device.IsUsingEventHandlers to false, on the single documentation line regarding it, is said it is done automagically, which is clearly not done).

I hope its clearer now, unlike the docs.

Peace,
Joao Correia