Tux

not exactly. Arcade games are made to do their work at 60 fps or close to 60 fps. If you find the exact point in the code where the 68000 waits for the next vbl interrupt, which means it has finished its work for the current frame, you can put a speed hack here to finish the emulation for this frame. Direct consequence : less cpu cycles wasted for the emulation, and you can increase the amount of cycles the 68000 can execute during this frame to avoid choppy animations for the games which have that. For neogeo, I can't remember any game having choppy animations, so the only point of a speed hack here is just to optimize the emulation, but for modern cpus it doesn't make a big difference, cpu emulation time is usually around 3% max (and more often 1 or 2%). So you can just disable them all the time here and forget about that. The reason why they fail for some games is that it would be too tedious to check all the speed hacks for the 100+ neogeo games so the detection is automatic. It works most of the time, but there are exceptions... !

Just leave it off with modern computers it's the easiest solution

Hey, it took me quite a while to find out because I had only standard game controllers and I had lost my usb adapter for my old ps2 gamepads... But with the heat coming back I suddenly thought again about this old guitar hero guitar which also has an usb adapter... that's the usb adapter I was looking for ! And these ps2 gamepads were not recognized as standard gamepads (what a surprise, my usb adapter appears as "Lakeview Research MP-8888 USB Joypad", no wonder it's not recognized ! So I mapped it using the "controller mapping" command, and button A (which is X on a ps2 gamepad actually) was not recognized in the gui ! Oh well, it's fixed finally, but it was a bug in the gui only, in game it was already perfect. I'll add some info for the "controller mapping" command because the window appeared behind my fullscreen raine window for some reason, so if you don't know there is another window here, you can be lost !

I don't like very much this appimage thing anyway, the result is huge, about 7 times the size of the normal binary if I remember correctly, it's much better to have a system updated to something more recent. For the analog inputs sadly very few games use these, mainly racing games (plus those using the equivalent of a mouse). The vast majority are digital only which is a pity in some cases. By the way you shouldn't need any borderless window, fullscreen works now...

The old "analog input" entry from the inputs menu is gone, it was broken for a very long time anyway. It's something inherited from the dos days when Warlock tried to add some very primitive handling for analog inputs for some racing games. I never took the time to test this properly and make a good sdl version since then... Now it's done. For now the new system is added to git for chasehq driver (so it's the chasehq games + night striker). The principle : a dipswitch determines if you want the analog input for the steering wheel, the accelerator and the brake. If you don't it's the usual analog inputs as always. If you do, and a joystick axis is associated to this particular input in the controls, it uses this axis value for the analog input. The left & right trigger in the recent game pads are seen also as joystick axis, so if you associate say right trigger to accelerate and left trigger to brake, you get some working analog inputs for both. I didn't check with a real steering wheel, but it should also work, the steering wheels on pc return axis values. The only drawback is that if you ask in the dipswitch some analog input and the input associated has no axis, it will just be ignored and you won't get any input at all for this one, but I guess it will become obvious in this case !

While testing other rendering modes, I discovered that the "drawpixels" mode for rendering in opengl was broken, it produced a black screen if "opengl overlay interface" was enabled, and it is enabled by default. It took me more than 1 hour to find out, a very stupid thing, but which seems to be here since 2013 !!! Ok, DrawPixels is not really interesting, I just keep it in case someone with a very broken opengl setup tries to use it because it can't use the default render to texture, but broken for almost 10 years... !!!! Anyway it was just because the overlay text interface was temporary disabling GL_TEXTURE_2D before rendering its text which is ok, but then it enabled it again, which is good for the default texture rendering, but which breaks very efficiently the drawpixels renderer ! Anyway... !

There was a fix in the code for this issue from the beginning of the sdl2 version, except that at some point it became useless and actually recreated the problem, the opposite of what it was supposed to do, probably because it was fixed at the sdl2 level. I didn't notice because I almost never use the windows version, so yes the thing which made me notice was your tests, so it's a good thing. Finally the cross compilation and mingw now target the same version of windows : xp sp2, so this link for win10 will go away, and the dlls package will be updated for next version. Until then, keep this one, next one will be smaller, fewer dlls, but this one works well already. Glad it's finally fixed for good !

argh, no luck then ! For the windows 10 only question : probably not, the version required is in a header file but I forgot which one... ! I don't fiddle with windows stuff very often... I'd say win7 would probably work but I am not sure, what is sure is xp wouldn't work with this one. EDIT : I found the stuff, it's WINVER, defined in many places in the mingw headers, it indicate the minimum version required, and it's actually not that high, it just requires xp sp2, which seems very reasonable (it's defined as 0x502, and you can see the versions there : https://docs.microsoft.com/fr-fr/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN ) Except that, well 100% reliable here, so this time try it if you can on your nvidia computer, and hopefully this should work ! For the way the windows is drawn : it's sdl2 stuff. I know it's related to the opengl context which is sometimes lost when switching from fs to windowed mode, it's supposed to be fixed now, but apparently there are still problems sometimes. Well if I had a windows expert contributing code for the windows version maybe he could find some way around this, but since I don't, and since I don't want to try that, well it won't happen ! The best workaround is simply not to use the keyboard shortcut but always switch by using the gui, I never saw this problem by switching from the gui. EDIT : I took another look, and it appears the workaround I had used for this very same problem is not required any more if using this version, so I'll update the binary and let you test it... Ok, binary updated in the archive, new date in the archive for raine.exe : 022-05-06 19:09:48

... which means that something is different in your windows ? 3d desktop effects ? Normally they can't be enabled/disabled in win10, so it's quite surprising, but yeah aero effect was known to create problems previously. For now I don't have any better idea... In the 1st post you said maybe it would be a good idea to try to enable this mod... which mode ? direct3d ? Well the shaders in raine are opengl only. Direct3d is not bad, but it's not multiplatform at all, and raine is. Maybe try to describe your 100% method to reproduce your white screen, but if it's just switch from fullscreen to windowed while ingame using the keyboard shortcut it's no use... Oops something changed, I can now reproduce it reliably, just start from fullscreen, switch to windowed mode while ingame... I guess I'll have another look at that then... ! ... and I seem to have a workaround : a version incompatible with windows xp ! By default when building using mingw32/mingw64 it builds an incompatible binary if you remember, I had to use some kind of trick to get a compatible binary. Well when I use a binary straight from mingw, the problem is impossible to reproduce apparently... ! what a mess... ! Resulting binary is 8Mb of size, too big for the forum, I'll have to create a new entry in the download page... Ok, new binary in the download page (latest) windows10 binary... it includes all the dlls, and no dirs and no data files, you are supposed to replace the exe and its dlls in the normal version (well you can leave the dlls if you want, it will eat disk space for nothing if they are not overwritten by this they will just be unused). Good luck then ! By the way it's not exactly 0.93.4, it includes the new "real" fullscreen, and the return of the driver info button in the about dialog, for some reason it never made it in the sdl version until now... ! Ah yes and the new 7z code. Only small changes, so no version number change so far. As I already said, most of these dlls are useless, but it's the price to pay to be able to use precompiled binary packages, they include all the options, even those we don't want... !

... and finally updated the x86_64 appimage to use a very old glibc 2.29 which I got from an ubuntu bionic image, inside a docker image ! The new appimage is named Raine-x86_64.AppImage That was some crazy stuff to do, but there were almost no bad surprises in the end, except helping the image tool to use the correct libs in the end, but it went quite smoothly, it was just long to do. For info since bionic is the oldest ubuntu in existence, it uses some very outdated packages by default, so I compiled manually sdl2, sdl2-image, and sdl2-ttf, the rest comes from the apt bionic repository. It also uses gcc 7 (we use gcc 11 now !), so well it might be a little slower than the latest normal binary then... ! I also had to select manually which libs to install for sdl2, I tried to take as much as possible, it seems quite complete. I tested it using an old pc which has glibc-2.33, it works well, including opengl and the sound (and joysticks mappings are read correctly). So I assume it will work on any pc having at least glibc-2.29... ! Oh well, at least I learnt a few tricks by doing this... ! (I don't plan to do the same for the 32 bits image, you said you used the 64 image, so I'll stop here !).

... and the 2 appimage were just updated, I took my old laptop which has lost its cmos battery to test that, and I missed a few details yesterday, so these 2 were probably unusable except here. Updated, for now they still require a 2.34 glibc, but they should work everywhere if you have that. I might try to create a virtual machine to build with an old glibc, but it would be long and painful, so no promise here. These distributions are really annoying, even when using debian I was using testing to be sure to be updated regularly... ! Anyway without any feedback on this I will just delete the 2 appimage files after a while and forget everything about this ! (but the appimage format is very good to package easily some application anyway).

Ok, since there is probably no way to explain this to you clearly, I have finally built 2 appimage with latest version inside, they are available at the bottom of the download page. These appimage contain the binaries with all their dependencies so they should work anywhere. Just download the one you want, make it executable (chmod +x from a terminal, or use any file manager to change the file permission graphically), and then run it, it should work. I am not sure I'll build this regularly, depends on the feedback I get... Well actually there is still a chance it won't work for you because one of the tool says my glibc is too recent, so if you have an old glibc, it's possible you'll get an error while trying to run this, the glibc is not included inside. Well I won't be able to do much about that, there is an old linux computer which has an old glibc also but it's not intended to package anything... Oh well, you'll tell me what you'll get, but I bet your glibc will be too old... ! (run it from a terminal if it doesn't work to see what the error message is !). After some more digging, and some tests with the old pc here : it seems to require at least libc6-2.34, I have 2.35 in arch here, and your 20.04 ubuntu has 2.31, see there : https://packages.ubuntu.com/search?keywords=libc6 Sorry, you'll need to update, that's the problem with these distributions frozen in time, they get outdated and when it happens it becomes harder and harder to install anything which is not from their official package. You either need to compile it yourself here, or to update your distribution.

Oh là la, all this is an insane mix of different things, the whole thing in a very bad english, this is going to be almost impossible to explain clearly in these conditions. Anyway, I'll try at least this time : - Sorry I didn't know ubuntu didn't have any raine package, there might be one in the zillions of unofficial apt repositories out there, but no info about that. Oh well... - you edited the makefile, great, if the line is already uncommented, even greater, then you didn't even try to type make to see how it goes ?!!!!!! Go figure... If you didn't try that and didn't tell why it didn't work in the 1st place, maybe it's a good idea to stop this discussion here... - you talk about moving the binary to another directory, try to launch it and just "it doesn't work". Sorry when you try to launch a binary, you do it from a terminal to see if there is any output, and in this case you try first to understand the output, if you post it here eventually put it between spoiler marks because it's probably be quite long. EDIT : on 2nd thought, no it should be only 1 line, the name of the shared library it didn't find. In fact you don't even need to run it to get this info, just open a terminal in the directory where the executable raine is and type ldd raine, it will give you a list of the shared libraries it need, and you will see "not found" on the right for those it can't find. So go to a website which allows you to find a package name from the name of a file inside it, and search for the shared libraries it can't find, if the site returns a package name, install this package. If one of the libraries can't be found (which is possible since arch linux evolves quite fast), you are out of luck and you can't run it. - I used retroarch once quite a long time ago when I tried a n64 emu, to finally give up and use the emu directly, it was better. The shaders in raine are from an old retroarch version, I don't even know which one, so there is some interesting stuff to get there sometimes. But don't ask me to make a retroarch module, I am just not interested. - and yes PKGBUILD is specific to arch linux, these files are not intended to be used in any other distribution, although they are easy to understand, it's just some basic ascii source describing what to do to build the package. I just said to use the tar.xz file, extract the binary from it, and try to run it FROM A TERMINAL OF COURSE so that you can see what's going on... !!! There will probably be some dependencies to install manually, but nothing too fancy, as I already said... Oh well... !!!

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 !