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.

And what took me so long ? Finding something to use for the sh2 emulation in 64 bits, and it was not easy ! Finally I took the sh2 emulation from an old mame version (153), and modified it to be compatible with what gens did, so that it's compatible with the psikyosh driver. The result is slightly slower than the asm version, but not by a lot, so it will do for now. I lost a lot of time with yabause which I looked at before that. Except that the windows status bugs seem fixed for good for those who missed the latest update of this painful story in the forum, there was a binary specific for that. And you can update your dlls for 0.96 if you want a more recent sdl2 version, but it's not mandatory, it should work fine with the old dlls. Have fun : http://raine.1emulation.com/download/latest.html Oh yeah, I also added some links to some strategy guides in the about dialog for galaxian, pacman & clones, and dodonpachi. It's nothing fancy, it will just open your current browser with the corresponding page in the web, some kind of integrated bookmarks to raine, but I thought these guides deserved some more visibility !

Same kind of hdmi setup but without windows. Anyway... ! edit : I actually just noticed why the mini didn't have a 2nd soundcard, because it's an integrated intel soundcard which needs a dedicated firmware ! Since I don't use it because I need a digitial out connector and it has none I don't really care, but I installed the firmware anyway. But no luck for you, it's a very specialized pc, no desktop environment at all and no windows, so it still selected the usb soundcard as it did before, oh well, you'll see on your side but if it doesn't work like you want I won't be able to do anything about it anyway ! (sdl2 choice, not mine).

If you want... You know normal people don't keep on deleting their config files all the time, usually sound setup is done in a few seconds only once and never after that, so it doesn't really matter which device is selected by default usually... But it's your day of luck, sdl2 thought about people like you and it knows about selecting a default device instead of just the 1st one, so that's what I'll do now. I can't test it now because I don't have any pc with 2 soundcards, maybe the mini but it has no raine for now because of a very small disk... I might test this later then. (but I don't guarantee sdl2 default will be the one in your desktop, but maybe !). edit after trying : no luck, the mini has only 1 soundcard detected, I got an old pc with 2 but this one hasn't been powered on for 3 years now and everything is too outdated on it to test something like that ! Oh well, you'll test that next time... ! Anyway I have no pc with 2 soundcards and windows installed on it !

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.

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

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.

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.

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.

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.

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.