Quote:Original post by penwan
If anybody sees anything glaringly wrong, be sure to let me know
if (fullscreen == IsFullscreen()) return SUCCESS;if (fullscreen) { // Set Fullscreen} else { // Set Windowed}Quote:Original post by Rockoon1
Certainly if development is being done with it as a windowed application, then there is no big reason to take advantage of exclusive mode unless performance has become a concern.
I'd go with a maximized window with no border or title bar as the "full screen" option given to the user.. the end user doesnt care how its implimented.
if (device lost){ for each resource { if resource needs to be reseted { release resource released_resource.push_back(resource); } } if (reset device ok) { for each resource in released_resources recreate resource }}Quote:To the above poster: it's actually not *that* hard. Look in to the SetWindowLong and SetWindowPos Win32 API calls. (Essentially you use SetWindowLong to modify the window's style parameters and then SetWindowPos to make sure that Windows actually recognizes the changes). Of course, you also have to make sure to reset the D3D device.I know the API calls (thanks to MSDN) but I always get weird glitchy errors when changing the window style of a Direct3D window. (I've never actually tried to change the style of a NON-D3D win.) Has anyone done this successfully?
Quote:You make it sound like OpenGL solves everything and is free of all problems. While it does solve some of the aforementioned issues, it definitely has issues of its own.Of course it does. But I've heard that OpenGL handles more of the resource management than D3D does (I don't do OGL programming). I know, both of them are just 3D APIs.
Quote:Direct3D doesn't expect anything. It works perfectly fine if you have a WS_OVERLAPPEDWINDOW style, but you'll still be able to interact with the title bar, which can cause problems.True, but you should NEVER have a fullscreen app that uses a WS_OVERLAPPEDWINDOW style. Not only does the title bar create problems, but also the corners are rounded in WinXP (so you could accidentally click on the window behind your game window).
Quote:Switching back and forth between windows styles is pretty trivial. It does require a slight hack to get back to the WS_OVERLAPPEDWINDOW, but nothing major. I don't have the time at the moment, but I'll dig through my library for a snippet later.That is the problem I always encounted. I've never been able to switch back to a W_OVERLAPPEDWINDOW style. If I remember correctly, the window stops resoponding (I need to look over my code more, maybe I created some weird eternal loop with the window procedure or something).
Quote:Use managed resources. Not a single resource that I create needs to be reset when I alt-tab out of my application. It may not be the most efficient or best way to do it, but it's easier and it's worked perfectly so far.I use managed resources as well. But then you still need to reset all of the device states/settings, which can be annoying. Also, if you have any D3DX resources (ie. fonts or sprites) or cursor stuff then it needs to be done manually (I think).
Quote:Original post by ouraqtQuote:To the above poster: it's actually not *that* hard. Look in to the SetWindowLong and SetWindowPos Win32 API calls. (Essentially you use SetWindowLong to modify the window's style parameters and then SetWindowPos to make sure that Windows actually recognizes the changes). Of course, you also have to make sure to reset the D3D device.
I know the API calls (thanks to MSDN) but I always get weird glitchy errors when changing the window style of a Direct3D window. (I've never actually tried to change the style of a NON-D3D win.) Has anyone done this successfully?
Quote:Original post by ouraqtQuote:You make it sound like OpenGL solves everything and is free of all problems. While it does solve some of the aforementioned issues, it definitely has issues of its own.
Of course it does. But I've heard that OpenGL handles more of the resource management than D3D does (I don't do OGL programming). I know, both of them are just 3D APIs.
Quote:Original post by ouraqtQuote:Direct3D doesn't expect anything. It works perfectly fine if you have a WS_OVERLAPPEDWINDOW style, but you'll still be able to interact with the title bar, which can cause problems.
True, but you should NEVER have a fullscreen app that uses a WS_OVERLAPPEDWINDOW style. Not only does the title bar create problems, but also the corners are rounded in WinXP (so you could accidentally click on the window behind your game window).
Quote:Original post by ouraqtQuote:Switching back and forth between windows styles is pretty trivial. It does require a slight hack to get back to the WS_OVERLAPPEDWINDOW, but nothing major. I don't have the time at the moment, but I'll dig through my library for a snippet later.
That is the problem I always encounted. I've never been able to switch back to a W_OVERLAPPEDWINDOW style. If I remember correctly, the window stops resoponding (I need to look over my code more, maybe I created some weird eternal loop with the window procedure or something).
if(!Fullscreen) { SetWindowLong(WndHandle, GWL_STYLE, WS_POPUP); PresentParams.Windowed = false; GuiManager.PreDeviceReset(); D3DSprite->OnLostDevice(); DeviceComPtr->Reset(&PresentParams); GuiManager.PostDeviceReset(); D3DSprite->OnResetDevice(); } else if(Fullscreen) { SetWindowLong(WndHandle, GWL_STYLE, WS_OVERLAPPEDWINDOW); PresentParams.Windowed = true; GuiManager.PreDeviceReset(); D3DSprite->OnLostDevice(); DeviceComPtr->Reset(&PresentParams); GuiManager.PostDeviceReset(); D3DSprite->OnResetDevice(); int Width = PresentParams.BackBufferWidth, Height =PresentParams.BackBufferHeight; int WindowX = 0, WindowY = 0; int WindowWidth = Width, WindowHeight = Height; RECT WndRect = {0, 0, Width, Height}; AdjustWindowRectEx(&WndRect, WS_OVERLAPPEDWINDOW, false, 0); WindowWidth = WndRect.right - WndRect.left; WindowHeight = WndRect.bottom - WndRect.top; GetWindowRect(GetDesktopWindow(), &WndRect); WindowX = (WndRect.right / 2) - (WindowWidth / 2); WindowY = (WndRect.bottom / 2) - (WindowHeight / 2); MoveWindow(WndHandle, WindowX, WindowY, WindowWidth, WindowHeight, FALSE); ShowWindow(WndHandle, SW_HIDE); ShowWindow(WndHandle, SW_SHOWNORMAL); }Quote:Original post by ouraqtQuote:Use managed resources. Not a single resource that I create needs to be reset when I alt-tab out of my application. It may not be the most efficient or best way to do it, but it's easier and it's worked perfectly so far.
I use managed resources as well. But then you still need to reset all of the device states/settings, which can be annoying. Also, if you have any D3DX resources (ie. fonts or sprites) or cursor stuff then it needs to be done manually (I think).
Quote:The corners aren't necessarily rounded, it depends on the theme. But despite that, when you create a full screen device I'm pretty sure the window is maximized (And maximized windows don't have rounded corners. But I'm not positive that it maximizes the window.) Anyway, you're right and you should never create a fullscreen device for a window with a titlebar.I suppose it does depend on the theme (most people just use Luna), however you should never assume the user will have a particular theme anyway.
Quote:Yes, I have and it works fine, although I don't use SetWindowPos().I think you should use SetWindowPos(...) so Windows will update the window cache.
Quote:True, I didn't actually think about that, but I usually don't use D3DX interfaces (ID3DXLine, ID3DXSprite, and ID3DXFont.)So what do you draw text with? I suppose you could make your own text-drawing engine, but that would take forever! You must be a real D3D guru. I don't really use ID3DXLine much, but what about ID3DXSprite? It makes drawing sprites (and particles!) much easier. You hand-code all of this yourself?
Quote:This is the code I'm using at the moment. It works fine on all the computers that I've tested it on (6 if I remember correctly.)I'll look at it and see if it works for me. I think the source of my glitches was a poorly programmed message loop. You always have to remember to avoid calling your WinProc from within your WinProc. Many Windows dunctions will inevitably call your window procedure without telling you first (which could easily make your app hang).
Quote:Original post by ouraqtQuote:The corners aren't necessarily rounded, it depends on the theme. But despite that, when you create a full screen device I'm pretty sure the window is maximized (And maximized windows don't have rounded corners. But I'm not positive that it maximizes the window.) Anyway, you're right and you should never create a fullscreen device for a window with a titlebar.
I suppose it does depend on the theme, however you should never assume the user will have a particular theme anyway.
Quote:Original post by ouraqt
Also, I made a fullscreen FPS demo with a WS_OVERLAPPEDWINDOW window. The corners were still rounded. If you want a window maximized, you have to do it yourself (but you should be using WS_POPUP anyways).
Quote:Original post by ouraqtQuote:Yes, I have and it works fine, although I don't use SetWindowPos().
I think you should use SetWindowPos(...) so Windows will update the window cache.
Quote:Original post by ouraqtQuote:True, I didn't actually think about that, but I usually don't use D3DX interfaces (ID3DXLine, ID3DXSprite, and ID3DXFont.)
So what do you draw text with? I suppose you could make your own text-drawing engine, but that would take forever! You must be a real D3D guru. I don't really use ID3DXLine much, but what about ID3DXSprite? It makes drawing sprites (and particles!) much easier. You hand-code all of this yourself?
