I'm trying to learn Direct3D 12 to do some simple 3D graphics for fun.
I've heard that pure fullscreen is the way to go for maximum fps, but now that I'm testing it, fullscreen seems way, way worse than windowed mode.
For example, a static color on a WS_BORDER window (with fullscreen size), and Windowed set to TRUE in the DXGI_SWAP_CHAIN_FULLSCREEN_DESC, can be rendered (with triple-buffering) at about 5000 fps on my computer.
On the other hand, a static color on a WS_POPUP window, Windowed set to FALSE in the DXGI_SWAP_CHAIN_FULLSCREEN_DESC and also IDXGISwapChain3::SetFullscreenState(TRUE, nullptr) called, only renders (with triple-buffering) at about 3000 fps.
Should this be the case or am I missing something?
The story of "fullscreen" for Direct3D is a complex one, and from the other comments/answers in this thread continues be a confused one.
For DirectX 12 on Windows 10, there is no FullScreen Exclusive mode (FSE). When you use SetFullscreenState with either of the modern DXGI_SWAP_EFFECT_FLIP_DISCARD or DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL effect modes then use are really using emulated Fullscreen Exclusive mode (eFSE). DirectX 12 does not support using the the older 'blt-style' effects DXGI_SWAP_EFFECT_DISCARD or DXGI_SWAP_EFFECT_SEQUENTIAL.
If you run with a borderless window that is maximized to cover the entire screen in "windowed mode", it's the same performance as using "eFSE".
There are some 3rd party video card vendor APIs and scenarios that require you use "fullcreen mode" rather than "windowed mode", so in those cases there's a difference.
The other issue is if you are trying to change the display mode vs. using the native resolution. The performance impacts here are the "pixel-fill' rate for the render target size. There are techniques for scaling performance by rendering to an 'offscreen' render target size and then scaling that up to the native resolution of a backbuffer vs. changing the display mode to try to reduce the size of the backbuffer.
See The Care and Feeding of Modern Swap Chains and Demystifying Fullscreen Optimizations.
Related
In my SDL2 program, I would like to enter fullscreen, but I'm on a desktop with multiple displays and I would like to enter fullscreen on any specific display.
I know this can be done with SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP).
However, I want to use SDL_WINDOW_FULLSCREEN (without _DESKTOP), instead. The reason is that it has less latency. But when I do that, it will enter fullscreen on display 0 exclusively, even if the window was on another display when I called the function.
Can I use SDL_WINDOW_FULLSCREEN on other displays, or is it strictly limited to display 0? I am doubtful because SDL_SetWindowFullscreen does not take an argument specifying which display to pick. Is that maybe why the other fullscreen mode is called _DESKTOP? Thanks.
Here's a little more context, if you like.
I am using Windows 10, though I don't think that matters much.
I am using SDL 2.26.2, but I've used the same code with an older
dll (2.0.16) and had the same issue.
Why FULLSCREEN_DESKTOP is slower, and I would rather use FULLSCREEN
FULLSCREEN_DESKTOP is a kind of "fake" fullscreen which is really just a resized window positioned perfectly, so it takes up the whole screen, whereas "real" fullscreen actually changes the video mode of the display. It says so in the docs for SDL_SetWindowFullscreen.
SDL_WINDOW_FULLSCREEN, for "real" fullscreen with a
videomode change;
SDL_WINDOW_FULLSCREEN_DESKTOP for "fake" fullscreen
that takes the size of the desktop;
As such, I've noticed that both windowed and fake fullscreen (which we know now are essentially the same thing) have a little more latency than real fullscreen. I made a little sprite that follows my cursor, and it lags behind noticeably more in fake fullscreen than it does in real fullscreen. Presumably because fake fullscreen still renders the desktop behind it and real fullscreen does not.
I'm programming a game with cocos2d-x for Windows, Linux and MacOS (for the moment I develop and test on Windows 10). I already have a system to change settings (either fullscreen or windowed with different resolutions but always a ratio of 16:9).
I've implemented a prototype of my levels system, with only a few sprites and the ability to move horizontally. In windowed mode everything is ok, but in fullscreen mode at native resolution I experience some tearing, though the resolution is set to 60 fps, on a 60 Hz screen (and the fps counter actually displays 60).
When investigating this issue, I've read on the thread OpenGL tearing with fullscreen native resolution that this may be due to bypassing the DWM compositor in fullscreen native resolution, which is otherwise doing some kind of vsync.
I would like to force vsync but I've not found any function neither in class cocos2d::Director nor cocos2d::GLView to do this, and with cocos2d-x I can't do this on a low-level (never using OpenGL directly).
Any idea of how to remove tearing / force vsync?
I am trying to draw on top of another process while it is in immersive full-screen mode.
I know this is possible using GDI and I have 2 questions:
Is it possible using a top-level transparent window ? (on top of the immersive process)
Is there a higher level API witch I can use instead of GDI?
Thank you :)
In Windows, you have two possibilities for creating a fullscreen window:
A full-screen application with exclusive drawing rights to the display.
A borderless window that extends to the full desktop resolution.
The first option allows you to change display properties like resolution, bit depth and refresh rate, while the second option is bound to use the same options here as a normal (windowed) desktop application.
Overlaying a fullscreen window with a top-level window is only possible if the fullscreen application is implemented with option 2. In that case however, any code that is able to create a transparent top-level window will do (be it pure WinAPI/GDI, or something more sophisticated, like Qt).
With option 1, as the description suggests, the fullscreen application has exclusive drawing rights to the display. Attempting to bring another window in front of it will either minimize the fullscreen application or force it into windowed mode.
There are some hacks how you can still get an overlay in this case, but they are rather invasive. For example, with a fullscreen application based on D3D, you can hook into D3D's Present routine and have D3D draw your overlay before displaying the back buffer. The important point here is that the code for drawing the overlay is executed from within the process of the fullscreen application, as that is the only process that is allowed draw to the screen at that point.
Note that some applications (in particular video games protected by anti-cheat software) do not like it very much if you inject code into the process this way.
Note that the Win API also provides an interface for so called hardware overlays, which allow drawing on top of exclusive fullscreen applications. Unfortunately, this mechanism is not widely supported on consumer hardware and might not work depending on which graphics card you are trying to run it on.
I am using C++ with Allegro 4.2 to build a windows game.
I want stretchable graphics in windowed mode.
I'm am one who likes giving users of my programs lots of options; I always hate when I'm playing a game in windowed mode and I'm either not allowed to stretch the window or the content inside the window doesn't stretch with it (this sucks a lot for 640x480 size games played on high resolution screens that don't even allow for fullscreen; requiring a magnify tool to play it properly). I'm wondering if there is some way in Allegro or perhaps if there is another programming library that allows the graphics to stretch with the shape of the window itself. I already know how to have my Allegro applications switch to fullscreen mode; I'm trying to improve the windowed mode.
A big reason for this is because my artstyle is low-resolution art (I call it "Bitmap Brothers" style); it's very good for games since it's organized and easy to edit. I don't want to have to go higher than 640x480 to increase the size because it's far to high for low-resolution art, but my window remains too small during windowed mode.
I noticed that Allegro 5.0.8 has this line of code:
al_set_new_display_flags(ALLEGRO_WINDOWED | ALLEGRO_RESIZABLE);
At the end it says "ALLEGRO_RESIZABLE", could that be the feature I'm looking for? If so, just how much does Allegro change from 4.2 to 5+?
Allegro 4 doesn't support user-resizable windows.
Allegro 5 does (as you've noted), but it is completely rewritten and is not backward compatible at all. Still, I would highly recommend that you switch to it as development on Allegro 4 is all but dead.
I'm porting a small graphics engine from DirectX 9 to OpenGL. The engine uses SDL (now ported to 2.0) to manage input and window creation.
I want to know how to correctly handle window events for both OpenGL and DirectX. I'm interested in these for Desktop platforms (linux, OSX and windows)
Window resolution change
Full screen to windowed / windowed to fullscreen handling
Alt+tab handling -
I've tried to search through the net but information is quite not focused in one place. I imagine many others faced the same problem before.
Are there any resources to read guidelines on that kind of handling for my engine?
Is it possible to handle resolution change without losing transfered resources to the renderer system in both OpenGL and DirectX?
Window resolution change
OpenGL itself requires no special treatment for this. Unfortunately SDL goes through a full window reinitialization, including the OpenGL context on a window size change, which means, that all OpenGL state objects (that is, textures, vertex buffers, shaders and so on) are lost.
This is however a limitation of SDL.
Personally I thus prefer GLFW for creating a OpenGL window and context. You can still use SDL for other things though (like audio, networking, image loading and such).
Full screen to windowed / windowed to fullscreen handling
The is effectively a window size change as well. See above.
Alt+tab handling -
OpenGL requires no special effort for this. Just minimize the window when Alt+Tab-ing out and stop the game loop. When the window gets restored just continue the game loop.