Tux

There is a link at the bottom of the download page about how to compile there : http://raine.1emulation.com/download/install.html Libretro's goal is to make an interface for emus which don't need a lot of configuration, or almost none. In raine there are quite a lot of settings, most of this would be lost if doing that. I had heard someone had tried to make a module for retroarch from raine at a time, but I never had the opportunity to test it. What's your distribution ? Most distributions ship a package for raine, even if not always up to date. In a nutshell for linux you need almost the same packages as described for windows with mingw. I don't know the names exactly, but if it's a distribution with -dev packages like ubuntu it must be something like libsdl2-dev libsdl2-ttf-dev, libsdl2-image-dev, libcurl-dev, libmuparser-dev. By default it will be the 64 bits packages, so compile the 64 bits version, for that you need to edit the makefile and uncomment NO_ASM = 1, otherwise it will try by default to build the 32 bits version. That's about all there is to know. The 1st time you compile it is the hardest one, after that the dependencies almost never change and the compilation is quite fast even for an optimized build, if you have 16 cores, do a make -j15 at least and it should be very fast. After that you only need to update your sources with a git pull from time to time if you got this from git.

It's just that the 64 bits version is newer, replacing all the asm functions by C ones, so it's less tested. Speed wise the 2 versions are equivalent, at least on current hardware, I don't think there are bugs left in the 64 bits one but it's still possible, for the debug builds I always use the 32 bits version because the asm is always fast even in the debug builds. Mer-curious always uses the 64 bits version and he doesn't seem to report any problem so it's probably safe for everyone now.

You are the only one I know and probably the only one in the world using wine to run raine in linux ! There are unofficial builds for most distributions now, and you can get the binaries from the .tar.xz files on this site and you just need to install the dependencies so that it works, really not that hard...

Sorry for that, but it was to be expected, by the way, it's not a new fullsreen mode, it's actually the old one, the one using a video mode change. Here you don't see any video mode change because it's the same resolution. You used the "Yes (real)" setting for fullscreen then ? At least you tested for good this time ! There is a last setting I just tested again right now, we tell sdl2 explicitely to use opengl for its part because if not there are crashes happening. I just tested it again, and yes they are still happening, very easy to trigger ! So no change on this side... I can keep the setting for the unbelievers yeah, it doesn't harm anything to have it. The desktop fullscreen just hides the window decorations, I don't even know if it's borderless, it could simply hide them out of the screen, it's done behind the scene, it's handled like a normal fullscreen mode.

After some thinking, after all it's not that hard to make a binary so that you can test that by yourself, and you might be lucky and it might fix some of the issues you have on your side. So here it is. The toggle to this real fullscreen can be made only from the video options dialog, not from the keyboard shortcut ingame. Except that the main change is mainly the update for the 7z code, which gave me some trouble to compile the windows version. Anyway here it is, in 64 bits, exe only. (I tested it quickly in windows 10 here, everything seems fine). raine64.7z

Tsss... if you have read the thread until the end, it turned out it was just a window manager problem in linux combined with the video card driver, it was fixed in git, but not in any official binary yet (at least for what I could test, this guy didn't reply to say if tests on his side were ok, that's why the issue is still opened). 2ndly as I already told you, I can't reproduce your white screen here on my desktop, it happens only in windows and I had it a long time ago while setting up the 1st versions using sdl2, but I have not seen it since then here. So I believe it's more related to some video driver/video card issue, and anyway since it can be worked around easily and is impossible to reproduce for me for now, there's no point. For the notifications I had telegram but only in linux, I downloaded the windows one, and in the parameters screen for notifications you can simulate notifications on your screen, that's what I did, raine playing in the background visible, the telegram window on top and the notifications which appear when you move the mouse over their displayed screen. No blinking, no white screen, nothing. Well since you use something to also capture some video, maybe it doesn't help. Why is everybody thinking this "real fullscreen" is like a super holy solution ? The only reason previously to have this "real" fullscreen was because that was the only way to have double or triple buffered display, it's not the case anymore with sdl2 it works perfectly in a window. So this fullscreen windowed mode gives a few advantage, you can't display a window on top of something using this "real" fullscreen, here you can without any problem which makes things easier for debuging or checking something else. The windowed fullscreen is actually a better solution, especially for lcd screens, the real one tries to change the screen resolution to match the window size, you don't want to do that on a lcd screen, that's why version 0.50 was created, and it was a very long time ago now... In the end, this is something really easy to test by modifying the source and testing by yourself, too bad you don't compile, you would have seen by yourself it's not the right solution ! Sorry about your driver glitches, but I can't do much about that, as far as I know at least... !

this is really going nowhere. 2nd screen is just what is displayed when the settings of the autofire have been saved and reloaded, and it works at least on the game I tested, I never bothered to find why the display order changed by the way, and I don't plan to. You tried that on kof98 apparently, it's not exactly the ideal game to use autofire, the autofire is done for shoot'em ups usually... ! I guess you would need to at least remap the autofire button to something else so that you can continue to use the normal button without autofire and switch to autofire only when really needed. kof98 is made to use combos, not pressing the same button as fast as possible, it wouldn't make much sense here. Try that on a shoot'em up, it will be easier !

I don't understand everything here, but the 2 pictures are equivalent, it's just the the order of what is displayed which is different, but the information is the same.

Well just tested with ddonpach using the keyboard, no problem, ddonpach is good to test that because continually pressing the fire button create a concentrated shot as opposed to the effect of the autofire (rapid shots). Tested with autofire directly assigned to button1, and with autofire using its own input, both on the keyboard, no problem (tested with the linux version, I won't even test with wine for that). By the way I got a report that fullscreen in the linux version was broken for quite a few window managers in linux, I didn't know that, it seems reports come very slowly for that, it's fixed in git for next version (at least for openbox which I tested directly and probably for kwin).

The 7z code in raine is very old, 11 years already, and the distributed code changed quite a lot in all these years... Since the performance of the 7z archiver didn't change a lot in the same time, I didn't expect a big improvement for the performance, but I was curious to try to update this anyway... In the end it was long, complicated, and for almost no improvement for the performance, quite disappointing ! I'll keep the update anyway, maybe I missed something in it, and it's probably better to have some more recent code. Things to notice : by default 7z archives are solid, but for some big rom archive, making it solid gains about 1% only in size, almost nothing. The time to decompress is almost the same for solid and non solid archives, but if the archive is not solid you get a real progress bar when loading the rom. If it's solid, then the whole archive is processed for the 1st file, and then the rest goes so fast that the progress bar becomes totally useless ! So it's probably better to create non solid archives (-ms=off when using the 7z or 7zz command line in linux).

It's smaller, but probably not faster, mpg123 is very concerned about speed too, it's full of assembler code inside so I doubt it's slower ! But I reverted to the old mp3 driver anyway... ! (I kept the mpg123 code commented in case it's useful again one day !)

Bang, Iccuslus suddenly exited from hibernation and fixed sdl_sound... ! See there : https://github.com/icculus/SDL_sound/commits/main almost 1 month later, but better now than never of course... Now I hesitate : is it better to remove the new mp3 dll and return to the old decoder and just forget all that and stay with what we have ? Well luckily only 1 version used the new dll, and it was included in the raine archive, so removing it now will have no consequence. So I guess it's probably the thing to do, the mp3 decoder used in sdl_sound is still smaller and maybe faster... Oh at least I'll have to try it first. Apparently the bug was that when the decoder returned something less than the expected bytes to read (which happens for the last block), it was understood as eof (end of file), and so the last block was not handled. Oh well... He finally closed the bug thread on github with this fix. edit : yeah, the fix works !

No it's not a unibios problem, it just displays a nice screen instead of just crashing here, the error shows the pc has just gone out of bounds, it should not have this value, it's an emulation problem, which is a little surprising since fbneo is based on mame, I didn't think they touched the emulation part very much, but I don't know it (no linux version !) For tmnt, I didn't even look ! It's probably not an easy one considering konami reputation, but no idea. For now I am looking at other things for a little while, I don't spend all my time in emulation...

It's a misconfiguration at the server level, mime types configuration, with wget you get this : --2022-03-04 14:09:08-- http://raine.1emulation.com/archive/raine32-0.93.4.7z Résolution de raine.1emulation.com (raine.1emulation.com)… 216.245.218.214 Connexion à raine.1emulation.com (raine.1emulation.com)|216.245.218.214|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 2902845 (2,8M) [application/x-troff-man] (the text is in french, sorry, but the mime type appears between () at the end : application/x-troff-man, it's a man page indeed, but it's not my fault). On my side, it's a simple <a href link, produced by some basic html file, I don't touch the mime type configuration... And, from there for example : https://github.com/mime-types/ruby-mime-types/issues/32 the mime type should be application/x-7z-compressed it's minor though, even the most basic browser would kinow how to download this, whatever the mime type is.

Yeah sorry I should have fixed that the 1st time. The reason why there is the option for neocd/neogeo is that it's a single driver for roughly 100 games, so the search for these speed hacks is generic there, and sometimes it can fail to find something good. You are right it's usually not really necessary anymore nowadays but it's in the spirit of raine, optimize as much as possible, just because doing it is great ! It would have been nice to have the option for all the drivers, for those who prefer to play with a choppy animation when the game is overloaded with sprites, but it's tedious to do it now, so maybe one day, but not for now... Except for neogeo where the driver sometimes fails to find the right spot, these hacks are made to end the emulation of the main cpu when it just waits for the vbl, instead of just wasting cycles looping for a vbl which won't come because it requires an irq. It saves some cycles, but on modern hardware, it's around 1 or 2% usually (on an optimized build, more on a debug build in C), but it's the right thing to do (mame prefers to emulate these wait cycles, because it's more accurate).

neocd/neogeo options / allow speed hacks : no And you'll probably need to reload the game after that because the speed hack installs itself very fast ! They'll be disabled by default for this game in next version.

Yeah yeah the pack was made hastily, I doubt any direct3d shader would work since raine uses opengl, although maybe ? (seems unlikely though !). So yeah some shaders are broken, they were clearly not even tested, just assumed to be compatible. For the glsl shaders, yeah good idea, but I am no shader expert, I already had some trouble to add the old shaders support, so... ! But I agree, it would be a good idea ! (actually the name is bad, all shaders for opengl use what is called glsl).

make sure you disable speed hacks for this game, I thought they were disabled automatically but apparently not. I just tested the neocd version with this shader, apparently it's ok...

Yeah it's very tiny indeed, I wouldn't have thought about using the loop in play track to change the setting when returning to game... Well considering that before this version returning to game would simply stop the current track which played, it's already a huge improvement that it does not stop anymore ! Actually the loop trick you find is the "exploit" of a bug, I forgot to restore the loop status when returning to game, so here it just takes the last loop status... ! Ok well I'll restore it from the track setting next time and not from the last value it had.

... and if you had read the announcement with attention you would have noticed the advice to go to options / colors / revert to to restore the colors to their preferred theme (blue by default). Before you ask, the effect is not immediate, you need to close the dialog and open a new one to notice a change, so after choosing which colors to revert to the easiest path is to just quit and reload the emu.

This binary is only about the sound associations, particularly those related to kof2001, so if you are not interested in this, you can skip this one because it changes the colors encoding so if you load it with a previous config file you'll need to use the "revert to" command from the colors menu in options. It also includes a new dll for libmpg123, which is included in the archive for this version, it will go to the dlls package soon for the next versions. You can see the details of what happened (and eventually get the audio tracks from mer-curious !) from there : http://raine.1emulation.com/download/latest.html

And finally updated the playing function from the "manage associations" dialog to handle the loop, and if you entered the sound commands dialog with a track playing, it's restored when you leave. And a new binary is on its way... !

Well it does a lot of rom bank switches while on this screen, a few / frame, which is a little weird, I wonder what it needs to fetch while on a selection screen, but anyway the bank switches are just emulated by a pointer which changes, it's extremely fast, and you can see that with the profiler %, they remain low. I thought maybe some kind of weird input which is checked, but it's neogeo, meaning all the games use the same inputs normally (cartridges !). So for now no idea... For the fix for sdl_sound, I just reverted to the decoder used in the 1.2 version, which worked well, so it means you wouldn't have this bug in the 1.2 version. I think it's quite unlikely to see that fixed, the author seems to have mostly abandoned the project, plus the bug is not in sdl_sound itself, it's in the decoder he chose, which is too experimental. It was convenient though, very small and very fast, so can be merged without needing an external lib, libmpg123 which I use now is huge in comparison !

And finally found a workaround for your weird colors in game in windows after displaying the sound association dialog : it can't be fixed, because it's totally crazy ! Actually the color you see is the color used by the lines of the cross to indicate a loop is enabled. Here you couldn't even see the lines since their alpha was 0, but the color indexes still counted ! So the only way I could find to work around it is to make sure the last line drawn here is white, this way there is no color applied to the game bitmap and everything is fine ! I am glad it's windows specific, because it doesn't make any sense ! So you'll notice now there is 1 green line and 1 white line for the cross... temporary workaround until someone finds something better ! The fix is in windows only of course, I keep the normal cross otherwise. I think that's the end of the fixes for your problems, I had a quick look at the slowdown in the game menu, and no idea for now !

The invisible cross in the loop checkboxes was simply a bad handling of its colors, it's because the colors changed their encoding in sdl2, I tried to keep some compatibility with the old ones, but it's the last problem here, I switch to the new colors, so next time you'll run raine, you'll have to use the "revert to" option in the colors menu (from options). The sound which loops badly is specific to the mp3 format, at least for me, I don't have it in wav or ogg format. This has been reported there : https://github.com/icculus/SDL_sound/issues/27 The problem is that the author doesn't seem to react much. So for now the best solution is to use ogg or wav instead of mp3, it's not specific to the vbr contrary to what I thought 1st, it cuts the end even with a plain 128k mp3 ! It's possible the problem doesn't happen in the sdl1.2 version, they changed their sound decoders in sdl2_sound, and might have chosen wrongly the mp3 decoder here. It's fixable since it's open source, but it's not an easy task ! Just checked : it also works correctly with flac, it's really specific to mp3 for me. Ok problem fixed by taking back the old mp3 decoder we had for sdl-1.2, and which used mpg123 (it uses minimp3 here). It works, but it requires to link with libmpg123, which means 1 more dll for windows, yeah !!!