Tux

Officially xp is still supported by sdl2. The joystick assignment is based on a unique "guid" assigned to the joysticks by the operating system, here is the little doc provided for the function : https://wiki.libsdl.org/SDL_JoystickGetDeviceGUID Normally the id should be unique even if plugged through a usb hub, but it's new, I am no specialist of the thing. I can add something to see the guid in next version What do you call "joypad 2" by the way, it's not the name displayed is it ? There is a joystick index function in inputs to change indexes, but normally you shouldn't get twice the same index there, go check it at least... But this function doesn't display the indexes themselves since they are unique normally. You can open the raine32_sdl.cfg file in the config dir with a text editor. In the section "emulator_joy_config" you will see how the joysticks are seen, these are long settings towards the end of the section looking like that : 030000004c0500006802000011817200 = 0 03000000242f0000b700000000017200 = 1 The 1st number is the guid of the joystick, the 2nd number is the assigned index, starting at 0. You should have 2 guids here since you have 2 joypads, and 2 different indexes.

Thanks ! Yeah this pkgbuild system is very reliable ! That's what they use in mingw32 and mingw64 too (the pacman tool to handle all the windows packages).

There was really no need for a video here. I am sure I tested this once and it worked, but I moved the test and it got corrupted where I moved it, and since I never use this mouse wheel, I never noticed ! Sorry, my bad. It's an easy fix at least (2 lines). If you want some more technical detail : it's because sdl2 uses a strange struct for its event where all the parts are not defined at the same time but only when a specific event occured. Here the data of the mouse wheel was overwritten by the data of a mouse's button test... ! It's a test that didn't test the mousewheel event because previously there was no need, the mouse wheel was a mouse button event... ! Anyway it's fixed. Nope, not here. But from your screenshot, it's because of the insanely long path name you have, and the default small size of the window. Now maybe I should choose fullscreen as the default setting since the fullscreen is now reliable even in windows... Here it's the old default safe setting : a 640x480 window to be sure everyone can display it... Now maybe the size of this path isn't taken enough to choose the font's size, but I am not sure anyway it could display all this length in a 640x480 window. Try a fullscreen and talk again... Already told, already replied, for now it's almost never used, I defy you to tell me in which game it's used for now, since you can't answer don't bother and leave this option alone. I have some plan for it, but it will take time. I am sorry I don't see it neither. Already discussed, you didn't reply what I posted last time... ! Tss, it's just that the minimum allowed font size is now 10 points. It doesn't change anything for people who keep their config from one version to another, which should be your case normally. Same comment as up there : Raine can't do any magic, it can't display things properly if it doesn't have enough room for that. Go to fullscreen it will make things easier. This title is way too long anyway, but I chose to keep the original here, if you want I can put "kof98" instead, this way you won't complain ! Yeah it's generic, it's the inputs for "2 players 6 buttons" configuration which was changed (for cps2). I didn't try to test all the games, but you found something very specific here, it's rare to see a behavior like that on an unmapped input. edit : on 2nd thought I added some code to cope with these too long titles for the display area, I hate dealing with this stuff, but it will make things easier later so it's a bad for a future good... ! You'll be able to test that again in 640x480 and it should work. No magic here, it cuts the strings in this case.

I'd say the video driver is the main cause here, but you might want to visit this page to update your xp as much as possible, it won't hurt : https://retrosystemsrevival.blogspot.com/2019/12/unofficial-cumulative-windows-xp-update.html

Yeah and I am always happy to keep as much compatibility as possible, but it's an extreme case here since I can't even test it... I can test the dos version, it works fine in doxbox and even better in dosemu, but no 3d in xp anymore for me ! And mer-curious for info, you don't even need a specific distribution for old hardware in linux, the kernel by default supports almost anything. They removed some old code about the 386 lately because nobody could maintain it anymore and it was making things unnecessary complex, so you might have problems if you try to make it run on anything less powerful than a pentium (but I think a pentium is the absolute minimum for linux on my side, unless you are doing something very specific, like a text mode only terminal). After that you just need to be reasonable and not try to install the latest 3d desktop with all the fancy effects, and choose something small and fast instead, but you are free to try anything !

So you say you are the 1st one to be able to run this correctly in xp ? Congratulations then ! (on my side there's nothing I can do, I can't even reinstall virtualbox-6.0.x, it's incompatible with current kernels in linux, I could try to install it in windows, but I am not that motivated, it would require to move also the xp image, too much trouble). Good news anyway !

It's mainly something to fix the little problems of 0.92... The dlls change again to address the incompatibility with xp of the previous set in 32 bits (there seems to be other problems with xp related to the 3d, but at least it's not a stupid message from microsoft to tell you are not allowed to run this in xp anymore !), and it's changed too for the 64 bits version because it allows me to make both versions the same way, + it's almost half the size of the previous archive. The only dlls packages listed in the download page are the ones required for the latest version, so just update and it should be ok. Except that, mostly fixes for 0.92 as I said. The key codes change again, we switch to all scancodes to be able to have default keys which don't change with each international mapping, but you have nothing to do here, it will overwrite all the keyboard configuration if it reads an config file from the previous versions. The joysticks use some saner defaults too but for them I didn't overwrite the config sections in case you have something fixed on your side which is different from the default. The famous bug found by mer-curious which prevented special moves from the right side in msh is fixed, and there was again a problem with merged inputs which should be fixed for good this time. Also you have the option of integer scaling in opengl. I tested it, and I am not convinced, there's no real improvement in the scaled image for me, but I left the option, you can test it and report in the forum. (The option is in "renderer options" for opengl). Also sdl is updated to 2.0.18, actually they mostly add new functions, it's very different from sdl-1.2 which was frozen in time, for now I don't use them, but updated anyway... http://raine.1emulation.com/download/latest.html

Nope, you misunderstood, now that this 64 version is made using pure C everywhere, nothing forbids to use this code in 32 bits, gaining an absolute portability. I don't do it for the pcs, because I like my asm, it was a lot of hard work after all, even if it creates problems sometimes (use of VirtualProtect in windows to allow self modifying code to work without crashing !), but it's easy to do.... !

Yes, said on the topic for raine 0.92, it's now possible. But you are wrong, the 32 bits version is still full of asm everywhere, video functions, cpu cores, plus small pieces of asm everywhere, but the 64 bits version had to do without this, so it's not the sdl2 version which made it portable, it's the 64 bits version. But sdl2 is more widely ported, and it's probably easier to make an android version with it. If someone wants to try that, he's welcome to, I'll eventually try that one day but I am not in a hurry for that (I don't think an android device is the ideal console for arcade games, lacks real controls, you would need at least some kind of real joystick, the virtual ones would probably lack too much precision for most games).

Easy : it's an UNINITIALIZED input, the previous game just initialized it... ! No no, I won't include different default inputs based on how many buttons are used. The current idea can be used for any game with up to 6 buttons, seems good enough. If someone wants something different, customize default inputs or switch to custom inputs is enough...

And finally found after a long search ! It was one of these bits from the input ports which looked like they were unused, so usually I don't even bother to tell they are unused since we have all the controls mapped in the test mode. Well there was no input directly linked to this one, but if it became active, it prevented this special move from the right side!!! I don't know exactly which bit did that by the way, because I cleaned up quite a few of them, but it can be found for someone interested... maybe there was a reason for that, something which was connected to test special moves ? The big surprise is that it happened for you in windows and for me in linux, everyone could do it. It was just an uninitialized input, and its bit turned active which should have had no effect normally, but it had this very weird effect. It's a good lesson for me, next time something so weird happens, I'll start by double checking the input ports... ! While looking into this I had a closer look at how the rasters work in cps2, and they are probably easier to emulate than the neogeo ones finally... just an impression, but anyway I am not sure I want to dive into this now. Anyway good thing to finally have fixed this !

You can try if you want, it still accepts the same old command line. I suggest to install mingw32 not to become crazy with the command line in windows, but it's manageable even with cmd. You don't even have to put a rom in the roms directory, it will try to download it if it can't find it, but without any working gui, it's going to be very hard to use it ! Something like "raine32 bublbobl" should give some result... if you are lucky ! I can't test at all this xp version here, or I'll have to install an old version of virtualbox for that, with the current version all I get is a completely white window which closes after a few seconds (no 3d support at all for xp currently, it was removed from virtualbox). Yeah the only output with sdl2 is 3d, either opengl or direct3d, and for now it's opengl for everyone. Yeah I know it can be surprising for a 2d emulator, but since these days everything is 3d and these cards have a tremendous power, it's possible to use them even for 2d, and use them well ! Also for info there is very good support in linux for the old hardware, contrary to what there is in windows. It takes a while to get used to it, but it will work much better than what you have here in the end !

As I said it was worth a try, but it's probably too old the 3d tricks inside, there is not much to do here, sorry !

no cps1 & cps2 share the same driver there are very little differences between the 2 actually... Ok, I could reproduce the problem even if I can't do it 100% of the time on the left, I am also at 0% on the right, which is very puzzling ! No idea for now... What I did to test that : a 2 player game with shuma gorath against himself, so I switch the gamepad to test 1 or another, and I have the cheat "infinite timer" if I need more time... And very strangely at a time every tlme I loaded my savegame the left shuma did this famous move as soon as it was loaded when I am sure I did the savegame with nobody moving ! I overwrote the save in frustration, but maybe I should have kept it to understand what happens here... (actually it was not in frustration, it was because for some reason the change in commands had made that one of the joystick buttons was also a button to create a new savegame... ! Normally there is no joystick button mapped there, so no idea how it happened to be here, but my save was destroyed anyway!) something very strange for sure, but it's not easy to track these special moves ! It's not the speed hack neither...

Alright finally taking a serious look at your sonic boom mer-curious... Just for info there is no "sonic boom" in the moves in the command.dat, bad start... ! And even on the right side I have some trouble to do it, it worked well previously, then I reloaded and can't redo it ! Oh well, I can already tell it's no buffer overflow, investigating the speed hack but I'll have to stop for now, more later... For the keyboard sorry, the whole key sections will be reset again in the next version : I switch all key codes to scancodes, that's because your idea of using qsd as default buttons changes with international mappings. To avoid that we need the scancodes. Which changes all the key codes again !

For the keyboard, sorry this version has a bug which makes remapping keys almost impossible, that's what happens with work-in-progress version, specially now. Default mappings might work though.

Yeah good idea. The latest binary shows in the about dialog "compiled on nov 29 2021, 23:01:59", and in "renderer options" you can enable/disable the integer scaling for opengl, it's disabled for default. And I just checked that the picture is scaled to the maximum possible ratio if it's disabled. If it's the latest binary, with opengl rendering and this integer scaling disabled and your picture is still cropped, I suggest you throw the computer to a deep trash somewhere !

For the picture it's normal, it's the integer scaling in action, redownload the latest binary as I said, the one from 23:44, and it should fix that. For the menus there is probably a bug lurking somewhere, related to the length of your path here, I'll check that later. For the controls I am not sure there's something to do... Testing this version on other os, I tried it quickly in my win10, but didn't try any joystick, but there's probably no problem here... It was an interesting experience to try to make this work on xp anyway ! And it's good to have some smaller dlls again anyway !

You have better luck than me on my vm, Oracle removed the 3d support for xp, so my xp image is suddenly a lot less interesting... ! No idea for the controls... ! It might be something else lacking in xp, or not that stable, not sure for that. For now the controls are totally broken if recompiling for sdl-1.2, I tried that earlier, there might be a way to improve this, but it would be crazy to make an xp specific binary... I re-uploaded a binary at 23:44 because I had left the testing of integer scaling enabled in the previous one, which made the picture a little special... Retest this binary on the one with the font problem, if it doesn't work at least you saw it working in xp !

Ok, I built a new binary without this stupid dependence The others can test this if they want too, it's an updated binary with a few fixes, and the dlls are smaller since they are no longer the precompiled ones from mingw32. dlls : http://raine.1emulation.com/archive/dlls32-0.92x.7z binary : http://raine.1emulation.com/archive/raine32-0.92x.7z What was running the computer with your font problem by the way ? You might want to test that on it too...

Good info indeed, that's some incompatibility added by microsoft for no good reason except another way to push people to update... I would say win7 was quite good, there's no good reason not to update xp to win7, except if it's a very old machine with nothing inside. In this case, it's probably a bad idea to use this sdl2 version, remember it relies heavily on some good 3d acceleration, not sure you would get that in your xp... Anyway I'll take a look to see if I can remove this stupid dependency (that's not from raine, it's from one of the dlls, the function is probably not even used anywhere). The dll in question in libwinpthread-1.dll, a kind of system dll, hard to do without it... ! The irony is that for this version I decided to use mingw system to build the windows exes instead of my usual cross compilation, thinking it would increase compatibility... apparently it's the opposite ! Well in this case I'll try to cross compile sdl2 to test, but no promise it will work...

I don't see why, but I should be able to test that in a virtual machine... I think opengl works in xp virtual machines... I won't test that now though...

In options ! Very hard to find ! "Min font size" and colors, then bg color. The game selection dialog has always had a transparent bg ! You sure it's not some kind of shader ? There is nothing relating to filtering in the cps2 driver anyway, sure about that, the drivers are totally separated from the core in raine, that's why I could change the lib it relies on twice already... The only filtering options are in video options / renderer options filtering is the last option of the dialog, linear creates this smoothing a little fuzzy effect, and nearest makes the pixels more visible. By the way I tested this "anisotropic" filtering, a failure, it doesn't seem to change anything for the 2d rendering I am using. What would be interesting to try eventually is an integer scaling multiplier. Previously it was used only in the normal blits, but since there are no more normal blits, it could be interesting to try to render the same way. I'll try to add something like that, at least to see how it turns out... So what you say is that your filtering is on nearest usually, and it changes to linear when you load a cps2 game ?!!! It would mean a rather massive buffer overflow somewhere, unlikely at this point, but... I am quite frustrated for now, I can't use the lib I usually use to detect these buffer overflows, totally incompatible with opengl, I'll have to make some tests with eventually the old version with sdl-1.2... You are crazy ! Or there is some kind of buffer overflow somewhere... but don't hope too much about that, it's rather unlikely, but I'll try to check anyway... Yeah the standard mapping asd which is used by almost any game to move in 3d these days, and 3 keys below that for the other 3 buttons. Not a bad idea, it's better than the vbn which was in the middle of the keyboard, and you can use the 3 buttons config as well as the 6 one. Ok, will give it a try... ! As for the keyboard, I didn't map buttons 4, 5, 6, I decided if someone needed them he would customize them ! But ok, I'll try to make something saner, but 6 buttons configurations are not ideal with these pads, I guess you are forced to use the left and right "shoulder" buttons for the 2 last buttons then... Yeah I know this one, but I couldn't reproduce it enough to fix it for good, it's on my wanted list... !

Well nothing interesting in your logs, but it's not the usual kind of problem neither. It's probably something very stupid. I can confirm that on my side if I rename the font to something else it prints it can't find it in stdout and uses the raster font instead, it's not the case for you apparently. And you have the same problem in 32 & 64 bits ! No idea, I would need someone who knows how to use a debugger for that, or at least a way to reproduce this without renaming the font to something else, without that I can't do miracles, I'd say just forget it, you just won't be able to use it that's all ! Yeah I just tested the 64 bits version in a blank new directory by downloading dlls64-0.92, then raine64, extracting all this in the same directory -> no problem. I can't do anything more here.

I remember seeing something like that while testing stuff with fonts and the normal truetype font could not be loaded. Normally it should be able to use a raster font when it happens, but it was broken, and I didn't try to fix it since everybody is supposed to have this tt font... But with a "blank" installation, it shouldn't happen. Try to run from a command line, redirecting output to a file : raine > log and look into the log to see if there is something interesting... Anything special, it's some usual windows ? EDIT : yeah I confirm I can reproduce the 2nd picture by renaming the Vera.ttf file to Vera.ttf0, but no idea where the 1st on 2 columns comes from... !