Raine 0.96.12 : the revenge of ffman1985 !

[mer-curious]

17 hours ago, Tux said:

But anyway knights is a 16:9 game, 384x224 it's 1.71 16:9 being 1.78), but I guess you took care not to use real fullscreen modes here again didn't you ?

Hello Tux! Thanks a lot for your fast reply and for providing another test build.

Yes, I made sure I was using the full-screen (desktop) mode option in the Video Options menu when I took the screenshots. But the thick black bezels also happen with full-screen (real) mode, so I don't think the issue is related to the full-screen (real) mode at all...

I suppose it is related to the GUI or Video Options menu because the thick bezels only show when enabling full-screen mode (either real or desktop) through the GUI. If you enable it by using Alt+Enter, the bezels are normal (as you see in the comparison screens provided in the previous replies).

I've tried here your latest test build and unfortunately the thick borders are still an issue with this version. On the one hand this is bad because the problem is unresolved, on the other it is good because it reveals the full-screen (real) mode is OK, so maybe it could come back. It's a feature that is not very used by people who come here in the forum but it could have its use cases for someone at some context eventually...

I have tried to reproduce this issue in my laptop too and it consistently happens there. In the laptop I have Windows 10 22H2 version and in my desktop 21H2 (the long-term support version). Both machines have Intel processors with Nvidia graphics chips, the laptop is from 10 years ago but the graphics drivers are from 2019 I guess; and my desktop has more recent parts and the graphics drivers are from 2023 (I don't play much PC games so I don't bother updating very often...).

Anyway, if you really followed my instructions on how to reproduce the issue in Windows and you can't really have the thick borders there when enabling full-screen mode through the Video Options menu, then I may need someone else to confirm that the issue is not within my setups. I may send ffman1985 a message and see if he can test that.

Meanwhile the solution is to just use Alt+Enter to avoid the thick bezels, but it would be good in the long-term to have the full-screen options in the Video Options menu working as good as the keyboard short-cut.

If you need more details on how to produce this issue or to test new preview builds, I'll be very happy to help.

 

17 hours ago, Tux said:

edit : another "confidential" binary for you to play with, it recognizes the 1st 2 emulator keyboard controls from any gui dialog, the 1st being screenshot, and the 2nd switch to fullscreen. Which means that poor windows users who can't take a screenshot using the print screen key will now be able to use the standard raine key for that at least !

Thank you for adding this feature. I tried it here with the latest test build and it's already working, take a look:

Now I can take a screenshot in the GUI.

By the way, I've noticed taking this screenshot that when we are showing the Video Options menu the game screen is shown correctly without the thick black borders. You can see in the screenshot above that there are no thick black bezels in the top, left and right of the screen, which should be the correct display of the picture and what happens when we enable full-screen through Alt+Enter. But if we enable it through the Video Options menu, then the thick bezels will strangely show...

Anyway, hopefully you will reproduce this and figure it out eventually...

Thank you so much again for your time and work.

PS: here's a short capture I took to better illustrate the issue commented above:

https://drive.google.com/file/d/1wPVP-ykHzIpzxOLCJ014Rx4_qqhjE5X5/

Edited October 25, 2024 by mer-curious

[Tux]

Shortest reply ever : no (for everything)

And I wouldn't have seen these black borders in all that time ? Tsss !!! Ridiculous !

I had fun with my own capture tool, obs because the windows bar is allergic to opengl programs clearly, it's a 16:10 screen, 1680x1050 so you don't get the same ratio as on yours, but you don't get any fucking black border (at least not on the right and on the left) : https://mega.nz/file/XUdCXQYQ#HWL-VxqTM1OGbnosgtW_XCVi4He7mT00rHfmX7yE4UQ

and finally a last build which will display numbers for you each time it calls the function to resize the game screen, it will tell you the resolution (of the window, or the screen if you are in fullscreen), and then x, y, w, h of the game screen. Don't use that as your main raine binary because it's probably annoying to get this message box all the time ! This way you can post just screenshots, if you have a software black border then you should see x > 0 and y > 0 from this function, if one of them is at 0 then everything works normally.

Still the same link : http://raine.1emulation.com/archive/tux/raine.7z

[mer-curious]

4 hours ago, Tux said:

Shortest reply ever : no (for everything)

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?

 

4 hours ago, Tux said:

And I wouldn't have seen these black borders in all that time ? Tsss !!! Ridiculous !

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

 

4 hours ago, Tux said:

I had fun with my own capture tool, obs because the windows bar is allergic to opengl programs clearly, it's a 16:10 screen, 1680x1050 so you don't get the same ratio as on yours, but you don't get any fucking black border (at least not on the right and on the left) : https://mega.nz/file/XUdCXQYQ#HWL-VxqTM1OGbnosgtW_XCVi4He7mT00rHfmX7yE4UQ

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.

 

4 hours ago, Tux said:

and finally a last build which will display numbers for you each time it calls the function to resize the game screen, it will tell you the resolution (of the window, or the screen if you are in fullscreen), and then x, y, w, h of the game screen. Don't use that as your main raine binary because it's probably annoying to get this message box all the time ! This way you can post just screenshots, if you have a software black border then you should see x > 0 and y > 0 from this function, if one of them is at 0 then everything works normally.

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.

Edited October 25, 2024 by mer-curious

[Tux]

You're becoming dumber and dumber here... !

Of course there is a black border on top OR on the sides, re-read what I have told for ages this is the normal behavior !!! When the game screen is scaled the same ratio is applied to the horizontal part and the vertical part, since the ratio of our modern screens don't match what they had for these games most of the time you get a black border somewhere, but it's done to fill at least vertically or horizontally the screen so you can't have both at the same time. There are options in the renderer option to play with this but if you want to keep the original screen ratio you shouldn't touch them.

Of course the ctrl-s can't work correctly when the resolution is displayed, this is a debug feature, it's displayed just before the frame is drawn, you could have guessed that !

And finally for your video : bad choice of  a game : if you play it in a window, you'll notice the top part of the screen remains black during the demo, it's a game which plays with borders on top and on bottom, I guess it's to look like a movie, take a game like bublbobl which is a real 4:3 game. You even saw the prompt telling you the coordinates of your game screen : 63x0, meaning 0 pixels from top and still you could see a black border on top, that's because the game displays it that's all !
And all these posts for nothing then... !

At least I hope you have understood now... ! I think you can delete the build which displays the game screen coordinates it shouldn't be useful after that.

 

 

 

[mer-curious]

On 10/25/2024 at 5:06 AM, Tux said:

Of course there is a black border on top OR on the sides, re-read what I have told for ages this is the normal behavior !!! When the game screen is scaled the same ratio is applied to the horizontal part and the vertical part, since the ratio of our modern screens don't match what they had for these games most of the time you get a black border somewhere, but it's done to fill at least vertically or horizontally the screen so you can't have both at the same time.

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

Edited October 27, 2024 by mer-curious

[Tux]

As I already replied a million times (it feels like a million times at least), I will keep this short : not here. So remember this clause which tells that free programs are given without warranty even though they are supposed to work the same way everywhere ? You are in the 0.1% cases where it doesn't work the same way, absolutely no idea why, sorry for your case, but obviously I don't have that and no idea how you can have it since as I already told, using the gui or alt-return calls exactly the same code !

So, sorry for your niche case, I'd advice you to use the keyboard in this case even if it doesn't seem to make much senses.

If you ever find out why you have such a curious behavior, post again, otherwise you can stop, it's useless.

[mer-curious]

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.

 

Edited November 3, 2024 by mer-curious

[Tux]

Ok, it happens, windows only of course I would have spotted this long ago in linux, it's not so old it started around 0.96.10, because of the windows tricks which was probably the worst idea I ever had !

It's even worst that what you say because once the video is broken this way, it's saved in your config file and you'll find the same broken video next time you launch raine.
It's easy to fix manually though, it's just screen_y in the config file which gets a bad value, just put your real screen height here and it will work, at least until you return to the windowed mode before switching again to fullscreen this way.

It's not easy to fix because this has become an intricate mix of craziness to work around the strange behavior of windows, my 1st attempt to fix it triggered an even worse bug. So for now either switch back to 0.96.9 or before, use the keyboard, or switch to linux !

For info the size of the black border on top is exactly the height of the title bar for a maximized window, it's a windows bug you see here, it doesn't happen when using the same binary in wine in linux. I am tempted to remove all this windows craziness, but even that has become complicated for now, so for now it will just remain as it is for now, I might return to it later, I already lost way too much time on that.

[Tux]

Ok, did a minimal fix, you can test it at the usual place : http://raine.1emulation.com/archive/tux/raine.7z

This forced me to reinstall the dev tools in windows, which showed me that the compilation of the 32 bits version was broken in mingw32, so nobody did that clearly ! Actually I had never reinstalled these after upgrading my windows disk which is now a ssd about 1 year ago or so.

Anyway the fix is at 2 levels, it forces the desktop size to the video mode size instead of looking at the usable area, but except that I got a stupid game screen in the lower left part of the screen when I was in fullscreen, only for the 64 bits version, so it forced me to make the binary in mingw32 and not in linux as usual, there is clearly some dll problem, probably specific to windows 10/11 somewhere.

So this archive is bigger, it includes a new libcrypto-3.dll which was not required before.
Also since the bug is saved in the config file, the fix can work only if raine is not started in fullscreen with a broken config file, if it's the case you need to return to some windowed mode and switch again to fullscreen, or delete your config file.

It seems to work for me, I guess I'll have to make something more official after that mess...
Problem is that it probably breaks compatibility with old windows version for good this time. It's not my fault, it's the way windows is made, they willingly make things harder and harder to stay compatible with old versions.

edit : and uploaded a new dlls64-0.96.7z with an updated SDL2.dll, 0.28 was becoming quite old. This should still be compatible with all 0.96 versions, and the libcrypto-3.dll is only in this raine.7z package for now.

[mer-curious]

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.

[Tux]

Yeah it's the quarter picture I got because of the dll problem, I guess I didn't get the right one then... I'll see that later.

But all this mess is a windows non sense, I just loose time here, had to reboot an incredible number of times while testing things since I couldn't reproduce the bug in linux and windows didn't have any decent dev tools installation yet. What a waste... Did I mention I really hate windows now ?

Anyway since I got this thing working here it's probably a detail to pinpoint so I'll finish this.

[Tux]

Alright fixed normally, and finally it was not a dll problem, just the usual kind of bug you get when you mess too much with windows statuses, and it could happen in linux too (the small screen in fullscreen).

Test when you can the good news is the new dll is not needed anymore, you can delete it if you still have it, it's a return to the normal build process from linux !

http://raine.1emulation.com/archive/tux/raine.7z

[mer-curious]

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

[Tux]

No, there's no good reason to re-add it. The main reason why most games prefer desktop fullscreen games is probably because there are less issues when alt-tabing out of the game and you can have some windows visible on top of the game screen without issue, which is impossible with the real fullscreen, it's totally exclusive and it can have sync issues sometimes. The desktop fullscreen is the modern way to do that, the real fullscreen was the old way.

Glad to see it's finally fixed, it was the most annoying series of bugs to fix, especially when you think that it was not even related to real emulation !
Most of the fixes are short, it's not complex code, but you just need to guess what needs to be done, there are more comments in the code and in the git log about all that.

[mer-curious]

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

 

On 11/4/2024 at 8:16 AM, Tux said:

Glad to see it's finally fixed, it was the most annoying series of bugs to fix, especially when you think that it was not even related to real emulation !

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.

Edited November 7, 2024 by mer-curious