Raine 0.96.12 : the revenge of ffman1985 !

[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 4 hours ago by mer-curious