Tux

For the smaller screen : yeah it can be done, I thought about it after posting this binary, easily done. For replacing 1 soundcard by another one : not convenient for now, it obliges to change a number by a string as a setting, and for now I prefer to avoid it, so I think it's going to be my limit, you'll have to live with it !

Ok, I'll take a look later, but there's no need to make a video all the time, just saying 1 load a game while being in fullscreen, the game starts normally while in the gui 2 go fullscreen -> the screen becomes blank It's shorter, takes less time, and is more efficient for everyone. I have tested this too fast, seeing that the gui seemed ok in fullscreen I assumed it was a windowed problem only. Later, then... edit : well sorry for my mistakes, I was half awaken when I did that and it shows, I went way too fast especially for the video resizing part. For the sound I didn't think just opening the sound options would make such a mess in such a case ! Anyway it's fixed again, you can have your test which was indeed useful here : http://raine.1emulation.com/archive/tux/raine.7z

Oh well you can always test this binary, since normally it can now work around the issue of soundcard not present you shouldn't be able to reproduce this error with it. https://raine.1emulation.com/archive/tux/raine.7z

No idea how it was broken so I can't do anything about it, sorry ! I would love to have someone maintain the windows version, it would be a lot less troubles for me ! Actually there are very few patches between 0.97.1 and 0.97.2 of course since it's mainly about the sound problem alone, raine does nothing fancy in this version, just calling sdl2 functions which were not called before, so I guess your incompatibility comes from there. But as explained before there is nothing much to do about it after a certain point, Microsoft does this willingly, they do nothing to maintain their old versions, not even security patches, and keep on adding new kernel functions to the new versions which are then used by some libraries. After a while the new functions become unavoidable and you have an incompatibility.

After some thinking, it's not so hard to add a small test for the video info to keep the window within the screen boundaries in case the physical screen has changed since the config was recorded, so I did just that. And in case the recorded soundcard is not available to just force a re-detection of it. 2 small workarounds for people who change their config all the time on their laptops while still keeping things easy, it should work... But I won't track the z80 error, yeah it can report an error like that if sound config is messed up when booting the game, even if I can't seem able to reproduce it for now no matter what.

I won't try to recreate a rare bug, it's rare so just avoid it that's all. There are known issues in sound like changing the sample rate in a game which use fm music after the game has started will produce bad sound, the known workaround is just to quit when you change the sample rate. Yeah I know it's not super ideal, now if someone wants to send patches to improve all this, I'll accept them ! It's assumed people can setup their sound once and then keep the settings for normal play. A program which works in all conditions is a crazy thing, that's something you learn quickly when you learn how to program, even if you try to do it with some sample code it can quickly become crazy. Now for some safe environments where it's a necessity, people try to keep programs small to avoid that things become too crazy. For raine it's already very big, you have to be a minimum reasonable about what to do in this case, it's already working as well as possible with some pitfalls which can be easily avoided.

Not for me, and really I get more and more tired of this... !

Of course it was never thought to be used on a machine which changes its setup like that, it's supposed to be stable. Well you can always install in 2 directories, 1 for your tv and the other one for the laptop, that's clearly the fastest solution because raine has worked like that for something like 20 years so I don't think I'll change that now, and I am not even sure how I would do it anyway. For your sound option which disappears after you remove the tv, well same thing I guess, delete your config file if you want to keep just 1 install to allow it to reset its settings for the new setup. That's an idea for later eventually to allow it to detect such radical configuration changes, but I won't make a hotfix for that.

For the soundcard detection and handling when there is more than 1 soundcard on the system ! All this went haywire because sdl2 SDL_OpenAudioDevice never returns 1 for compatibility with sdl1... !!! And also the fact that I never had the opportunity to test on a proper system with 2 soundcards. So if you have only 1 soundcard and everything works fine, no need to update this time ! http://raine.1emulation.com/download/latest.html

This part alone almost made me crazy. There is a compatibility hack in sdl2 to stay compatible with sdl1 so that it never returns the device id 1 on success when opening an audio device ! So it means you must ignore the returned device id (if using something else than autodetect). Crazy stuff... I'll fix that ASAP... It's changed in sdl3, it correctly returns the logical device id which was opened, I guess sdl3 is soon now. I would have spotted this earlier if I hadn't changed my installation here, no 2nd audio card to test... oh well... !!! Ok, fixed. The autodetection is totally different now, it can't rely on opening the device as it did before, so it might work better for you now. Tested in many configurations, it should be ok everywhere. For the neocd bios, yes it looks for neocd.zip in the raine directory, it can't look anywhere else since there are no roms directory in neocd. It's always been like that.

Impressive !

No idea, but as you said, it's not important as long as the setting is properly saved and restored since it takes just a few seconds to setup that. Tested with the latest version, and it is, so that's all that matters for now, if someone wants to investigate further, he's welcome to ! for your change, I changed the way the soundcard is 1st selected in 0.97, I let sdl2 choose instead of always selecting the 1st one, but I don't know how it chooses ! It was discussed in another thread, started by mer-curious too. Notice that if you preserve your config file and always unpack a new version in the same dir, you won't notice this change.

Non issue, already talked about it. And no sorry, already said but I can't detect your desktop sound setting (and really don't care). I tested that quickly in the mini with its 2 soundcards and selecting the 2nd soundcard was saved when quiting normally using the quit command. You can check it in the config file in [Sound] section, sound_card is just a number, 1 for the 1st sound card, 2 for the 2nd, and so on. edit : and in windows too of course, I plugged this usb soundcard which became the 1st soundcard in windows for god know which reason but anyway at this point I could change or keep the soundcard in raine and it was saved all the time. End of the problem for me.

It mainly fixes the untested games in 0.97.0, but I took the opportunity to totally overhaul the disassemblers in the console, they are not external anymore, they use the functions provided by mame to disassemble. With that you can disassemble z80 encrypted roms which is convenient, but I did it mainly because my offsets arrays was becoming way too big with the sh2 emulation, it had been done for the 68000 for 32k regions, here it was really far over the limit ! But those who don't use the console shouldn't notice anything. Except that added the "psikyo SH2" driver to the drivers list in the game selection dialog options to be able to select these games more easily. That's all, the overhaul of the disassemblers is a very big change in git, it gets rid of most of the directories settings too. http://raine.1emulation.com/download/latest.html For the gory details : dz80 was one of the external disassemblers, the one used by the z80, it was with raine since the old allegro dos version actually ! Very good disassembler, but it can't cope with encrypted roms... ! Also there was no support for the 6502 disassembler in the console, although it supported an external disassembler ! The list command changes because of that although its functionality remains the same, now the pc line is not in the middle of the listing but at the top. That's all for now, it was a very furious coding session !

Previously the sh2 emulation worked only in 32 bits, the asm version, using the gens sh2 emulation, so all the psikyosh games were usable only in 32 bits. I'll add some driver selection for Psikyo SH2 in the game selection dialog to be able to list them more easily next time. This includes : - Gunbarich - Gunbird 2 - Sol Divide - Strikers 1945 II and III - Tetris the absolute grandmaster 2, and 2 plus. These games are the biggest and the most modern ones in raine, all using 24 bits colors. I just noticed that I released a little too fast and sol divide and Stikers 1945 II don't work well in this version, I'll probably release a fix later today. This was something which bothered me for long actually ! For info the ultimate motivation to finish this came from a news in slashdot about some avx512 optimization in assembler by ffmpeg : https://news.slashdot.org/story/24/11/04/2140206/ffmpeg-devs-boast-of-up-to-94x-performance-boost-after-implementing-handwritten-avx-512-assembly-code up to 94x acceleration, and for hand written assembler you don't see that everyday particularly these days, and some comments doubt it's possible since recent compilers include options to use avx, avx2 or avx512 to optimize, you can do it even with raine, the binary is slightly faster, but since it's slightly only it's not enough to justify another binary. But raine shows very well how the compilers improved in the last 20 years : the 32 bits assembler version includes crazily optimized assembler code for the video part, and nowdays the 64 bits version is almost as fast, and this version uses only C, relying entierly on the compiler to optimize ! This is really impressive. So I became really curious to see what a compiler could do with some C sh2 emulation... ! Actually it's still a lilttle slower than the assembler version and it would require some more work to be at a similar level of speed, but it's already quite good.