Tux

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.