Tux

For your filtering issue, not sure it's fixed, all I found is the filtering option for sdl2 itself (that's what is used in sdl2 native mode and also when displaying the animation behind the gui), so I fixed that to follow the open gl setting in rendering option (linear or nearest). But for opengl rendering itself, the filtering option is enforced for every frame, so I don't see how it could create problems here, if you still have some problems you'll have to give more details with a precise way to reproduce that and I'll try that in windows... Anyway 0.92.2 released, thread change !

It's still mainly about fixing the sdl2 issues, the only emulation change is the addition of some rasters emulation for cps2, finally, but I didn't test that a lot (actually only on the lava level in attract mode for msh !), so don't expect miracles. It's easier to emulate than the neogeo rasters though, so it's fast. Except that : - mouse wheel fixed again - the gui handles some strings too long to be displayed properly (they are cut now, but the default is still a small 640x480 window for raine, so just change that to fullscreen or anything bigger before complaining !) - fix broken screenshots in opengl - some experimental game controllers mappings for mer-curious, we'll see how it goes... - the option to use the dpad for movement only or to be able to remap it when the dpad is recognized (game controllers) - and some little details (more default inputs for the joysticks, the hats are handled again natively for unknown game controllers...). http://raine.1emulation.com/download/latest.html

On your screenshots sure, but you have to look carefully, I probably missed it in the emu, I'll have a closer look tomorrow... (1:40am here). It was for xp originally, even if I heard a 64 bits xp exists, it's quite rare... ! It's not some incompatibility, it's just you have 2 gamepads which are not recognized, the ones you sent the mappings... They can still be accessed as normal joysticks, but in this case we don't know how the inputs work... Stick 0 is the default input, movement assigned to 1st stick, but yeah it doesn't know what stick 0 is for (it must exist though !), well if you use the mappings you sent, default inputs for movement will be assigned to the left stick you chose in your mapping. Yeah because of the removal of the code for the hats ingame, I was too confident about this part, I took it back for now. I'll look into your blurring effect tomorrow, it shouldn't be too long, thanks for the infos !

Thanks for the reply, I was in lack of feedback... ! Well sorry but I don't see that here, in windows or in linux. Screenshots maybe, e.g screenshot of a game when loaded 1st and the same game when loaded 2nd to see this effect in action ? By the way sorry, I just noticed the function to take screenshots from raine in opengl is broken, that's probably the one you'd need here since by default it saves at the size of your screen, just take a screenshot of your window then... Yeah that's the game part that I removed thanks. Yeah there are 2 separate functions to handle events ingame and in the gui, which is a problem but it's unavoidable. Nope ! Tsss it was in the dlls for raine 32 bits of course... ! You messed up the SDL2.dll version, it used an old version here, just unpack the archive in the raine32 0.92.1 and it should get all it needs correctly, but anyway now that you have what looks like a working mapping you don't really need that anymore. I probably forgot a font, luckily it can work without it ! And I have another question then, already : I actually didn't know when using sdl-1.2 that some gamepads handled the dpad as a hat when some others handled it as buttons, yours are both handling it as a hat apparently. So the question is : in raine < 0.92, it tried to remap the events coming from a hat to joystick events, so how did it work ? You could use it for movement, or not at all ? Or could you remap it to something else, buttons actions ? This code is not supposed to be used anymore if your controller is correctly recognized as a gamecontroller, which will be the case if we add these mappings you just made, so it's interesting to know how it worked before that... Ok, your mappings seem to work, but bad news, they are platform specific, which means 1 mappings file for each platform ! I still don't know if I should merge this mapping thing into raine or simply allow to remap it manually as before... Well in my case I have 2 gamepads which are already recognized as game controllers, so no problem here, I don't need these mappings, so I'll need some fedback for that. The old code for sdl-1.2 remapped automatically the hat to a joystick axe which didn't exist... ! So it appeared as a joystick movement, but it worked in the end... I'll keep this for now I think... We're not in a hurry so I'll wait at least a day to see if I get some news from your blurry effect, but I am starting to have a few interesting changes for a new release, even if this time there are not many changes... I'll release the next one for windows with your mappings as an external file "mappings" in the archive, you'll be able to test with and without it to see the difference...

the new part here is mainly the guid as I probably told already, it seems your xp returns only 1 guid for the 2 controllers here, maybe I should have included that basic testjoystick in the archive, but normally you should get some output on stdout even with no recognized game pad connected, here is what I get when I connect my microsoft sidewinder pro, which is obviously not a gamepad (gamecontroller as they call it) : INFO: Joystick 0: Microsoft SideWinder Precision Pro (USB) (guid 030000005e0400000800000000010000, VID 0x045e, PID 0x0008, player index = -1) INFO: Rumble supported INFO: PS3 Controller 1: PS3 Controller (guid 030000004c0500006802000011810000, VID 0x054c, PID 0x0268, player index = 0) INFO: Rumble supported INFO: XBox One Controller 2: Generic X-Box pad (guid 03000000242f0000b700000000010000, VID 0x2f24, PID 0x00b7, player index = 1) INFO: There are 2 game controller(s) attached (3 joystick(s)) INFO: Game controller device 1 added. INFO: Game controller device 2 added. As you see I get the name + guid for each controller connected. So it's possible xp doesn't return any usable guid, making the whole system unusable here... I'll think about that, but now that I have some indexes allowing to choose which joystick to use as 1st joystick, I find that convenient, and I don't feel like going back... I'll try to test this part on my xp, even without any display, I should be able to get something out of it... After testing, it's a horrible environment to test that kind of thing, cmd eats all output, it's impossible to get any stdout output from any command, I guess you need to install mingw32 console at that point, but I won't go that far for an xp virtual machine. As far as I can tell (I had trouble enabling the usb game controllers on the virtual machine, then it asked to install a stupid driver for them and failed), the joystick handling seems badly broken. My advice : either stick to raine < 0.92 on xp, or don't use the joysticks. I'll try to fix the index stuck at 1 in the next version, so you'll get it as 1st joystick instead of 2nd, but that's probably all that can be done, don't hope to use both at the same time... But it's even unlikely that you would be able to use even 1 pad in this configuration, I couldn't get any result from even the simplest test program, testjoystick, which uses the most basic api for the joystick, I don't know if it's a problem of driver or something else in xp, and I won't loose more time on it, just don't use joysticks in this configuration, or go back to an older raine !

Really... Did you at least read what I wrote ? I don't want a mapping, I just want the output of the testgamecontroller.exe, including names and guids of the controllers found, that's all. Really I am starting to understand these old open source licenses which stated "the program is provided AS IS", meaning you can do something out of it good, you can't ? We don't care !

No luck for you, I also have a ps3 controller, the simplest model, the one without rumble I forgot how they are called, so old that one of the 4 main buttons has stopped working, I keep it anyway to test things like that. It's working wonderfully well (at least for the directions from the dpad) both in windows and in linux ! I even tested by using the nail to touch just the edge of the dpad so that it makes a loud noise when going up and down and the control is selected for about 0.1s only, works perfectly, you see the direction "blink" in test mode and revert to central position. I have no idea how you do that, and I am not sure I want to know anyway... ! Is it windows 10 ? If so really no idea ! (and I even tested with the other controller which is a cheap xbox controller clone I found on amazon, same thing, no problem, both in linux and windows). The only way I can think of to do that is to use at the same time the stick and the dpad until you succeed to make raine nuts, I am not sure I could do that, but I won't even try because it doesn't make any sense, use either the stick or the dpad, but not both at the same time !

mer-curios: about your "blurring" effect, no you didn't answer the part where I said I didn't really understand what you said, this is handled by the filtering option in rendering options, near or linear, linear giving this effect (but very light), and near underlining pixels. Now when the game starts behind the gui, it's not opengl directly, it's just rendering to some sdl texture using their api, so the filtering option is ignored here. Then what do you mean exactly in all this mess ?

well normally all controllers have a stick 0, it''s just the 1st stick ! You might eventually want to try the controller.7z file I attached in a post up there to see what it reports when it sees your controllers. After some thinking : if you see "stick 0" it means that your gamepad is not recognized as a game controller, but as a simple joystick, meaning it works exactly as in sdl-1.2, and you won't have any dpad redirection because it can't recognize the dpad in this case. But you'll be probably able to remap the dpad to anything (hum, just maybe, try it and tell me, I think I removed the hat detection for the joystick and maybe I should have left it for this kind of case). Yes I know, it's not very clear, maybe I should find some way to inform the user in this case. I wanted to test with an old ps2 gamepad of mine because it's unlikely they added a mapping for that in sdl2, but I currently lost its adapter to be able to plug it to the pc... If I ever find it again, I'll test ! Until now for info, that's what the controllermap.exe program in the test archive I provided is for. To make a mapping for unknown gamepads. If you feel like it, you can try it, launch it by redirecting its output to a file like that : controllermap > log As they describe it : Press the buttons on your controller when indicated (Your controller may look different than the picture) If you want to correct a mistake, press backspace or the back button on your device To skip a button, press SPACE or click/touch the screen To exit, press ESC There will probably be buttons you don't have, so you'll have to use the space key to skip them. In the end it should output a mapping, send the log file and I'll include it in the next version. It's possible to include this to raine to allow users to make their own mappings, but I think most people will already have a recognized game pad. This setup is the one used by all 3 major consoles right now, and all gamepads sold these days follow the same rules... It's easy to add the option to be able to remap the dpad as 4 buttons instead of having it for movement alone, could be used for combinations, if you are interested it can be done...

Joy 2 ? It means it doesn't even have a proper name for the device ! Wow... ! Well, yeah there are test programs with sdl... I'll try to compile 1 for your windows... but you'll have to run it from the command line, this kind of program expects people to have a proper console... ! Here it is, controller.7z, unpack in a directory, add SDL2.dll (the one from raine), and run ! You should get info in the standard output, if your console is to crappy to see what it prints, redirect it, it might work without redirection on xp. It allows to test all the controllers connected with more info than you'd ever want ! And I have added 2 exe in the archive by mistake, well the one is testgamecontroller.exe, you can try controllermap.exe if you want, it's to make a new mapping when you find a gamepad unknown to sdl2 (to recognize what is what in the controls). controller.7z

Just added some experimental handling of raster effects for cps2, finally, it's the consequence of having spent too much time on msh... I read somewhere on the web that emulating raster effects is easy, the guy who wrote that spent too much time on mame which tends to hide the complexity of things with its interface, but raster effects are usually high risk programming, even on the original hardware, with time the clocks tend to de synchronize making this kind of programming unreliable, I saw the effects of that on some old atari st ! Anyway, the cps2 raster seems easier than neogeo, so it would have been a pity not to at least try them. I tested only in 1 place so far, the lava level in msh attract mode, probably the easiest spot to reach using these effect. I had to disable speed hacks for all cps2 games because of that, which is a pity because they are actually rarely used, but it's hard to disable a speed hack on the fly so the safest option is to disable them for all cps2 games for now. The result is not too bad for now, runs rather well even on a debug build with no optimization (but with the asm cpu cores which are fast even in debug mode). It will probably create more bugs... but anyway there were places which were unplayable because they were not emulated, it will probably not be worse than that ! edit : and finally found a way to have the best of the 2, the speed hacks are temporarily disabled while handling rasters effects and they come back after that ! A little crazy, but fun !

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