• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
riuthamus

Resolution ( full screen vs windowed )

13 posts in this topic

So, we have been programming the ability to setup different resolutions and such. Our issue now is with the UI and screenlocking. When the game is first started we open it up in a 1280x720 ( windowed ) client. You can change this via the in game options menu but when you change it to fullscreen the UI does some silly things.

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.
2) We have tried changing the type to stretch, to centered, to whatever and it seems to give the same effect
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?

Any and all suggestions are welcome. If you need a picture to better explain this let me know and I will provide that as well. If you need some backstory on how we are doing the system let me know that as well. Thanks in advance.
0

Share this post


Link to post
Share on other sites
Are you using any particular engine? sounds like only the visuals are being affected by the resize, you need to either update the UI hit areas or scale the mouse position to a standard resolution before checking collisions.

There are different ways a UI can adapt to stretching and they are all useful in their own cases, such as:
Remain unchanged, no scale or position alteration.
Maintain position relative to an anchor, a screen corner, center or side.
Fully scale with screen.
Probably others I'm not thinking of.
1

Share this post


Link to post
Share on other sites
The problem seems to be that directx is completely ignoring the resize and just staying with the original resolution. According to my monitor, its running in 1280x720 when in fullscreen, despite having been set to 1920x1080. This is the code that I'm using:

[code]
public static void ApplySettings()
{
swapChain.SetFullscreenState(Settings.WindowMode == GameSettings.WindowModeSetting.Fullscreen, null);

if(Settings.WindowMode != GameSettings.WindowModeSetting.Fullscreen)
Form.ClientSize = new Size(Settings.DisplayMode.Width, Settings.DisplayMode.Height);

Resize(Settings.DisplayMode.Width, Settings.DisplayMode.Height);
}

private static void Resize(int width, int height)
{
BackBuffer.Dispose();
LinearBackBuffer.Dispose();

swapChain.ResizeBuffers(0, width, height, Format.Unknown, SwapChainFlags.AllowModeSwitch);
Viewport = new Viewport(0, 0, width, height);
Console.WriteLine("Viewport size: {0}x{1}", Viewport.Width, Viewport.Height);

using(var resource = Resource.FromSwapChain<Texture2D>(swapChain, 0))
{
BackBuffer = new RenderTargetView(device, resource);

LinearBackBuffer = new RenderTargetView(device, resource, new RenderTargetViewDescription
{
Dimension = RenderTargetViewDimension.Texture2D,
Format = Format.R8G8B8A8_UNorm
});
}

if(OnResize != null)
OnResize();
}
[/code]
0

Share this post


Link to post
Share on other sites
I hope you're not using an absolute scale for your mouse coordinates. That would make me a sad panda :( Arbitrary scale from 0-1(float) is practically mandatory.
On the resize issue particularly, you may be attempting to switch to a mode your monitor does not support. Before hard coding values for it to switch to make sure to get the list of available resolutions (and keep in mind just because it supports a resolution does not mean it supports your format/refresh rate). Also, add error checkers around all of this code.
As another aside, do NOT name your member variables as the same spelling (and capitalization) of your class names... Viewport, for example, is never explicitly used in your above code (except to print the size) and if this had been a clip instead of a full function I wouldn't have been able to tell if it was a local or member variable. :( And oh god no.. OnResize/OnResize()... that's just.. painful.
1

Share this post


Link to post
Share on other sites
We're not using absolute scale, but we decided not to use floats/percents since it makes a bit of a pain when designing the UI. The UI actually uses 1280x720 as its baseline. It scales itself according to the actual resolution.

As for the resolution being set, its not hard coded, I enumerated the list provided by Output.GetDisplayModeList. And its not like I'm requesting any weird setting. 1920x1080@60Hz is certainly supported by my monitor. And I should certainly hope the R8G8B8A8_UNorm_SRGB format is supported.

For error checking, I don't see where I can add any, this is C#/SharpDX. Unlike C++, ResizeBuffers has no return value. I imagine if it fails, it would inform me via an exception, which it hasn't.

The variable naming... well that's pretty much C# standard convention. I hate the _ or m prefixes, it just makes things harder to read. Visual Studio shows plain as day whats a variable and whats a type. Though I suppose I do have the convention on the event handler backwards
0

Share this post


Link to post
Share on other sites
The code you see is all that's being run for resizing. The only window I have that I can resize is the RenderForm, which, as suggested, I tried resizing to no effect. Wouldn't removing the border only be for borderless fullscreen mode?
0

Share this post


Link to post
Share on other sites
[quote]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.[/quote]

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 ..

[code]Device11.ImmediateContext.Rasterizer.SetViewports(viewport);[/code]

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.

[quote]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?[/quote]

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.

[quote name='Mike.Popoloski' timestamp='1351819719' post='4996392']
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.
[/quote]

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
[code]swapChain.ResizeTargets()[/code]
Which will also resize your window, and fire a Resize event, so that your backbuffers can adjust. Edited by Gavin Williams
2

Share this post


Link to post
Share on other sites
Even though not direcly an answer to your question maybe a tip:

Don't expect the user to know:
- that it's possible to switch to fullscreen
- that he can change the resolution of your application or know what changing the resolution will do
- what resolution is optimal for his/her computer

You won't belive how often I'm at some computer where the resolution is not selected correctly. Most of the time users don't use the native resolution of their display. Most of the time they don't even know what the native resolution is or how to change the desktop resolution. Sometimes someone else did set up their computer and choose thecorrect resolution, but how would they know what to select in your game?

If you're targeting causual users, just start your application in fullscreen mode with the current desktop resolution. This will work fine most of the time.
Of course it's allways good to provide a resolution as well as a windowed/fullscreen option.

Best luck with your project.
2

Share this post


Link to post
Share on other sites
[quote name='Gavin Williams' timestamp='1351869438' post='4996558']
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.
[/quote]

Well, I'm not sure if you were saying to do this or not, but I tried calling ResizeTarget and letting that in turn call my Resize method. So both ResizeTarget and ResizeBuffers end up being called. My monitor is now properly reporting 1920x1080 as the resolution and the mouse positioning is working correctly. No where have I seen any examples or documentation that stated BOTH of these needed to be called.

This is what worked for me in the end:

[code]
public static void ApplySettings()
{
swapChain.SetFullscreenState(Settings.WindowMode == GameSettings.WindowModeSetting.Fullscreen, null);

if(Settings.WindowMode != GameSettings.WindowModeSetting.Fullscreen)
{
Form.ClientSize = new Size(Settings.DisplayMode.Width, Settings.DisplayMode.Height);
Resize(Settings.DisplayMode.Width, Settings.DisplayMode.Height);
}
else
{
var mode = Settings.DisplayMode;
swapChain.ResizeTarget(ref mode);
}
}

private static void Resize(int width, int height)
{
BackBuffer.Dispose();
LinearBackBuffer.Dispose();

swapChain.ResizeBuffers(0, width, height, Format.Unknown, SwapChainFlags.AllowModeSwitch);
Viewport = new Viewport(0, 0, width, height);
Console.WriteLine("Viewport size: {0}x{1}", Viewport.Width, Viewport.Height);

using(var resource = Resource.FromSwapChain<Texture2D>(swapChain, 0))
{
BackBuffer = new RenderTargetView(device, resource);

LinearBackBuffer = new RenderTargetView(device, resource, new RenderTargetViewDescription
{
Dimension = RenderTargetViewDimension.Texture2D,
Format = Format.R8G8B8A8_UNorm
});
}

if(OnResize != null)
OnResize();
}
[/code] Edited by Telanor
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0