Archived

This topic is now archived and is closed to further replies.

If you use c# and Managed DX, should read. Alt-tab related.

This topic is 4955 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Thank you. Actually, that may come in handy.

One thing I noticed that was interesting...

.. The C++ SDK (framework) samples can change mode and reset the device flawlessly.
.. The C# SDK (framework) samples will occasionally crash when the device is reset/changed.

So, they haven't even done a perfect job of making sure their samples reset the device yet... It seems like all the help and examples are not completely up to snuff yet.

I must say, though, I much prefer developing with Managed DirectX. It's much cleaner..




[edited by - The Frugal Gourmet on May 18, 2004 10:28:42 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by joaocorreia123
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.


If you read the docs:

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?



Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
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?


LOL! Incredibly vague. Are you kidding?

It may well be *technically* documented, but the .. er... "documentation" is nothing more than a list of properties and methods -- about 1/4 of which have vague explanations written out for them. Essentially, the only way to see "Releases all references to video memory resources and deletes all state blocks." and apply it in its appropriate context is to read through every single list of events, properties, and methods and piece together how a real application should work. Even after coming across this little tidbit browsing through the "documentation", only an experienced DirectX (or other 3D API) developer would be able to apply this information and even know what losing the device and resetting it meant.

*Normal*, well-written documentation -- which clearly this isn't -- would explain how to build, manage, and keep an application working in standard prose.

You may think the documentation is fine, but I submit that you were either an experienced 3D API developer to being with or you are a certified genius. In either case, congratulations.

However, I still think the 99% of managed DX users claiming the "docs" are merely a vague list of commands are spot on. This documentation sucks. Plain and simple. And no, this fella is not an idiot for not figuring how or why to reset a lost device from it.


[edited by - The Frugal Gourmet on May 19, 2004 1:41:55 PM]

Share this post


Link to post
Share on other sites
The docs definitely need a lot of work. But if you look at the methods on the Sprite interface, OnLostDevice should jump out at you when dealing with a Lost device.

The C++ docs cover the same ground and are a valuable resource.


Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
You know... In retrospect, I realize I went a little over-the-top in my response.

Oh well.. anyway.. my general feeling is still the C++ docs are the way to go for now, and definitely the SDK examples.. I do find the C# docs very sparse... If I had tried learning DirectX from them, I''m not sure I would have gotten very far. But there''s always the SDK examples too.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
At least you guys -have- documentation. VB users got the spiky end of the shaft where DX9 is concerned. I''m going to have to learn a new language if I want to use DX9.

Share this post


Link to post
Share on other sites