1) The ui becomes offset and to be able to interact with the UI elements you need to move the mouse to some odd place.

The ui becoming offset could suggest that your viewport is wrong. So just for safety you could set the viewport straight after you change its size ..

Device11.ImmediateContext.Rasterizer.SetViewports(viewport);

But when you say that you need to move the mouse to some odd place. hmmm.. Can you put up some screenshots of that ? Is the place where you have to click where you would expect the element to be if it were being rendered in the correct place ? That might suggest that you ui code is wrong, either rendering or hit detection, but maybe not as well.

3) Normally, when you put any program into a FULLSCREEN mode your mouse is unable to leave it, but with our game... it can... why?

I can move my mouse to the second display when i switch to fullscreen mode, so I would say that it's normal behaviour. I used to know how to handle that issue with XNA, but I haven't yet worked it out with SlimDX. I think how I did it in XNA was actually just monitor the mouse position and limit it to the window bounds with a setmouseposition() function. I'll look into this for both of us.

However, it looks like you only set the client size of the window when in windowed mode. I'm pretty sure it's necessary that you also set the size of the window when in fullscreen mode. ResizeBuffers will only resize your backbuffer; it's probably get squashed back down to fit on the form surface.

I don't set the window position in fullscreen mode, and I'm pretty sure it works properly. Edit - checked this, and because I'm using SwapChainFlags.None it just adopts the desktop resolution. Just learnt something about resizing the 'front buffer' ... I tried setting the form manually, but that just won't work, it can and will ignore the width height values you pass in. Instead, use

swapChain.ResizeTargets()

Which will also resize your window, and fire a Resize event, so that your backbuffers can adjust.

1) The ui becomes offset and to be able to interact with the UI elements you need to move the mouse to some odd place.

The ui becoming offset could suggest that your viewport is wrong. So just for safety you could set the viewport straight after you change its size ..

Device11.ImmediateContext.Rasterizer.SetViewports(viewport);

But when you say that you need to move the mouse to some odd place. hmmm.. Can you put up some screenshots of that ? Is the place where you have to click where you would expect the element to be if it were being rendered in the correct place ? That might suggest that you ui code is wrong, either rendering or hit detection, but maybe not as well.

3) Normally, when you put any program into a FULLSCREEN mode your mouse is unable to leave it, but with our game... it can... why?

I can move my mouse to the second display when i switch to fullscreen mode, so I would say that it's normal behaviour. I used to know how to handle that issue with XNA, but I haven't yet worked it out with SlimDX. I think how I did it in XNA was actually just monitor the mouse position and limit it to the window bounds with a setmouseposition() function. I'll look into this for both of us.

However, it looks like you only set the client size of the window when in windowed mode. I'm pretty sure it's necessary that you also set the size of the window when in fullscreen mode. ResizeBuffers will only resize your backbuffer; it's probably get squashed back down to fit on the form surface.

I don't set the window position in fullscreen mode, and I'm pretty sure it works properly. Edit - checked this, and because I'm using SwapChainFlags.None it just adopts the desktop resolution. But when I try to set the window Bounds or Size (using RenderForm) it ignores any width/height values i send it, and will rather set the window to 640x480 then fire another Resize event, changing the size to 1920x1033, and it still looks like it's in 640x480, this is all from a request to the form to change to 1920x1080. So ... I don't know how that should work.

1) The ui becomes offset and to be able to interact with the UI elements you need to move the mouse to some odd place.

The ui becoming offset could suggest that your viewport is wrong. So just for safety you could set the viewport straight after you change its size ..

Device11.ImmediateContext.Rasterizer.SetViewports(viewport);

But when you say that you need to move the mouse to some odd place. hmmm.. Can you put up some screenshots of that ? Is the place where you have to click where you would expect the element to be if it were being rendered in the correct place ? That might suggest that you ui code is wrong, either rendering or hit detection, but maybe not as well.

3) Normally, when you put any program into a FULLSCREEN mode your mouse is unable to leave it, but with our game... it can... why?

I can move my mouse to the second display when i switch to fullscreen mode, so I would say that it's normal behaviour. I used to know how to handle that issue with XNA, but I haven't yet worked it out with SlimDX. I think how I did it in XNA was actually just monitor the mouse position and limit it to the window bounds with a setmouseposition() function. I'll look into this for both of us.

However, it looks like you only set the client size of the window when in windowed mode. I'm pretty sure it's necessary that you also set the size of the window when in fullscreen mode. ResizeBuffers will only resize your backbuffer; it's probably get squashed back down to fit on the form surface.

I don't set the window position in fullscreen mode, and I'm pretty sure it works properly.

1) The ui becomes offset and to be able to interact with the UI elements you need to move the mouse to some odd place.

The ui becoming offset could suggest that your viewport is wrong. So just for safety you could set the viewport straight after you change its size ..

Device11.ImmediateContext.Rasterizer.SetViewports(viewport);

But when you say that you need to move the mouse to some odd place. hmmm.. Can you put up some screenshots of that ? Is the place when you have to click where you would expect the element to be if it were being rendered in the correct place ? That might suggest that you ui code is wrong, either rendering or hit detection, but maybe not as well.

3) Normally, when you put any program into a FULLSCREEN mode your mouse is unable to leave it, but with our game... it can... why?

I can move my mouse to the second display when i switch to fullscreen mode, so I would say that it's normal behaviour. I used to know how to handle that issue with XNA, but I haven't yet worked it out with SlimDX. I think how I did it in XNA was actually just monitor the mouse position and limit it to the window bounds with a setmouseposition() function. I'll look into this for both of us.

However, it looks like you only set the client size of the window when in windowed mode. I'm pretty sure it's necessary that you also set the size of the window when in fullscreen mode. ResizeBuffers will only resize your backbuffer; it's probably get squashed back down to fit on the form surface.

I don't set the window position in fullscreen mode, and I'm pretty sure it works properly.