mer-curious

Thank you so much for this new test build, Tux! I have tried it here and the issues are finally gone! The game picture is perfectly resized now to match the smaller monitor resolution, and the sound is no longer stopped if you visit the Sound options menu. Everything fixed correctly. Yes, I understand, I'm sorry for the extensive reports. It's just that sometimes I think that a video may illustrate better what I write with words. Anyway, I still have some things to report about these issues. I saved my configuration file on the desktop/laptop monitor and then thought of switching back to my Samsung 1080p TV to see if everything would be working fine when going back to the big screen. Here is what I've found: 1) The game picture will retain the smaller resolution from the monitor and show it in a frame in the bigger resolution screen, take a look: https://drive.google.com/file/d/1Tv4p5PJjDWXKVTBUrd0uPvjPA-C669b_/ This is my laptop monitor configuration (1366x768) running in my desktop monitor (1600x900). You notice that the frame is not so big because the resolution difference is not big either. And this is my laptop monitor configuration (1366x768) running in my 1080p TV screen (1920x1080): https://drive.google.com/file/d/1wMUdgELxPv_LX-pZxZqwWZtmFOFWrY5d/ Notice that the black frame is now bigger because the resolution difference is bigger. I suppose that if I used this same configuration in a 4k TV there would be an even greater frame difference. Maybe this escaped from your testings in this test version. Hopefully it will be easy for you to fix it... 2) The program no longer auto-detects the Samsung TV speakers set as default in the Windows desktop, so I have no sound in Raine, as you see here: https://drive.google.com/file/d/1OBhQiy9V20TV6uDv7_JrGoM5hH39RyZA/ You see that even if you visit the Sound options menu, it will stick to the Realtek HD Audio sound output, even if in Windows desktop I have set the Samsung TV speakers as default. I was wondering how you could fix this and thought of maybe doing what most emulators do: add a "Default" sound output device value to the sound device setting. See this option in Duckstation: Now see it in PCSX2: So this could maybe be the solution for this problem, no? It would allow the program to always detect the default sound device which is being used by the Windows desktop, be it the internal PC speakers (in my case, Realtek HD Audio), the external display speakers (Samsung TV) or others. If the user wanted to set a different or specific sound device, then he/she could select it by the list reported in Raine. The Default sound device value could be 0 or 1 in the config file, and then the other sound devices could start at 1 or 2, 3, 4 and so on. Let me know if this could be a good idea to fix this issue. Anyway, hopefully this can be the beginning of the end of these sound device and window manager issues in Windows... Thank you so much again for your continuing work in the emulator.

Thank you so much for providing a test build! This may be useful to avoid several hot-fix releases in a short time. I made a quick test here with this test version using my current configuration file in Raine, that is, the one created with the desktop computer/laptop computer hooked to the TV to check if the problems have been solved. Here are the results: - the issue with the game picture not resizing appropriately for a smaller resolution display is still present in this test version. I no longer have a game picture out of bounds though, it is just a black screen now, take a look: https://drive.google.com/file/d/1vQ2OyXaRyxgjJy2nRgrpZk5R4uM0AKCM/ So the change you implemented did change something in this regard, but it is not perfect yet. Hopefully you'll be able to understand what is going on with this issue... - the issue with Raine not detecting the current sound output device and showing a "None" value in the Sound options menu has been partially fixed. This is what is happening now: 1) if you load a game before visiting the Sound options menu, the sound device setting will be normally filled with the current sound output device found in Windows, take a look: https://drive.google.com/file/d/1ly7fQTWlOnHFJwD27v0Yat66gf-X_0h3/ The sound seems to work normally in this case as far as I've tested. 2) if you visit the Sound options menu before loading a game, then the "None" value will remain set as the sound output device and there will be no sound during the game play. This will also trigger the "Z80 error/MVS slot check" error in KOF2000 as mentioned before. See here: https://drive.google.com/file/d/1jJInRBM7Z0bxba7P0vc2_sgxxN743pNk/ So, the change you have implemented did fix the issue with the sound device detection, at least partially. There is only the case that if you visit the Sound options menu before loading a game, it will trigger the issue and then the sound will be broken. In case of KOF2000 and possibly other NeoGeo games, it will also produce the "Z80 error/MVS slot check error". The Z80 error does not allow you to play the game, as you see here: https://drive.google.com/file/d/1o05mq-RM6tg0leivib5vXm4e9v9q7o4Z/ Hopefully this test will be useful for you somehow when checking those issues again. Thank you so much for your time and work.

Hello Tux! This is really good news! I should be testing these workarounds as soon as a new version is released. Thank you so much for that. Hopefully those were the last issues related to the sound device detection and the window management feature... No problem, I cannot reproduce this issue in a normal installation either. It only happens when I have the configuration file created in my TV with my laptop or desktop computer and then try to use it with the monitor, that is, when you have the "None" value in the Sound options menu. If you have set the Unibios, it will show the "MVS slot check" error. If you have set the default Europe bios, it will show the "Z80 error". Just out of curiosity, I took the configuration file created in my laptop and tested it in my desktop computer and could consistently reproduce the error. Here's a capture showing the procedure I make, if you would like to try it once more: https://drive.google.com/file/d/1AhpKDgOwk9YeR_LdLURSosRSIqzbQCla/ As you see in the video, you need to visit the Sound options menu before loading the game to trigger the error. I have provided above the configuration file created in my desktop connected to the TV. Now I provide the configuration file created in my laptop when it was connected to the TV: https://drive.google.com/file/d/1AXfBp2K1VwRDILBorzrpnzZsNsdcXwxA/ I'm not sure it will make a difference in your testing, but since you couldn't reproduce it at all, maybe you could try it with this one too...? Anyway, I am already glad the other two issues have been fixed. Thank you so much again for your continuing work in Raine.

You are correct! I'm so sorry for that. The issue was with my earphones, one of the channels wasn't working correctly, and so the NeoGeo logo was sounding weirdly here. I suppose this logo may use the left and right channel to produce different sounds, and so if one is not working correctly the music will sound incorrectly. As for the error message in KOF2000, I think it only happens when you have the "None" in the Sound options menu. I couldn't reproduce it in a normal installation, I mean, an installation that is created in the computer using the computer monitor and the Windows desktop is set to use the computer built-in sound output. If you would like to reproduce this issue you would need a TV or monitor with built-in speakers or a second sound output device to create a configuration file based on that setup and then disconnect the TV/monitor/second sound card to see if Raine shows the "None" there for you too. Perhaps you could try my configuration file? I'm not sure if that would work, but here it is: https://drive.google.com/file/d/1szTZAjTJbct1E0dtKA6YSDtsgwviCWXl/ If you happen to have "None" in the Sound options menu then you may finally see this error in the game. You have to visit the Sound options menu before loading the game, or if you are using Unibios visit the Sound options menu when the game is already loaded. The error message may appear after the game attract demo. You can see the procedure I do in my capture in the previous post. I really apologize again for the mistake in my previous report. Thank you so much for your time.

Thanks for the fast reply Tux! Yes, I agree with you that most of these issues would probably be solved by having two installations of the program. But I think one installation is fine for most cases, it's just these minor issues that I come accross in my user experience that happen to bother me and then I report them here to see if they could be fixed. By the way, I tested Raine for a little longer with the configuration file created in my TV and found out that the sound is not working correctly, contrary to what I said in the previous post. Hearing it more attentively I noticed the sound effects sound poorer in quality, and the NeoGeo logo is sounding weirdly too, check here: https://drive.google.com/file/d/1PaQeQY5JEXnEhkfjk8JTkl-57_Fj09Pr/ So even before visiting the Sound options menu the sound seems already broken unfortunately... Interestingly, if you visit the Sound options menu before loading KOF2000 you will have this in the screen: And if you visit the Sound options menu when the game is already loaded the Unibios may show you this after the game attract demo: Maybe this could help you find the solution for this problem...? You can see this error happening in my video capture shared above. Anyway, hopefully you will grow some motivation to test theses issues eventually... Thank you so much again for your continuing support.

Thank you so much for this fast fix! I hurried to test it here and finally Raine auto-detects my TV speakers when they are set as default in the Windows desktop! But I think I have found a final issue related to that: I play normally on my TV and then quit Raine through the "Quit" option to save the configuration. Then I disconnect the computer/laptop from the TV and return to playing in the monitor/built-in laptop display. Raine again can auto-detect the sound device in the Windows desktop and the sound works normally, which is the expected behavior. But if you happen to visit the Sound options menu, the sound device is filled with a "None" value and then the sound won't work anymore. See: So, the emulator is working correctly now, the issue is that if you visit the Sound options menu, it will screw the working sound output configuration. Hopefully you'll find a way to reproduce and fix this when you have some free time. Now I would like to report what I think is the final bug related to the window manager: If you play in a bigger resolution display, save your configuration file in full-screen mode, then run the emulator in a smaller resolution display, the game picture will preserve the bigger resolution size and be out of bounds. I came across this issue only now because of the recent tests with the sound output between the TV and the computer monitor. I finally saved a configuration file because everything seemed to be working perfectly in Windows at last, but then I found this issue when I returned to the computer monitor. I've recorded a short video to illustrate the problem, take a look: https://drive.google.com/file/d/1xvpE7JnLcP7kBtZuM-upbcEkItSgxBUY/ So, to reproduce this you need to find a way to run Raine in a bigger resolution display, go to full-screen mode, save a configuration file and then open Raine again now in a smaller resolution display. You'll also notice in my video that when you leave full-screen mode the Raine window will not be very well centralized in the new monitor desktop resolution. I don't know if this could be also fixed, but it is either way a much minor issue in this report. You mean in Raine's root folder, right? In my case I keep the bios file named as "neocdz.zip" to differentiate it from the first NeoGeo CD bios. But I don't have it placed in the root of the emulator, I have it within my arcade games folder. But anyway, I guess I can live with that. I don't need to set the bios path every time, I just happen to do it frequently because I erase my config file to see if the program is working fine in a new fresh installation of the program, which is what a new Raine user would mostly experience. Thank you so much again for your time and work in the recent bug-fix releases. I am glad that the Windows version of Raine if becoming as functional and operational as the Linux one.

Hello Tux! I'm sorry for the late reply on this report. I tested again the sound device saving operation and it is indeed saved as you said. But I think I found what led me to think it wasn't being saved. There are two bugs related to that: 1- if you load a game, the sound output device is reset to the 1st one found in the computer. 2- whenever you visit the GUI, the sound output device is also reset to the 1st sound output device in the computer. That is why I was reporting the sound device selection wasn't being saved, it was being hindered by these two bugs. I suppose they might be related to the changes you made to the sound device selection recently, no...? Anyway, I've recorded a video showing the issue in my laptop, here: https://drive.google.com/file/d/10gQmloPfmz9JPYedt_BL9_jzpTkw6eJD/ You see in the video that the sound device is reset as soon as a game is loaded in Raine, and then if you go to the sound options and select your desired sound device, it will be reset again whenever you show the graphical interface. I think this is a very weird bug... Hopefully you'll be able to reproduce it in your setup and fix it when you have some free time. You mean you don't know the code for that or that it is a limitation from the SDL2 library? I could open a feature request in the SDL2 GitHub page if it's the second reason maybe... Finally, I have a feature request: Currently we have to go the NeoGeo CD options to set the CD bios path in order that the program identifies it. I was wondering if Raine couldn't look for the CD bios automatically as well as it does for the NeoGeo ROM bios. So, when defining the NeoGeo ROM bios or the NeoGeo game ROMs folder it could also look for the NGCD bios in files such as "neocdz.zip", "neocdz.7z", "neocd.zip", "neocd.7z" or similar formats and set the path for it. If it doesn't find it, then we could manually configure it in the NeoGeo CD options. Maybe this would let the NGCD bios configuration process more user-friendly... Some users might use Raine just for NeoGeo CD emulation, for this case the manual bios configuration could be used instead. I will wait your comments on that. Thank you so much for your attention. PS: I created another pull request to suggest a subtle revision to the fullscreen option. I also noticed the Raine controls are not translatable yet. Perhaps they could, no...?

Hello Tux! Thank you so much for this new release. I hope more users can also benefit from the fixes to the window status, and from the other changes too. Here I have a quick and short feedback for this version: - the issue with the default sound output device detection is still present in this version unfortunately (and in version 0.97.1 as well). Raine can't detect the sound device which is currently used in desktop. Also, the sound device setting is not saved and restored if we change it and reopen the program after properly quitting it. Perhaps this could be fixed too...? But I think the most important improvement would be to detect the sound device set in desktop when the program is opened and use it as default, because this is what happens with most emulators, so users are not used to configuring that. I think this would let Raine more user-friendly, especially when using it for the first time. Anyway, hopefully you'll be able to test this in a Windows device and finally see what is going on with it. Thank you so much again for your work. PS: there are some very cheap USB sound cards available in the market which could be possibly used to reproduce this issue (see here: https://www.aliexpress.com/w/wholesale-usb-sound-card.html). But I don't think it is worth it getting one just for this test, unless you know someone who could lend it to you...

Hello Tux! Thank you so much for trying to fix this issue so quickly. I don't have a second sound card here either, I only have the one on the motherboard. The second sound device which shows in Windows is the TV speakers. I connect my desktop or laptop computer to the TV via HDMI input/output and then Windows automatically sets the sound device as the TV speakers (in my case, a Samsung TV). So, if you have a computer or laptop with HDMI out and a TV with HDMI in you should be able to reproduce this issue with the selected sound device in Raine. Otherwise, you could provide a test build again so I could see if the issue is indeed fixed. I'll be glad to do that. Thank you so much again for your time and attention. PS: there are also some computer monitors with internal speakers, but I don't have one here.

Hello Tux! Thank you so much for the details on the "real full-screen" mode. Now I understand your rationale. So it still makes sense to have the option named as "Yes (desktop)", as far as I've understood? Or perhaps it would be better read as "Full-screen mode (Desktop)" and have the alternatives named just as "Yes" and "No"? I think I could do that and fix all the linked translated strings in the code if you agreed with the change... Now that the full-screen issues are gone, I could finally play with the emulator regularly again and I think I've stumbled upon two issues: - the left arrow key in the keyboard can also enter/confirm actions in the GUI. Is this expected? - Raine is not following the sound output setting configured as default in desktop. Apparently it selects the first sound output offered by the driver, which in my case are the computer speakers. I came across this issue recently when I connected my laptop computer to a TV and had no sound coming from Raine. Then I tried it with my desktop and had the same result. Here is what Windows sets as default when I connect my computer to the TV: The selected option is the one in blue, the Samsung TV internal speakers (click on the image to magnify). And here is what Raine sets as default: It selects as the default "Sound device" the computer speakers, and if you don't have any connected, you will hear nothing in the game. I had to figure out why no sound was coming from the program, and then finally found that the issue was with the sound device selected by Raine as default. So, I was wondering if it wouldn't be possible to have Raine select as default sound device the one currently set in Windows desktop. I suppose this would let the program a little more user-friendly, especially for new Raine users which are used to playing with other emulators. As far as I remember, most emulators don't need this kind of configuration, they just use the sound device currently set in the desktop. But I'm not sure how doable this would be though... Anyway, I'll wait your comments on that. I can also test another preview build if you need. Thank you so much again for your work.

Hello again Tux! Thank you so much for your fast work! I tried it here with the latest test build and the issue is finally gone! Here I have some screenshots to compare: Full-screen with the GUI option: Full-screen with Alt+Enter: Full-screen with the GUI option: Full-screen with Alt+Enter: I tried to enable full-screen mode from the GUI and then disable it through the GUI and everything seems to be working correctly. I also tried to enable it through the GUI and then disable it by hitting Alt+Enter and no problems so far. I made these tests with all default configurations and no config file created. I was wondering if the GUI was really causing this issue as I suggested... or was it something more complex? Anyway, I'm glad that all GUI options are working perfectly again. Using the graphical interface in full-screen mode is more suitable when playing from a distance from the display, so this fix will be helpful if it's necessary to enable or disable this mode in that situation. Thank you so much again for the time put into this fix. PS: do you intend to re-add support for real full-screen mode. As far as I understood, it was not causing this issue, was it? Maybe it could have some use cases...?

Hello Tux! I'm glad you could finally reproduce and understand what is going on with this issue. Fortunately my test in 16:10 monitors was worth it in the end... So, I have tried here the latest test build you provided in this thread and I am getting something different now on the screen. It's not perfect yet though, but something did change. Take a look: So the issue is not fixed yet, but something changed. I tested this with no config file created in Raine, 64 bit version. I just open the program for the first time, load the game and go to the Video Options to enable full-screen, and then leave the GUI to show the game picture. Enabling full-screen through Alt+Enter is still perfect, see: Anyway, hopefully you come up with a solution for this eventually. Please post here a test build again if you need someone to try a new solution for this problem. I'll be glad to try it. Thank you so much again for your time and work.

Hello Tux! Thank you so much for your reply. As a final report on this issue, I had the idea to test Raine in a 16:10 aspect ratio monitor because this is the one you have there. Maybe this could help you finally notice the issue in your setup. But I don't have a monitor with that aspect ratio here, so I put Raine in a thumb-drive and took it to a shop which had some electronics available for testing. Hopefully I found exactly two laptop models which had that aspect ratio in their displays (all the other ones had 16:9 screens, which seems to be a standard for gaming and general-use computers). They were expensive Galaxy Book models, I believe Galaxy Book 4 Pro or Ultra with 2880x1800 displays on both of them with different screen sizes. They also had Core Ultra 9 or 7 processors with RTX 4070 GPUs. The system on both of them was Windows 11. I confirm the full-screen issue is reproducible in monitors with such aspect ratio. I took some screenshots so you can compare the difference: Full-screen toggled with Alt+Enter: Pay attention that the game picture is perfectly centered in the display. Now compare with the full-screen mode enabled through the GUI: Notice that there is a bigger bezel in the top, the GUI applied some kind of zooming/repositioning effect on the game picture. The game picture is no longer perfectly centered in the display, as it ought to be in my opinion. More screenshots to compare: Alt+Enter: Full-screen through the GUI: The issue is more noticeable with 4:3 aspect ratio games, take a look: Full-screen with Alt+Enter: Game picture is perfectly centered in the display. Full-screen through the GUI: The game picture suffered some kind of zooming/repositioning/redimensioning in this case, resulting in bigger bezels on top and sides. More screens: Full-screen with Alt+Enter: Full-screen through the GUI option: So, I suppose you didn't realize it before because the difference is more subtle in widescreen games displayed in 16:10 monitors, but it is there too. It becomes more noticeable if you try 4:3 aspect ratio games such as NeoGeo ones. Also, it should be possibly only spotted in Windows, so if you are trying to reproduce it in Linux you should not be seeing it at all. It seems to be a minor issue though, but it would be interesting if you could finally see what was causing it if you ever have time to do it... Anyway, thank you so much again for all the time and attention spent in this report. PS: notice that if I use the debug build which you shared in this thread the Alt+Enter method no longer works to have the game picture perfectly centered in full-screen mode because after hitting Alt+Enter a GUI window (the "Reclip screen:") shows, which triggers the zooming/repositioning/redimensioning effect in the game picture.

Hello again Tux! I think you may have misunderstood my bug report about this issue. My complaint is not related to the black bezels eventually shown in the screen to fit the monitor's aspect ratio. The issue is that the bezels are being created only when we enable full-screen through the GUI. If we enable full-screen by Alt+Enter, the bezels don't show, which I think should be the normal behavior. That is, something in the GUI is producing extra bezels, something wrong is happening in the GUI that produces these extra bezels in the screen. This is the issue I have been experiencing and reporting through this thread in the recent posts, and this is what should be fixed in my opinion. I have asked you before to reproduce this issue and you said you were unable to do it, or perhaps you were unable to notice it? Anyway, I'll describe the procedure once more, this time as objectively as I can. Please pay very close attention to the details below: My setup: Windows, Raine 0.96.12a with no config file. Open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (no black bezels on top and no extra bezels on both sides): Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top and extra bezels added on both sides): 1) Can you spot the difference in the picture? Pay very close attention to the bezel created on the top of the screen and the extra bezels created on both sides. 2) Why is this happening? Results with a 4:3 game (not really necessary to support my report but can help you to better notice it): Same procedure: open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (no black bezel on top and no extra bezels on both sides): Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top and extra bezels added on both sides): 1) Can you spot the difference in the picture? Pay very close attention to the bezel created on the top of the screen and the extra bezels created on both sides. 2) Why is this happening? My setup: Windows, Debug Raine with no config file. Open the program -> load the game -> hit Enter in the "Reclip screen" prompt window -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (bezel created on bottom of the screen and extra bezels added on both sides): Now in full-screen hit Enter in the "Reclip screen" prompt window to make it go away. Resulting picture (bezel swapped from bottom of the screen to the top and extra bezels kept on both sides): Conclusion: Alt+Enter toggle method does not work in the debug build because this build has a prompt GUI window that shows when the program goes full-screen mode (the "Reclip screen" info), resulting in the production of the bezels. The "Reclip screen" prompt triggers the creation of a bezel either on top or bottom and extra bezels are added on both sides of the screen. Why is this happening? Your setup (based on the video capture you shared in the thread): Windows, Raine 0.96.12a with no config file. Open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (expected results: no black bezel on top and no extra bezels on both sides): (Incoming picture...) Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top; apparently no extra bezels added on both sides): So you do have the issue in your setup too apparently, you just didn't realize it. This is a guessing, but I can't prove it because your capture does not depict the game screen in full-screen mode using the first method (the Alt+Enter toggle). You need to follow my procedure in Windows (open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode) and see if the screen will have a bezel added to the top or not (it should not, according to my testings). I would be very thankful if you could make this final effort in this issue and make this test using the first full-screen method in Windows. It would be extremely uncommon to have this issue only in my setups. It's not a major issue though, because it only happens in some situations (in a debug build or when enabling full-screen through the video options menu), but if you reproduce it you could finally understand what is causing it and possibly fix it. Thank you so much again for your time and attention. PS: 1) I have the same results in 3 monitors, one is 1600x900, the other is 1366x768 and finally one is 1920x1080 (a TV). They are all 16:9. I wish I had a 16:10 to test on it... 2) I don't know the technical terms for that, but perhaps something in the GUI should be triggering some kind of zoom effect and/or repositioning effect in the picture? This could be causing this "borders effect" to show...

Hello Tux! Thanks a lot for your fast reply. I didn't understand your answer exactly. You mean that you are not going to re-add the real full-screen mode? Maybe not, because it only happens when you enable full-screen through the Video Options menu, and maybe only in Windows...? If you use Linux most of the time and set full-screen by using Alt+Enter, the chances to notice the thick borders would be very rare I guess... As for myself, I only stumbled upon this issue recently when trying to fix all the window manager bugs, which is a feature added recently... But I haven't tested old versions of Raine to check when this issue was introduced, or if it was always there... Yes, you don't have a thick border on the sides of the screen, but you do have one on the top, which I also have in here. Take a look: This is from your video capture. It would be necessary to compare this screen with another one using Alt+Enter in your setup to set full-screen mode. If my guesses are correct you should also have a game picture without this thick top border, which is also what happens to me here. Thank you for trying to troubleshoot this problem. I downloaded the test build and here is the screenshot for when I am in windowed mode: And here it is when I toggle full-screen in the Video Options: You see that the CTRL+S feature doesn't work correctly when this "Reclip screen" prompt is showing in full-screen. But from this screenshot we can also notice a thick border in the... bottom? That's why my guessing is that the GUI is interfering with something in the game screen, which would explain why the thick bezels only show when I toggle full-screen using the Video Options menu in the GUI. Anyway, I have captured a short video showing my testings with this most recent build, take a look: https://drive.google.com/file/d/1H_1XOFgp_C51VhbITHQS54_blXaIJKU-/ By the end of the video (around 1'20~1'24) you'll see that I enable full-screen mode using Alt+Enter, and curiously the thick borders will also show in this situation (!). If you pay attention the "Reclip screen" prompt also shows there, so I'm really suspicious that something in the GUI is causing the display to show these thick bezels when we go in the game screen... Hopefully you will unveil this mystery eventually... Thank you so much again for your time and work put into this issue.