And more than 1 year after 0.96.0 : raine 0.97.0 !!!

[Tux]

It's a miracle we can still post to the forum with a full disk, maybe the database uses another disk ?
Anyway here is a mega.nz link for now : https://mega.nz/file/OYVAXI4b#uMADM9P6tyzFjRN3kUj90s1spQKI-B188WSJmvIBYDE

[mer-curious]

Duplicated again due to the forum bug...

Edited November 24 by mer-curious

[mer-curious]

15 hours ago, Tux said:

It's a miracle we can still post to the forum with a full disk, maybe the database uses another disk ?
Anyway here is a mega.nz link for now : https://mega.nz/file/OYVAXI4b#uMADM9P6tyzFjRN3kUj90s1spQKI-B188WSJmvIBYDE

Thank you so much for providing this new test build, Tux!

I tried it here and everything seems rightly fixed. The sound device auto-detection works perfectly between different sound output devices set in the Windows desktop. So my problem is finally solved!

My last request related to this new feature is that the "Auto-detect" option became the default option in Raine for new configuration files. This way users wouldn't have to worry about setting this up and possibly coming across the "no sound" issue which happened to me when switching between different devices. The "Auto-detect" option may also work in your mini PC as well as in every other context by default, so I suppose it's safe to have it as the default option at least in new configuration files, no? This way Raine would also follow what other emulators do in relation to this option.

Please let me know what you think about this suggestion.

Except that, I think I may have found the last bug related to the "black frame/black border around the game picture" issue. Yes, I found a new way to trigger it. Here is how to reproduce it:

- run Raine and toggle full-screen mode either by using Alt+Enter or the Full-screen option in Video options menu;
- save your configuration by using the Quit function;
- reopen Raine and load a game;
- when you leave the GUI, you may notice the game picture has now the black frame/black border around the game picture;

Comparison screens:

Normal picture:

Black frame/black border around the picture:

Here's a quick video of me reproducing it in case you need:

https://drive.google.com/file/d/1vh9lk3wqSkwDFQGNJQgehMButhUbzzRd/

I came across this bug by trying to create a "perfect configuration file" without even loading a game first. So I went to full-screen and quit to save the configuration, then when I came back to finally load a game, I noticed the black frame around the picture was surprisingly back!

Anyway, you should be able to reproduce it easily in your setup hopefully. The black frame may be less noticeable if you use a 16:10 aspect ratio monitor, but it will be there too.

Thank you so much again for your various recent improvements in Raine emulator.

Edited November 24 by mer-curious

[Tux]

1) autodetect as default : we used the other way for years and you are the 1st to have a problem with that, I think we can keep the old default for now, I prefer to see precisely my soundcard name when I go to options.

2) your haunting black border : well not for me in linux. Maybe it's windows only... I am terribly tempted to simply stop to support windows, what a marvelous idea it would be ! I might try that in windows later, but for now in linux :

1) removed my config file, started raine, went to fullscreen loaded dino, took a screenshot of the title screen, then quit
2) run raine again in the same config, loaded dino, took the same screenshot, got exactly the same picture, end of the test for now.

... and same result in windows, same picture in both case (compared the files they are identical).

got it, I hadn't the latest binary in windows, it's still the same old problem because I changed the way to get the screen coordinates, in windows we get the height of an invisible windows title bar added, not in linux. 1 line fix, a function name instead of another, but it's really annoying.

At least the site is fixed, back with some disk space, you can get the ultimate test binary there : https://raine.1emulation.com/archive/tux/raine.7z

[mer-curious]

Hello Tux! Thank you so much for this fast fix, as always.

I tried here the latest test build and everything seems right now with the game picture. I enjoyed a good playing session with different arcade games and also Samurai Shodown RPG and didn't see any issues to report. It looks like the bugs with the window manager in Windows are ended hopefully!

There is only one issue left, which is that of the window positioning after leaving full-screen in a desktop with different resolution. But since I am having a seamless experience between different devices now, I don't need to leave full-screen mode often, so it doesn't bother me much...

 

5 hours ago, Tux said:

I am terribly tempted to simply stop to support windows, what a marvelous idea it would be !

Yes, it would be great if someone else joined you in improving the project, especially fixing the Windows bugs. I do my best testing the new features and reporting bugs, but I don't know programming, so I can't help on that part unfortunately.

 

5 hours ago, Tux said:

1) autodetect as default : we used the other way for years and you are the 1st to have a problem with that, I think we can keep the old default for now, I prefer to see precisely my soundcard name when I go to options.

Yes, I never complained about that before, but I think I didn't experience that issue before either...? Maybe Raine was still using SDL1 back then, or maybe the sound output device detection worked differently...?

It may have been a recent change in Raine that surfaced this issue with switching between different sound output devices in Windows, because I didn't use to see that issue when hooking my laptop to the TV...

Anyway, my thinking of letting "Auto-detect" as default in Raine is to prevent this issue from happening with other users in the long term, or even with me again if I happen to forget to set it up manually. I some times delete my config file to test new features and fixes and see that everything works fine from a "new-user perspective", so it is easier and quicker if I don't have to manually set another important option in my testing.

But that change would only apply to new configurations. If you mostly use Linux and try to keep your configuration file for a long time, I suppose it wouldn't affect you, no? You'll keep seeing your specified sound output device showing in the Sound Options menu, I suppose...

All in all, the most important is that the auto-detection feature is finally implemented and working as intended, which is great. For now we need to select it manually, but maybe you'll reconsider this decision eventually...

Thank you again for your great improvements during the last week. Maybe it is time for a new release finally...?

Edited November 25 by mer-curious

[Tux]

Well you can always test the last sdl1 version to check, sdl2 started in 0.92, so the last sdl1 must be in 0.91.15. Also if you saw the post in the other thread, we became xp incompatible with 0.97.2, so it's probably because of the new function to detect the soundcard. It doesn't really matter anyway, xp is ancient now, and you are bound to hit an incompatibility like that if you keep adding new functions. Also something you probably didn't think about, but if you set Autodetect as default, then you will never see which card is selected, it probably doesn't matter much anyway as long as it can be heard, but if you want to have the detect and store result as before, the only way is not to have this autodetect as default. (or modify the interface to show which card was detected when Autodetect is selected, but I prefer to keep things as simple as possible).

And for the unexpected return of the black border : I had actually tested this in windows, but apparently this function doesn't return the same thing when you call it in windowed mode and fullscreen ! So it got me, because I didn't think about saving the config and run again. And it doesn't make much sense, it's supposed to be state-less normally... ! Anyway !

[mer-curious]

On 11/25/2024 at 6:54 AM, Tux said:

Well you can always test the last sdl1 version to check, sdl2 started in 0.92, so the last sdl1 must be in 0.91.15.

Hello Tux! Thank you for your reply.

Just out of curiosity, I went and tried here an old version of Raine and it indeed worked flawlessly when switching from the laptop speakers to the TV ones. I tried version 0.91.21, the last SDL1 version I guess. I noticed it didn't have a sound device selection setting, so maybe it was the implementation of this setting which introduced this issue? Or maybe it was when Raine started saving the sound device firstly detected in the configuration file...?

Anyway, I think I was surprisingly right on my memories on doing this switch without issues before, because it is something that started recently apparently...

 

On 11/25/2024 at 6:54 AM, Tux said:

Also if you saw the post in the other thread, we became xp incompatible with 0.97.2, so it's probably because of the new function to detect the soundcard. It doesn't really matter anyway, xp is ancient now, and you are bound to hit an incompatibility like that if you keep adding new functions.

Yes, I saw pmc2's comment talking about that. I'm really sorry for that. I hate hardware obsolescence. Maybe this change could be reverted without breaking the auto-detection feature...? Or maybe with the improvements made in the test versions so far the compatibility may have been restored?

 

On 11/25/2024 at 6:54 AM, Tux said:

it probably doesn't matter much anyway as long as it can be heard

I think the reasoning behind this decision in other emulators is exactly this, the "default/auto-detect" setting for the sound output device works for all contexts because it may always make the sound work. The user who is not satisfied with it may manually edit this setting if he/she wants...

That's why I also think it makes more sense to have this option set as default in Raine too, applied to new configurations, I mean, so if you have already set your desired sound output device, then it wouldn't affect your setup anyhow.

 

On 11/25/2024 at 6:54 AM, Tux said:

And for the unexpected return of the black border : I had actually tested this in windows, but apparently this function doesn't return the same thing when you call it in windowed mode and fullscreen ! So it got me, because I didn't think about saving the config and run again. And it doesn't make much sense, it's supposed to be state-less normally... ! Anyway !

Thank you for this explanation. It's good that I stumble upon these weird bugs in Windows sometimes, so you can have the opportunity to check and fix them eventually.

Thank you so much again for your attention in relation to the recent bug reports.

Edited November 27 by mer-curious

[Tux]

xp last update was in 2010 or 2011, so it doesn't make much sense to loose too much time on it. I would have kept compatibility but virtualbox removed direct3d support for xp in 6.1 because of a big security hole in their driver, I would have preferred that they would simply add a big red button to click to allow users to install this despite the security hole, but they just removed direct3d support, so it's impossible for me to run any version of raine in xp in virtualbox now, so too many people want xp to disappear.
On my end I quite liked some custom xp editions like tinyxp : small, fast and efficient, but oh well, I guess it's too outdated now.

And it's not hardware obsolescence, you still do what you want with your hardware, you can install something else on it, it's software obsolescence only here.

And the next victim will be win7, but maybe I won't have to deal with that... !

[mer-curious]

Hello Tux! Thank you for your reply, and also for still trying to support these old operational systems, even if they can't do much except be used for these old games and a few arcade emulators.

 

On 11/27/2024 at 10:02 AM, Tux said:

And the next victim will be win7, but maybe I won't have to deal with that... !

Yes, I hope pmc2 can still use Windows 7 or Linux in his old hardware to play with some emulators...

 

Except for these comments, I'm mostly replying to report what I think could be a rare bug: if you load a game with IPS patches presenting ROM conflicts and then try to open the console, Raine will crash. See here:

https://drive.google.com/file/d/1yC7WX9AjTgb32URZ2TSc_qL9hHnLsqtR/view?usp=sharing

I stumbled upon this bug by trying to visit every option in the main menu to see that everything was right with the recent changes. Luckily I was playing KOF97, which has some ROM conflicts in the IPS patches. I couldn't reproduce this crash in other contexts, I mean, using games without patches or games with patches but without conflicts. It seems specific to this very case...

You could try to reproduce it by using my kof97.ini file with some conflicts, here:

https://drive.google.com/file/d/1MRMjay45G9bapkMGFeeCVZSKycF8SQ2G/view?usp=sharing

You can get the corresponding IPS files in this thread:

The patches are either in the YouTube video and/or in the emufrance link. They can also be in the GitHub link. It's a little confusing because I got different patches from different packs I guess. If you can't find them please let me know and I'll upload my kof97 IPS folder for you.

I'm not sure if this crash was expected, but I'm reporting it anyway...

Thank you so much in advance for your time and attention.

[Tux]

No problem, it's very easy to reproduce. It comes from the very special nature of the console, contrary to other dialogs in the interface, it always exists, but since the interface has a parent system to be able to draw the background, it can create problems when the parent of the console disappears. Here because of the error, it takes one of the temporary messageboxes as parent and so the 1st time you try to display it, it just crashes because the parent has disappeared !

Yeah it's normal, this part of the gui is a hack, because I wanted the console to always exist, which is not the normal way of working for this gui.

So there is a workaround, not too complex, maintain a list of active dialogs to be able to check if the parent is still active when drawing a dialog. If it's not, just remove the parent that's all. So patch very short and efficient.

Pushed to git.