[feature request] Option to Windowed fullscreen/Borderless

[LuismaSP89]

There are some problems in windows 10 HDR mode when Gliden64 is on use. All the games (Using project64 + Gliden64) looks with washed colors when fullscreen mode is used. If I switch back to windowed mode, all colors looks as they should.

Looked on a lot of forums, and seems this is happening to a lot of users, not only for project64 or Gliden64, but indeed can be solved by having the option to enable a windowed fullscreen/borderless instead of exclusive fullscreen, because windows 10 takes this as HDR content even if Gliden64 + Project64 are only SDR capable.

Also (I don't know if this can be related, the mouse is stuck when entering in fullscreen mode, and cannot be moved or hide)

Using other plugins such as Jabo doesn't have this problems (Mouse stuck problem & HDR problem)

Attached you'll find 2 image (You can see the color difference between windowed & Fullscreen) sorry for the quality.

[LuismaSP89]

Note: I found that other emulators like snes9x (x64 version) bypassed this problem with HDR in the latest windows versions by using a emulated fullscreen without borders. And works like a charm.

[gonetz]

Any links to articles or example of how it can be done would be nice.

[LuismaSP89]

I'll check if I can found the PR that added it to the snes9x. In any case, this "emulated fullscreen" feature is the same as most PC games had, "windowed fullscreen" or "windowed borderless" instead of fullscreen.

[LuismaSP89]

I saw a lot of programs that allow this, maybe can take the code of a free one?

Anyway, there's a lot of info about this:

https://www.pcgamingwiki.com/wiki/Glossary:Borderless_fullscreen_windowed

https://www.makeuseof.com/tag/windowed-fullscreen-borderless-modes/

https://westechsolutions.net/sites/WindowedBorderlessGaming/

[Jj0YzL5nvJ]

https://github.com/project64/project64/issues/2068#issuecomment-873341593 https://github.com/mpv-player/mpv/pull/5520#issuecomment-368331966

[gonetz]

I mean "example of how it can be done", that is some OpenGL scenario, to not invent a wheel.

[Jj0YzL5nvJ]

mpv can do borderless with any API, not only OpenGL.

[LuismaSP89]

@Jj0YzL5nvJ Yes, I posted also other apps to allow borderless in any app on windows, there are a lot, but the idea is to integrate borderless in the plugin without needed to install 3rd party apps.

@gonetz Info related with borderless in Opengl can be found here, hope this helps:

https://community.khronos.org/t/windowed-fullscreen-mode/21571/9

https://stackoverflow.com/questions/22259067/opengl-non-exclusive-fullscreen-mode-a-k-a-fullscreen-borderless-window

Also it can be done by using: PFD_SUPPORT_COMPOSITION in the PIXELFORMATDESCRIPTOR of ChoosePixelFormat/SetPixelFormat

https://www.opengl.org/pipeline/article/vol003_7/

[Jj0YzL5nvJ]

The one that has to implement the option is the client (Project64, 1964, Mupen64Plus, m64p, etc), not the plugin.

[LuismaSP89]

The thing is that this HDR problem is only happening with Gliden64, other plugins such as jabo don't look with washed colors when HDR + fullscreen is enabled. So maybe the plugin itself can solve something here. Also in the info I posted, there is information on how this technique works on opengl, then the graphics backend has something to do with it.

Of course this is not urgent and there is other issues to solve before. But in case this can be solved quickly by creating/copy a few lines of code, since there is a lot of info about windowed fullscreen in opengl, I think a lot of people will appreciate it.

[Jj0YzL5nvJ]

The issues of HDR with OpenGL in NVIDIA hardware are "driver product limitations". ANGLE can effectively skip such "limitation".

[LuismaSP89]

@Jj0YzL5nvJ I don't get your point. I mean, what's the problem for allowing the plugin can have windowed borderless option and solve the issue by doing this little trick such as other emulators do? Opengl can support HDR mode with this workaround in gliden64.

Other emulators such as rpcs3 and dolphin have an opengl backend and the HDR works fine. In case of snes9x it doesn't. They implemented this option and luckily this solves the issue.

Like I said of course there are other important things to do before. But if with a little research and a few lines of code a option like this can be implemented, I don't see the reason to discuss about it. Indeed if the dev see that he is going to spend a lot of time to implement this, he can decide if yes or not.

[gonetz]

The one that has to implement the option is the client (Project64, 1964, Mupen64Plus, m64p, etc), not the plugin.

It is true for Mupen64Plus. Project64 and 1964 do not deal with drawing context, it is plugin's duty.

[gonetz]

@gonetz Info related with borderless in Opengl can be found here, hope this helps:

Thanks! These topics have some useful info, but not the whole working scenario. I'll try to play with pixel flags, but it would be better to find some already working piece of code.

[LuismaSP89]

@gonetz Sorry, I don't know much of programming, so I don't know what to look for. I'll try to do a deeper search, in that links there are code to do this in opengl, I thought that will be enough.

[LuismaSP89]

Maybe here?

https://ecode.dev/transparent-framebuffer-borderless-window-using-glfw/amp/

https://github.com/ands/borderless-window-opengl/blob/master/borderless-window-rendering.cpp

[gonetz]

Maybe here?

https://ecode.dev/transparent-framebuffer-borderless-window-using-glfw/amp/

https://github.com/ands/borderless-window-opengl/blob/master/borderless-window-rendering.cpp

These example use some high-level OpenGL libraries. All work is made under the hood. We use OpenGL directly. However, both GLFW and ImGui are opensource libraries, so I should be able to extract the necessary code from them. Thanks!

[gonetz]

I tried to implement that feature but failed. May be someone else can take this task.

[Jj0YzL5nvJ]

If the plugin can't create a "480p" borderless window, how is it supposed to do the rest?

[LuismaSP89]

It's a shame, because the bug with HDR still persists even with a different OS "from W10 to W11" the colors are totally washed in fullscreen but looks fine on window mode. I don't know how the other emulators or games do to this feature of borderless fullscreen, it's a hack or something?

[LuismaSP89]

I'll try with this:https://www.pcgamingwiki.com/wiki/Glossary:Borderless_fullscreen_windowed

Let's hope it can help with the issue.

[Jj0YzL5nvJ]

I don't know how the other emulators or games do to this feature of borderless fullscreen, it's a hack or something?

It's literally a f***ing window without any properties (minimize, maximize, resize, border, move, close) that takes up the entire screen with the attribute always on top. In the old days IDEs like Delphi used it as a template and it was the programmer who enabled those properties. Modern IDEs do exactly the opposite. The one that has to program this function is the frontend. The window has its own graphics acceleration and "simulates a monitor" (video output signal) on top of it.

[LuismaSP89]

I don't know how the other emulators or games do to this feature of borderless fullscreen, it's a hack or something?

It's literally a f***ing window without any properties (minimize, maximize, resize, border, move, close) that takes up the entire screen with the attribute always on top. In the old days IDEs like Delphi used it as a template and it was the programmer who enabled those properties. Modern IDEs do exactly the opposite. The one that has to program this function is the frontend. The window has its own graphics acceleration and "simulates a monitor" (video output signal) on top of it.

For me it's also just a window, and seems an easy task to do, since most emulators have this function. But since I'm not a programmer, it's only my point of view, it can be a nightmare to implement even if it looks easy from the outside.

Anyway, like Gonetz said (And some people in the project64 forums) this must be implemented by the plugin, not the project64.

[Jj0YzL5nvJ]

For me it's also just a window, and seems an easy task to do, since most emulators have this function. But since I'm not a programmer, it's only my point of view, it can be a nightmare to implement even if it looks easy from the outside.

It's as difficult as implementing a context to play a video file at any arbitrary resolution, at any arbitrary aspect ratio in real time.

https://i.imgur.com/NLYIkQ6.mp4

Anyway, like Gonetz said (And some people in the project64 forums) this must be implemented by the plugin, not the project64.

That just proves that none of them have the faintest idea how THE FAKE FULLSCREEN (AKA fullscreen) works in video players.

[oddMLan]

@LuismaSP89 @Jj0YzL5nvJ try this dll with Project64 GLideN64_borderless_wtl.zip I don't have an HDR monitor to test so can you try it for me?

Explanation: Nothing fancy, I just commented out the winapi call ChangeDisplaySettings in windows_DiplayWindow.cpp. I believe it has that intended borderless window effect. For instance, this is what happens when I set a Full screen res of 800x600. When you set your resolution to match your current resolution it actually takes up the whole screen.

[LuismaSP89]

For me it's also just a window, and seems an easy task to do, since most emulators have this function. But since I'm not a programmer, it's only my point of view, it can be a nightmare to implement even if it looks easy from the outside.

It's as difficult as playing a video file in any arbitrary resolution and any aspect ratio in real time.

Anyway, like Gonetz said (And some people in the project64 forums) this must be implemented by the plugin, not the project64.

That just proves that none of them have the faintest idea how THE FAKE FULLSCREEN (AKA fullscreen) works in video players.

Yes, ok, ok, we know you're a god. But if is that easy, then perhaps your highness can implement the code for the Gliden64 instead of wasting time here.

[LuismaSP89]

@LuismaSP89 @Jj0YzL5nvJ try this dll with Project64 GLideN64_borderless_wtl.zip I don't have an HDR monitor to test so can you try it for me?

Explanation: Nothing fancy, I just commented out the winapi call ChangeDisplaySettings in windows_DiplayWindow.cpp. I believe it has that intended borderless window effect. For instance, this is what happens when I set a Full screen res of 800x600. When you set your resolution to match your current resolution it actually takes up the whole screen.

I'll try that and let you know. Thanks a lot 👍

[Jj0YzL5nvJ]

Yes, ok, ok, we know you're a god. But if is that easy, then perhaps your highness can implement the code for the Gliden64 instead of wasting time here.

I'm not God, I'm not dead... yet. This highness uses his spare time as he pleases and only knows how to program in dead languages, thanks for your concern. /s

[LuismaSP89]

Yes, ok, ok, we know you're a god. But if is that easy, then perhaps your highness can implement the code for the Gliden64 instead of wasting time here.

I'm not God, I'm not dead... yet. This highness uses his spare time as he pleases and only knows how to program in dead languages, thanks for your concern. /s

In that case, if you're not going to help with the development of this feature and you are only here to say that everybody knows nothing about programming this feature, (even the devs) I don't see the point of what are you doing here.

[Jj0YzL5nvJ]

Now I understand your hostility, I never tried to convey that, I just paid very little attention to my translation from Spanish to English. I already corrected my bad translation, never trust 100% in Google Translate =P

Even so, I support my second sentence. Knowing how to code has absolutely nothing to do with understanding an API and all its behaviours.

[LuismaSP89]

It's a shame we cannot speak in spanish, because this kind of forums are in english, I'm for spain.

I didn't pretended to be hostile, but understand that even if we think this is an easy task to do, we don't know how to do it, and we cannot judge a dev if he cannot implement this feature.

[LuismaSP89]

@LuismaSP89 @Jj0YzL5nvJ try this dll with Project64 GLideN64_borderless_wtl.zip I don't have an HDR monitor to test so can you try it for me?

Explanation: Nothing fancy, I just commented out the winapi call ChangeDisplaySettings in windows_DiplayWindow.cpp. I believe it has that intended borderless window effect. For instance, this is what happens when I set a Full screen res of 800x600. When you set your resolution to match your current resolution it actually takes up the whole screen.

This is awesome, this solved the issue! Is there any way to implement this into the plugin's code and enable a checkbox with this borderless option? It would be awesome.

[Jj0YzL5nvJ]

It's a shame we cannot speak in spanish, because this kind of forums are in english, I'm for spain.

Podemos hablar, pero no aportaríamos nada con ello, yo soy de México, de la parte norte del país. NADA que ver con los chilangos ¬¬

I've tested it @oddMLan, it works fine as "Non-exclusive Fullscreen Mode" if used at full resolution... but not good at "production level". But it is good enough for most user cases.

A real implementation would have the ability to re-render the image generated by the plugin at a higher resolution for a more retro feel (480p to 4K). Or 8K to 1080p for benchmarking, etc.

See #2410 for more examples.

[oddMLan]

Ya cásense hombre 😄

A real implementation would have the ability to re-render the image generated by the plugin at a higher resolution for a more retro feel (480p to 4K). Or 8K to 1080p for benchmarking, etc.

Isn't that already possible by using "Native resolution factor"? set that to 1x and set the fullscreen res to match your current resolution, then it should render at 240p. Use 2x if you want 480p. EDIT: If you meant rendering at 4K internally and then downscaling to native resolution... then streching THAT to take up the whole screen, then it would require a bit more work. But at least we know HDR works when skipping ChangeDisplaySettings

[LuismaSP89]

Yes, maybe it can be improved, but at least, it solves the HDR issue for everybody with an HDR screen, wich is becoming more frequently since all new monitors/TV's have HDR. And if the issue can be solved by only changing one line, maybe @gonetz agree with the "fix"

[Jj0YzL5nvJ]

Personally, I would prefer a borderless window mode that can be manipulated like the example with mpv. With such support, multi-monitor setups will be easier for the user to arrange and more convenient for streams.

[gonetz]

Yes, maybe it can be improved, but at least, it solves the HDR issue for everybody with an HDR screen, wich is becoming more frequently since all new monitors/TV's have HDR.

My monitor has HDR support, but I turned it off. I use it only for games with HDR support.

And if the issue can be solved by only changing one line, maybe @gonetz agree with the "fix"

I don't mind, but I suppose it should be optional, which means new option to support in GUI and CLI. Could anybody make a PR with that?

[LuismaSP89]

Yes, maybe it can be improved, but at least, it solves the HDR issue for everybody with an HDR screen, wich is becoming more frequently since all new monitors/TV's have HDR.

My monitor has HDR support, but I turned it off. I use it only for games with HDR support.

And if the issue can be solved by only changing one line, maybe @gonetz agree with the "fix"

I don't mind, but I suppose it should be optional, which means new option to support in GUI and CLI. Could anybody make a PR with that?

I think nobody here "except you" has programming skills to do the PR 😅. Who is the person who usually do the PR's related with the QT5 GUI? Maybe we can ask him.

[LuismaSP89]

Another think we can just do, is to add the feature "disabled by default" and the the ability to change it using the config file. At least until someone adds the feature to the GUI. This is the way others emulators do this, for example RPCS3, some things can be changed using the .ini file only "mostly experimental things" and after some time the main UI dev "megamouse is his name" adds it to the UI for everybody's use.

[LuismaSP89]

Sorry to bother you @gonetz but since nobody is adding this option to the GUI, is there any posibility to implement this by changing a option in the gliden64 config file? at least to solve this problem until someone do a PR for adding this feature to the GUI.

Thank you so much,

[gonetz]

Beta implementation: Support Borderless windowed mode. #2686

Zilmar-spec only. Please test.

[oddMLan]

Hey @gonetz! Nice to see you again.

On my 16:10 monitor (1440 x 900) the image is cropped with the Borderless Fullscreen option.

Exclusive fullscreen = Current screen resolution, it works correctly here.

EDIT: You're obtaining the maximum width and height supported by the display, not the current resolution. I set my screen resolution to 1280 x 1024, and borderless used 1440 x 1024 again.

[LuismaSP89]

Excuse my ignorance, but how I can download this build in order to test? I don't know how to build from github, is there any way to download from the github jobs/PR or something?

[oddMLan]

Excuse my ignorance, but how I can download this build in order to test? I don't know how to build from github, is there any way to download from the github jobs/PR or something?

[LuismaSP89]

Excuse my ignorance, but how I can download this build in order to test? I don't know how to build from github, is there any way to download from the github jobs/PR or something?

Nice, thanks a lot!

[LuismaSP89]

Hey @gonetz! Nice to see you again.

On my 16:10 monitor (1440 x 900) the image is cropped with the Borderless Fullscreen option.

Exclusive fullscreen = Current screen resolution, it works correctly here.

EDIT: You're obtaining the maximum width and height supported by the display, not the current resolution. I set my screen resolution to 1280 x 1024, and borderless used 1440 x 1024 again.

Yes, same problem here, I have a 4k TV (But with 1920x1080 resolution set in windows 11 config) and the games are extremely zoom-in, if I set the windows desktop resolution to 4k in the w11 config, then it works without that huge zoom-in (But extremely slow since I'm forcing 4k resolution on my a bit-old-computer. Sure this is taking the maximum screen resolution instead of the selected in the windows 10/11 desktop settings.

[gonetz]

Thanks for the feedback!

EDIT: You're obtaining the maximum width and height supported by the display, not the current resolution. I set my screen resolution to 1280 x 1024, and borderless used 1440 x 1024 again.

Yep, I did not expect that somebody will use non-native display resolution. The issue is fixed. Now the feature should work with any display mode without need to open config dialog.

[LuismaSP89]

Thanks for the feedback!

EDIT: You're obtaining the maximum width and height supported by the display, not the current resolution. I set my screen resolution to 1280 x 1024, and borderless used 1440 x 1024 again.

Yep, I did not expect that somebody will use non-native display resolution. The issue is fixed. Now the feature should work with any display mode without need to open config dialog.

Now is working very nice Sir, ; ) thank you so much for all your hard work.

[gonetz]

New update: if you have several monitors, you may select to which one the borderless window should go. I still don't know, how to select display for true fullscreen mode, but this option is a good workaround.

[gonetz]

Fixed with PR #2686