would you support a windowed-mode pro game?
Author
I have a somewhat subjective question (more or less) to ask:
Would you pay money to buy a game which could only ran in windowed mode, with no fullscreen exclusive option?
Here's my situation: I am in my third year of development on my game, which I intend to publish/sell for profit. I am writing this in DirectX, by the way.
If it were possible, I would like to leave out fullscreen-exclusive mode in my game because it would shorten development time. This is because fullscreen-mode (in Direct3d, at any rate) can at times be fraught with issues. Video-card specific issues, like the shifting around of D3D resources, problems with RenderSet calls, and such. These are issues that I quite frankly do not have the experience, tools, or hardware to handle. I am pressed for time, also. I am already about a year behind schedule with this game.
I should let you know that the game does work fun in fullscreen mode on my own computer - it's just that I am almost sure that strange problems would come up if I were to try running the game in that mode on any other computer.
I realize that leaving out fullscreen-exclusive mode would be an act of laziness on my part, but I have very limited time in which I can work on this project, and I'd like to simplify production as much as I can.
Thanks in advance for any input!
-synth_cat
Unless your game is really small, the switch between windowed mode to fullscreen mode shouldn't be that big of a hassle. HOWEVER I am aware of the blunders of DirectX! Direct3D expects you to have a WS_POPUP window for fullscreen mode, and a (*usually*) WS_OVERLAPPED (or similar style) window for windowed mode.
Switching between window styles is not easy to do in Windows, and it screws a lot of things up. So do we need to create 2 windows for this? I'll leave it up to you to figure out (I'm trying to figure this out myself!). Look at the way DXUT does it.
In addition to these problems, there's a butload of resource management issues that we need to take care of when eg. the user Alt-Tabs or presses the Windows key. When the device is lost, practically all is lost. All device states and settings need to be reset, many resources need to be reloaded (or OnDeviceLost(..) or whaever).
Maybe we should all switch to OpenGL.
It all depends on the type of game. For a FPS, I would expect fullscreen mode.
Switching between window styles is not easy to do in Windows, and it screws a lot of things up. So do we need to create 2 windows for this? I'll leave it up to you to figure out (I'm trying to figure this out myself!). Look at the way DXUT does it.
In addition to these problems, there's a butload of resource management issues that we need to take care of when eg. the user Alt-Tabs or presses the Windows key. When the device is lost, practically all is lost. All device states and settings need to be reset, many resources need to be reloaded (or OnDeviceLost(..) or whaever).
Maybe we should all switch to OpenGL.
It all depends on the type of game. For a FPS, I would expect fullscreen mode.
I would typically expect full-screen mode in most games, but it depends on the type of game. Is this a top-down RPG? Windowed mode is fine. An RTS? either or. A FPS or first-person RPG? Anything immersive I prefer to play fullscreen, in general.
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.
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 really think that it depends on the kind of game. For something like Bejewelled, it would be fine. If you are writing the next blockbuster FPS, it would probably be best to go with the option of windowed or fullscreen.
EDIT - If you want, I will be happy to post some C++ code that I have used in the past, that has worked for me. It handles pretty much any resolution, 0, 2, and 4x multisampling, vsynch (on or off), and a few other things.
EDIT2 - It loosk like penwan beat me to it.
EDIT - If you want, I will be happy to post some C++ code that I have used in the past, that has worked for me. It handles pretty much any resolution, 0, 2, and 4x multisampling, vsynch (on or off), and a few other things.
EDIT2 - It loosk like penwan beat me to it.
As an addendum, here's the code in my engine that I use to switch back and forth between windowed mode and fullscreen. If anybody sees anything glaringly wrong, be sure to let me know -- but it works for me. (note: GetRectFromParams is a convenience function I use that uses the AdjustWindowRectEx call to make sure the actual client size is the size expected) -- also the device reset is handled elsewhere when the code receives the message confirming the resize
const DWORD WINDOWED_STYLE = WS_OVERLAPPEDWINDOW | WS_CLIPSIBLINGS | WS_CLIPCHILDREN;const DWORD WINDOWED_EX_STYLE = WS_EX_APPWINDOW;const DWORD FULLSCREEN_STYLE = WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN;const DWORD FULLSCREEN_EX_STYLE = 0;Result Window::ShowFullscreen(bool fullscreen){ ASSERT_WINDOW_HANDLE(); if(fullscreen && !IsFullscreen()) { DisplayMode dm = Display()->CurrentMode(); mStyle = FULLSCREEN_STYLE; mExStyle = FULLSCREEN_EX_STYLE; SetWindowLong(mWnd, GWL_EXSTYLE, mExStyle); SetWindowLong(mWnd, GWL_STYLE, mStyle); SetWindowPos(mWnd, HWND_TOP, 0, 0, dm.width, dm.height, SWP_SHOWWINDOW | SWP_FRAMECHANGED); mFullscreen = true; } else if(!fullscreen && IsFullscreen()) { mStyle = WINDOWED_STYLE; mExStyle = WINDOWED_EX_STYLE; SetWindowLong(mWnd, GWL_EXSTYLE, mExStyle); SetWindowLong(mWnd, GWL_STYLE, mStyle); // Make the window a sane size if necessary RECT rc; DisplayMode dm = Display()->CurrentMode(); if(mPrevXpos < 0 || mPrevYpos < 0 || mPrevWidth > static_cast<s32>(dm.width) || mPrevHeight > static_cast<s32>(dm.height)) { rc.left = 0; rc.right = dm.width >> 1; rc.top = 0; rc.bottom = dm.height >> 1; } else { GetRectFromParams(&rc, mPrevXpos, mPrevYpos, mPrevWidth, mPrevHeight); } mFullscreen = false; SetWindowPos(mWnd, HWND_TOP, rc.left, rc.top, rc.right - rc.left, rc.bottom - rc.top, SWP_SHOWWINDOW | SWP_FRAMECHANGED); InvalidateRect(NULL, NULL, FALSE); } return SUCCESS;}Quote:Original post by ouraqt
Unless your game is really small, the switch between windowed mode to fullscreen mode shouldn't be that big of a hassle. HOWEVER I am aware of the blunders of DirectX! Direct3D expects you to have a WS_POPUP window for fullscreen mode, and a (*usually*) WS_OVERLAPPED (or similar style) window for windowed mode.
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.
Quote:Original post by ouraqtSwitching between window styles is not easy to do in Windows, and it screws a lot of things up. So do we need to create 2 windows for this? I'll leave it up to you to figure out (I'm trying to figure this out myself!). Look at the way DXUT does it.
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.
Quote:In addition to these problems, there's a butload of resource management issues that we need to take care of when eg. the user Alt-Tabs or presses the Windows key. When the device is lost, practically all is lost. All device states and settings need to be reset, many resources need to be reloaded (or OnDeviceLost(..) or whaever).
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.
Quote:Maybe we should all switch to OpenGL.
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.
@OP: I personally like to play all of my games in fullscreen mode because when I'm playing my game I'm not doing anything else. Plus, I don't want to accidentally click outside of the window or accidentally close the game (by clicking the close button in the title bar) if the in-game cursor doesn't line up with Windows cursor. That being said, I can't really say whether or not I would buy a game if it was just windowed. If I want it bad enough I would probably buy it.
There is a certain mmorpg that can be run in windowed mode and in full screen. The full screen mode is nothing more than the window's client area resized to the screen size and positioned so that only the client area is visible. You can have your browser on top the game screen. The only difference is that it mutes the sound when sent to the background. You can switch tasks or access the start menu with normal shorcuts in both modes. This is good, especially that the ingame help system has links to the game's webpages that start your browser.
I agree that it depends a lot on the game; for anything 3D/first-person, I would say probably not. 2D platformers, puzzle games, card games, etc. are acceptable.
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.
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.
Author
Thanks for all the replies!
For clarification, my game is a top-down shooter. Immersive-ness was always meant to be a plus in this game, so I suppose I really should try to use full-screen mode.
Thanks for the source code. Does it use an external library? I ask this because of the functions like InScreen(), which don't seem to exist by default in my IDE.
That seemed like a good idea to me, and I tried it. However, when I did this, the creation of one of my vertex buffers failed (the second one.) This happens in either windowed or full-screen mode. Do you know why this may have happened?
For clarification, my game is a top-down shooter. Immersive-ness was always meant to be a plus in this game, so I suppose I really should try to use full-screen mode.
Thanks for the source code. Does it use an external library? I ask this because of the functions like InScreen(), which don't seem to exist by default in my IDE.
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.
That seemed like a good idea to me, and I tried it. However, when I did this, the creation of one of my vertex buffers failed (the second one.) This happens in either windowed or full-screen mode. Do you know why this may have happened?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
