Tux

Yeah I feared that, the bug with mouse sensitivity forced me to change a function in the core of the gui, which is very dangerous, and I was almost sure there would be a problem... Maybe I should have taken more time to check things. Well I got a cold + some covid from a friend lately, so it's a little hard currently, I'll go and check for this covid a little later. So at least I know where the problem comes from, even if it's not obvious to fix, I'll look into it later. Meanwhile, use the keyboard for the game selection !

and for adaptive vsync, it's used if supported by your hardware, just run a game, then go to video infos. If it's supported you'll have the last line which reads : Opengl vsync : Adaptive But it's not a big deal anyway, it's just about enabling vsync when the fps becomes too high and disabling it when it's too low, normally it's never too low in raine. We don't like to wait for anything in raine, so we use double buffer here, and it's possible to disable it in the menus, it allows to display a frame while we work on another one, and the swapping of frames is done automatically when a vsync arrives. It works well if you don't have a crappy monitor like mine which doesn't support 60 fps, but it's not far, it's 59.88, that's why I added an option to be able to lower the fps used by the drivers.

Oops, my bad, this page is static but generated by a script, usually it selects the latest version by itself, but here it was lost because of these letters at the end... ! It's fixed and the page is updated, sorry !

No, it's just a static page so it isn't updated if you viewed the old version with your browser. You need to use refresh, or F5, or quit your browser and relaunch it.

Ok finally found mer-curious inversion problem, the 64 bits version doesn't have the same indexes for this dialog, so I check directly the labels now to work around that... ! And finally fixed the inputs dialog problem when using the mouse (index error). That makes a 0.93.5b package : http://raine.1emulation.com/download/latest.html I hope there won't be any 0.93.5c !

Hum no, can't reproduce your inversion, no idea how you do that. For vsync, it's just double buffer, the double buffer does that by default, and it even works in windowed mode. By default it's enabled, and why would you want to disable it for some games ?

I hadn't noticed. I don't know what happens here, but it's minor, I'll see it later. Not for me : raine bublbobl -> history is history, driver info is driver info, where/how do you get that ?

New binary uploaded : 0.93.5a, still shows 0.93.5 in the about dialog, it just fixes the disappeared "joysticks indexes" in the controls dialog : http://raine.1emulation.com/download/latest.html and linux binaries uploaded too.

Let it rest in peace. That's the difference with some open source os where you can have some support as long as some people are interested, here it's commercial, and microsoft has decided that xp must disappear, so if you stick with it, you'd better avoid any new program then, too bad I know, but we can't do anything about that, as I already said I can't test any xp binary because I don't have 3d support in the virtual machines. But as I already said normally it should still be compatible with xp service pack 2, if that's what you have and it doesn't work then I can't do anything about it, sorry !

Yeah this dog marked the memories, but anyway... ! Too bad for "Joystick indexes", it was a bug because I removed the entry for the menu for "digital inputs", I checked the other indexes, but missed the fancy updating of mouse sensitivity, so now you have mouse sensitivity which overwrites the "joystick indexes" entry, that's why it appears twice in the menu, never made this kind of bug before, it's a 1st time... !!! Oh well, I'll post a new binary a little later today. Meanwhile you can click on the 2nd entry where you see "Mouse sensitivity: some percent value", it should run the joystick indexes command ! Sorry for that !

NeoRaine has been merged into raine in 2013 ! you are 9 years old, yeah ! Anyway download the latest raine, I just uploaded a new 0.93.5 by the way, download also the corresponding dlls (32 or 64 bits), then you just need to launch the game, and once it's started you should see the cheats either by returning to the menu and choosing "Action replay cheats", or by pressing Alt-C by default while inside the game. by the way there was some partially translated samurai spirits rpg, enough to be playable in english. I thought it was uploaded somewhere here, but I can't find it, it's an old file already, 2014, it replaces the default files in the iso, if you don't have it tell me and I'll put that somewhere...

Nothing fancy here, just some fixes and little improvements here and there. Actually 0.93.4 was using libmpg123 for mp3 decoding, and this version reverts to the decoder included in sdl2_sound, which makes quite a mess in the dlls. So the dlls are updated for this version, be sure to update from the right dlls package (32 or 64 bits). The unofficial binaries I released in the forum had at least a bug to load any neocd game, that's why I finally release this binary with everything fixed and tidy. You can see the changes in git, nothing exciting here as I said, I started to remove the old analog input section from inputs which has been broken for ages, but so far the new way to handle this works only for chasehq & contcirc. I had planned to add a new driver with something more consequent for these new inputs, but I missed time and motivation for that sorry, I lost a dog who shared my life for 15 years at the end of march, then some family problem, then the heat in the beginning of june... ! Anyway raine is not dead at least, and you get this new binary. I tested it in linux only but everything should be fine. http://raine.1emulation.com/download/latest.html

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... !!!