   [MDX/C#] Toggling Fullscreen (Is This Okay)?
  Well, I decided to do some more work on my MDX engine, using C# VS .NET 2005. Now, I've gotten to the point where I want to add fullscreen/windowed mode toggling, using the 'F1' key press.Now, here is how I am currently doing it (and it works):private void ToggleFullscreen(){    fullscreen = (!fullscreen);   // Toggle fullscreen flag    // Dispose of and "delete" D3D device in engine object    engine.d3dDevice.Dispose();    engine.d3dDevice = null;    InitEngine();   // Re-initialize engine}'InitEngine()' is a method in 'MainForm' (the form I render to), and it initializes the engine, including creating a device, PresentParameters, etc. So basically I'm "re-starting" the engine. Is this a safe way to toggle fullscreen/windowed? Or is there something to do it for me, that I'm missing? LoL.Thanks in advance,    Matt U.   
  If it works for you fine, then it should be. Maybe you'll want to get some tests in your paint event or wherever you do rendering, ie if (device != null) just to be on the safe side   ;  Thanks. =) But do you mean to check for 'null' on the device before I render, just in case it tries to render while the device is 'null'? If so, I already do that. =)   ;  Yup... or i better way i think is to catch the DeviceLostException. When you catch it you need to wait for the device to be ready for reset. Once the device is reset you'll need to recreate all non-managed resources.A few good keywords to look up:Device,DeviceLostException,Device.Reset,But for your question, i'm not sure you really need to recreate everything on fullscreen toggling, i was assuming we just need to make sure render target is valid (right size/format), same for projection matrix. But im not completly sure about this.;  As LowRad pointed out, it may be more efficient to call device.Reset(PresentParams) rather than to recreate the device and all resources. If you have a sizable number of resources in the managed pool, these will be implicitly recreated with more efficiency than you'd get by manually creating new ones.However, if you call device.Reset you will still need to recreate any resources in the default pool yourself, as well as setting any renderstates and the world/view/projection matrices. So from this point of view, I'd stick with your implementation if it works for you. It's a bit cleaner since you'll know you get a 'fresh start' each time, as long as you make sure you're disposing of any device-bound resources before you create the new ones.   ;  Hi remigius,Can you confirm me if i was also right about the RenderTarget size. Or is this only when resizing a window (in windowed mode of course)?Thanks in advance,Jonathan   ;  When you reset or recreate the device, you have to pass in a new set of PresentParams there, so you can use these to specify the size & format of the backbuffer. Afaik, you do not have to set any RenderTarget explicitly, unless of course you are using one for a fullscreen postprocessing effect like glow.For fullscreen mode you indeed need to make sure the resolution you pick is supported, but you can easily get around that by using the System.Windows.Forms.Screen.PrimaryScreen.Bounds rectangle. This contains the current resolution of the primary screen, so this way you know for sure it's supported and it will prevent any annoying desktop resolution switching. When resizing in a window, you can just use the client area of your control as the size for the backbuffer.As for the format, to be completely on the safe side, you'd have to check if a format is supported in fullscreen (I believe windowed mode is a bit more forgiving here, converting formats as needed). If you're targettting reasonably recent hardware though, it's quite safe to assume it supports the X8R8B8G8 backbuffer format.   ;  Reset will set the new created back buffer as the render target additional it will destroy the old back buffer. That’s the reason why you need to request it again (in the case you need it for a effect) after a reset. In the unmanaged world you are not able to reset the device as long as you still hold a reference to a back buffer. I am not 100% about the managed world because even there you should dispose all resources that are in the default pool before you reset the device. If you use the event system of managed DirectX you can do this in the device lost event because it will even called in the case you have forced the reset.In general a reset is the fastest way to switch between full screen and window mode. But sometimes it is possible that a reset does not work. Because of this it is a good choice to include some code to destroy and recreate the whole graphics system as a fallback. ;Quote:Original post by DemirugIn general a reset is the fastest way to switch between full screen and window mode. But sometimes it is possible that a reset does not work. Because of this it is a good choice to include some code to destroy and recreate the whole graphics system as a fallback.This is interesting, i am also in the process of implementing the ToggleFullScreen method into my renderer. I've read MSDN and they say: "If a call to Device.Reset fails, the device is placed in the "lost" state."So i'm assuming that the best way to implement what your saying is simply trying to Reset the device then check if CheckCooperativeLevel return true. If it returns false, it safe to assume that we didnt successfully change Windowed/FullScreen mode and we must handle a lost device then call the fallback system.Note: You were also right about non-managed resource in MDX.Quote:From MSDNBefore calling Device.Reset for a device, an application should release any explicit render targets, depth stencil surfaces, additional swap chains, state blocks, and Default resources associated with the device....Pixel shaders and vertex shaders survive Device.Reset calls for DirectX 9.0. They do not need to be re-created explicitly by the application.Humm, is it serious if i add more questions to a thread i didnt start? I mean, its closely related.Thanks,Jonathan   