Direct3D and OpenGL true and false full screen

Direct3D and OpenGL true and false full screen

Full-screen display in Windows programs has different implementation methods, including true full-screen and false full-screen. True full-screen means that the content to be displayed occupies all the resources of the display device, and the program does not load the frame outside the window. The other is the fake full screen. The principle is to adjust the size and position of the content to be displayed so that it fills the entire screen.

There are several game window modes, generally we are directly divided into full-screen games and window games. In fact, there is an intermediate state, which is the fake full screen.

The full-screen mode is what we generally see, such as CS, Duke of Destruction, Delta, etc. After entering the game, the game controls the entire screen (resolution, refresh rate, and color depth are all changed to the game setting mode). The game has exclusive resources. The advantage is that the game will run faster than the window mode. But this method is very inconvenient. I think everyone has had QQ rang when playing CS, so I have to cut out the game to see the chat.

Window mode is the kind of windows that we generally see, such as games like Bubble Shooter. The advantage of this game is that the player can easily switch to other programs while playing, such as chatting QQ, reading novels, etc. This mode is generally suitable for small games that do not occupy high system resources.

Fake full screen mode (pseudo full screen) is actually a window mode, just a full screen window, which gives people the feeling of a full screen game, which makes it easier for players to participate in the game. Of course, the player switching to the QQ interface during this process will not affect the playability of the game. However, its speed is not comparable to that of a full-screen game (resolution, refresh rate, and color are synchronized with the current desktop), and chatting with QQ is not as convenient as windowed. Intermediate products often inherit the advantages of both parties. It also inherited the shortcomings of both parties.

These three methods have their pros and cons. Which one do you prefer when writing programs?

I am not very familiar with OpenGL, but I am eager to know the following questions about OpenGL screens. I hope to get your help, thank you!
Does OpenGL support full-screen "exclusive" mode?
Or does it only support adjusting the window client area to the same size as the screen instead of truly exclusive screen display resources?
Does the double-buffer or multi-buffer mechanism in OpenGL full-screen mode support a true flip mechanism like DirectX full-screen mode?
The above questions are limited to the Windows version of OpenGL.

OpenGL itself does not support the so-called full-screen mode. Relatively speaking, DirectX really supports exclusive display mode and can determine some drawing features that are closely related to it. For example, the Flip mechanism can exchange the address of the hardware display buffer at the graphics card level, which is impossible for OpenGL.
Is my understanding correct?
My purpose is to figure out the difference between OpenGL's ability to utilize hardware (OpenGL supports hardware acceleration) and Direct3D.

For Direct3D, according to your statement, Direct3D is only a 3D API function, it also has no interface and window, but D3D has a function to directly set the full-screen exclusive mode: If the pPresentationParameters->Windowed in the CreateDevice() parameter is FALSE, D3D works in full-screen exclusive mode. In this mode, if pPresentationParameters->SwapEffect is D3DSWAPEFFECT_FLIP, the hardware display buffer address is exchanged during Present().
For OpenGL, it's not exactly as you said, there is such a function found on the Internet: glutFullScreen() can set the full screen mode, but the specific implementation is still through the settings in Windows as you said. Finally, back to my question, whether OpenGL itself supports or not, is it possible to use some non-D3D means (through other third-party libraries, etc.) to make OpenGL work in a true full-screen mode similar to D3D. And what the SwapBuffers() function exchanges is the hardware display buffer address?
Based on my preliminary research results, for operations such as swapbuffer, OpenGL-based programs, even in full-screen mode, there is no case of "switching addresses through registers", all are copy methods, such as CS Kind of game. Most of the games based on D3D full-screen mode are really "switching addresses through registers". I once tried to display windows normally in D3D full-screen mode, but the result failed and the windows flickered. It is "switch address through register".
This led to my question about whether OpenGL's "full screen mode" can "switch addresses through registers", because if OpenGL-based programs do not have this capability, I can ensure that the window is displayed normally without worrying about the window flickering, and then I will concentrate on finding ways to solve the problem of how to not flicker in D3D.

After discussing for a long time, I still didn't get an exact answer.
Let me describe the problem in a targeted manner: Under what circumstances does OpenGL's swampbuffer "switch addresses through registers"? How can this be proved?
This post is not to discuss the advantages of OGL and D3D, just hope to confirm my research conclusions. And this research conclusion is very important to my work.

My research conclusions are:
1) In window mode:
a. OpenGL's SwapBuffers() function exchanges the address of the internal buffer, and the front buffer is copied to the screen.
b. Direct3D's Present() function is also the address of the exchanged internal buffer, and the front buffer is also copied to the screen.
Conclusion: In window mode, because it needs to coexist with other applications, neither the underlying implementation of OpenGL nor D3D allows the hardware display cache address.
2) In full-screen mode:
a. OpenGL's SwapBuffers() function exchanges the address of the internal buffer, and the front buffer is still copied to the screen. The working mode is the same as the window mode, which can be understood as fake full screen, or OpenGL itself has no concept of true full screen.
b. Direct3D's Present() function may have two behaviors at this time: one is still to exchange the address of the internal buffer, and the front buffer is still copied to the screen; the other is to directly notify the hardware to exchange the address of the display buffer.
Conclusion: For a 3D engine, it shouldn’t involve issues such as window mode or full screen mode. OpenGL may think this way, so for OpenGL, there is no difference between window and full screen; but Microsoft is different. Since the birth of DirectX, there has been a certain difference between window mode and full-screen mode. DirectX has always supported a mechanism called Flip, which provides page flipping capabilities in full-screen exclusive mode (of course, you can also do without page flipping) Turning over will cause the physical address of the video memory mapped to the content currently displayed on the entire screen to change. For the current hardware performance, it is true that flipping does not have much speed advantage. Copy is fast enough, but page flipping is still supported by DirectX.
Finally, quote a paragraph from MSDN in response to madamanahong:
This is a short paragraph of text in the D3DPRESENT_PARAMETERS parameter description:
SwapEffect - Member of the D3DSWAPEFFECT enumerated type. The run time will guarantee the implied semantics concerning buffer swap behavior. So if Windowed is TRUE and SwapEffect is set to D3DSWAPEFFECT_FLIP, then the run time will create one extra back buffer, and copy whichever becomes the front buffer at presentation time.
idea is that if Windowed is TRUE (that is, in window mode) and SwapEffect is specified as D3DSWAPEFFECT_FLIP, then an additional backup buffer will be automatically created at runtime (at this time there will be at least 2 backup buffers) ), every time it is Present, the content that will become the front buffer is copied to the back buffer, and then the pointer is exchanged with the next back buffer to complete the false page flip.
The implication is that if Windowed is FALSE (that is, in full-screen mode) and SwapEffect is specified as D3DSWAPEFFECT_FLIP, no additional backup buffer will be created, and each time it will be a real page flip.
Anyone who has written Chinese online games based on DirectDraw or Direct3D may have encountered such problems:
If you want to use the various input methods of the system normally in the game, you cannot use the Flip() function to exchange the foreground and the backup buffer in a 2D full-screen game, but you can only use the Blt() function to copy them; in 3D The D3DSWAPEFFECT_FLIP page flip flag cannot be specified in a full-screen game, but only the D3DSWAPEFFECT_COPY flag can be specified. Otherwise, the window of the input method will continue to flicker, because the window of the input method cannot be adapted and flipped, it can only be drawn on one of the pages.
For OpenGL, these settings seem to be missing, but fortunately, it does not page flip, so the window does not flicker. What I am worried about is, will OpenGL start to flip the page and the window will flicker?
"Fulll-screen" isn't a mode, and there isn't an API to enter it -- full screen is just a consequence of other normal actions. What applications normally do is to create a WS_POPUP and WS_EX_TOPMOST window whose dimensions are GetSystemMetrics(SM_CXSCREEN), ...CYSCREEN. This obscures the rest of the screen and so looks full.
If an app has changed resolution first, using ChangeDisplaySettings(CDS_FULLSCREEN), then I don't know what GetSystemMetrics(...) returns. Note that, despite the name of this API call, I think it'd be wrong to call it a "mode". The function still allows other windows to be shown on the desktop normally, albeit at a different resolution. ChangeDisplaySettings is often used in OpenGL games.
Still, if you tried to grab exclusive mode for yourself and were denied, that'd be a good sign that someone else had it.
see also
Adding a Full Screen Feature to an MFC Application

Full screen is the problem windows system, there is no real difference between full screen and non-full screen of
the working principle of the display card, the content on a screen occupied memory space is only a part of the graphics card
specifically what part, by The
so-called swapbuffer controlled by the hardware register only switches the address through the register. The
graphics card itself interprets how the content below the address is displayed according to the address, status, and port information on the register.
It is precisely because of this, this The operation speed is very fast. You can process the content of the background buffer while the display card displays the original content, and then swap them after the completion of the
graphics card. The working principle of the graphics card itself, regardless of whether it is full screen or full screen, is always full screen in its eyes. It is
divided into text mode or graphics mode; whether to use video memory or memory or agp memory
dx. In the early days, flips in windows mode were not supported, and only flips in full-screen exclusive mode were
supported. The reason for not supporting flips in windows was very Simple, because everyone shares this desktop, you can’t simply replace
swapeffect. It’s a concept after dx9. The flip allowed under windows is also a special implementation.
As mentioned earlier, flip actually occurs in the backbuffer and an intermediate internal buffer, and then From the internal buffercopy in the middle to the desktop area, this copy is also a copy of the internal data of the graphics card, and the speed is also very fast.
From the principle of pc display card work, there is no problem with opengl supporting this level, but opengl is a cross-platform system; Directx must rely on the windows platform. Under a single platform, Microsoft can control all
the graphics card memory display address flip attributes can be supported on other computer systems and operating systems, it is questionable;
If OpenGL does not provide such a function, I personally think that it is also the reason
for the cross-platform and cross-system compatibility. As for whether OpenGL will suddenly change its strategy, this is not worth worrying about!

Reference :