Tux

You describe a low level problem, either hardware or driver level but more likely hardware : a direction which can't be maintained. Nothing comparable to the problem fixed in 0.92.3 where as soon as an unmapped dpad was pressed, a direction was stuck. I have that partially on the dpad of my ps3 controller, but it's very old now, so it's normal (and only on the very old one, the new xbox controller clone works flawlessly !). There isn't much I can do here. For info I found a way to disable xinput for sdl2 if you want to test it, see there : https://wiki.libsdl.org/SDL_HINT_XINPUT_ENABLED So to try that without recompiling raine you need to have some command line like what you did for the controlmap thing, then type : set SDL_XINPUT_ENABLED=0 and then run raine from the same command line. The default is to have xinput enabled, so you'll see how it goes without it. For me on my real windows it doesn't make any difference. You have the list of hints there : https://wiki.libsdl.org/CategoryHints They say one of the differences with xinput is that it supports only up to 4 gamepads, but we never support more than 4 players at the same time in raine anyway. For now I have no idea for your problem, eventually try to plug only 1 gamepad at a time, they should not interfere with one another, but what you describe is not normal for sure ! For the rasters, sorry but it was to be expected, I was too lazy to test all the uses cases for it, and the lava level in the attract mode was the simplest one, I would have been very lucky if everything had worked without testing. msh is the kind of game I like watching but not playing, so it makes testing harder, thanks for the savegame, I'll look in more detail later.

Just some quick reply for your gamepads before going to bed : Last time I heard about your gamepads, you had 2 gamepads recognized as game controllers because of the mappings you sent and everything worked fine. Now you buy a new one, and 2 gamepads get broken ? !!!! It doesn't make any sense, I don't know what you are doing with that but it sounds crazy ! Anyway it was useless to try to make a mapping for a dual shock 4, it's recognized out of the box since it's a recent controller, you should know by now that if you see "leftx" or "lefty" instead of "stick 0" it means the gamepad is recognized and doesn't need any mapping. No I won't change my driver on my side, I don't have an official driver, I have something unofficial, at the time we didn't even think sony would make an official driver... and no I don't want to change a setup which works, it's windows, it might explode if I change anything ! Anyway, just load a game like sf2, go into the dipswitches and select test mode in the last dipswitch. Once in the test mode, navigate to io test using the keyboard and not touching your gamepads before you are there, then inputs. When finally you are on the inputs screen try all your gamepads inputs 1 by 1 until you find the one which leaves a direction stuck, and report. Good luck, ! You can try that with or without the mappings file, but maybe it's better to use the one which was in the archive before you modified it...

Arf, you made a mix of everything here ! Nope, it's a for allegro, normally the dos version uses seal for its sound, but since some people reported issues with it, I tried with allegro for testing. For a soundcard from around 2000 or before you'll have better chance with seal, but for something more recent this version might work better, not sure. The language = C is nothing like that, this setting is just ignored by the dos version anyway, it's the international language used, C means no locale, and in this case it falls back to english. There is no translation in the dos version anyway, I don't think the libintl is supported in dos... ! (well actually there are still the very old translation files from before 2000, but they were made totally differently, and don't use the notion of locale at all).

A short word on the linux version : I forgot to update it yesterday, just did it, and I noticed I forgot to update the new dependencies for version 0.92 (sdl2, sdl2_ttf, sdl2_image instead of sdl, sdl_image, sdl_ttf). That's a weakness of this PKGBUILD, dependencies are not dynamic. There was also an old dependency to GLU, I don't even remember why it was added but it's been ages since it's not needed anymore, fixed that in the makefile too. So there is a brand new PKGBUILD for this version, and I slightly updated the text on the download page to tell the 32 bits and the 64 bits packages are now built using only standard libs from the standard repository since sdl_sound was merged into the source of raine.

Yeah I think I can call it like that, that's him who reported all the bugs to fix, with great descriptions to be sure to be understood, he was perfect on this one, even if I was a little disappointed to see 0.92.2 disappear so fast ! Anyway here are the fixes this time : - the sound associations were deleted if you loaded any game which had some. This reason alone was enough to make a new binary to avoid that people delete all their associations ! - yet another gui problem where the loading dialog was zoomed too much. Fixed, and the default is now to use opengl for rendering, which makes much more sense since it has more options and is much more tested. - cps2 rasters are better, see the details in the 0.92.2 thread if you want to know how. - and the joysticks configuration changes again, which obliged me to reset again the keys configuration since they are saved with the keys. Sorry, it should be the last time I do that. This fixes a conflict between the hat of a gamepad and a stick direction if the gamepad was not recognized as an sdl2 game controller. This one was hard to precisely pinpoint, but anyway it's fixed too. Very few changes, but they were necessary. I hope to rest longer this time ! http://raine.1emulation.com/download/latest.html

About the mappings and the game controllers : they are handy, you know which button is which, you can assign what to do with the dpad, but I think they are not worth asking people to make a mapping just for that. In the next version released very soon now you'll have better defaults in case your controller is recognized or you have a mapping for that, but otherwise you'll be able to fix what you want in the controls. The only thing you can't do if you have an unknown gamepad is assign the dpad to movement like the main stick at the same time, it can't be done since we don't know what is what in this case, so you have to choose. I think I'll just leave things as they are, those who want to create a mapping and send it can do it, the others will do with what there is...

Long post, and I am tired, I should return to bed, so I'll try to make this short, eventually details later. 1) the no output from testjoystick is because of the stupid redirection there is in cmd, here the output is on stderr, so you must do testjoystick 2> log, sorry I missed it, but maybe you won't need it. 2) I was able to reproduce your problem by accident, that is I remapped the directions for 1 pad in the inputs, and then while testing in game since everything worked correctly I tried the other pad, and the left direction was stuck. It happens only if : 1) using something which is not recognized as a game controller (you removed the mappings file, I forced the detection of my gamepad) 2) using the hat ingame while the inputs are using the stick 0 for the game in raine. In this very particular case, when you release the hat after having pressed it, the event is taken as the stick 0 going left. Said otherwise : you can't mix the dpad and the stick 0 in the inputs if using something which is not a game controller, you must choose either one and stick to it. Now I'll probably add something so that it doesn't happen again, I'll have to find another way to encode events for that, it happens because the sticks start at 0, and so the hats (which is the way they are numbered by the drivers and reported by sdl2), I should make them start at 1 in the encoding to avoid that, I'll do it later after sleeping a little more... ! But anyway if you map your controls correctly, it doesn't happen. Now the way it works in the gui is simpler, the movement is recognized for any stick, and hats movements are translated as movement of stick 0 (even if you don't use a stick 0 on your controller). Normally there is auto-repeat for the hat or the joystick, I tested that with my pad recognized as a joystick, and moving in the gui using the hat or the joystick produces exactly the same thing, so don't know why the auto-repeat doesn't seem to work for you here. Ingame it can't translate the hat to stick 0 because stick 0 could be used for something else (when it's not a gamecontroller), so it interprets the hats directly, without translation. In sdl-1.2, it translated the hats ingame to a virtual stick which didn't exist in your gamepad to be sure there would be no conflict. Anyway I am sure you can fix that by fixing the inputs for the game, if no "stick 0" appears anywhere for this joystick when using the hat it will work. I'll update things with the new encoding later, but in this case it will have to erase all the joystick configs in the config files for the next version !

And finally the rasters, which sent me in a stupid search when it was a stupid mistake, it's just that I thought the border of the screen was 16 pixels, when it's 32 pixels for cps1 & cps2, because of their scroll3 layer which has 32x32 sprites... ! This simple mistake produced your strange square on the right of the screen... ! Anyway...

And it was just a stupid error, totally unrelated with that, an old hack used for neocd games which was also used for neogeo games until now, except in previous version I added something to force the deletion of the keys in the configs, but because of this hack it also deleted the assoc section by accident ! Sorry I didn't notice, I hope not to have destroyed anything valuable in your associations but I am sure you have backups for that ! The fix was only 1 line, to limit the hack to neocd only, which should have been done earlier !

This is because the default is sdl2 native as video renderer when it's the least tested one, I just changed that, now it will be opengl. And in this case the loading dialog was zoomed to the game resolution by mistake, it's fixed too.

To be sure we talk about the same thing : you remove or rename the mappings file (which is just an ascii file that you can open with a text editor and which just contains the 2 mappings you sent), and then launch raine with a game, and start to remap you controls in the input section to match the version without the mappings file, and once the inputs have been correctly setup, you go in game, and it doesn't work as intended, specially for direction, correct ? If that's the case then your gamepad is doing something weird, and I need more tests because I just retested with mine, and it works perfectly. So here is the basic testjoystick, unpack this, put it with the dlls32 for raine, run testjoystick > log to get the log file about what happens. The version for sdl2 doesn't let you choose which joystick to monitor so maybe you'll be able to have only your gamepads plugged to see what happens, anyway once you have the right gamepad which is monitored, just move in one of the dpad directions and release it. Once it's done you can quit by pressing ESC with the window active. Check you have some info into the log file related to the movement and not just the info about which joystick was opened. Once you have the info send that here, good luck ! testjoystick.7z

Good thing, I wouldn't have had any other idea to fix it ! Good eye, not sure if it's fixable and how, I might take a look later. Really ridiculous you know ? but it's right there seems to be a problem about its size, but here again if you start in fullscreen it will do... Oh well I might take a look the fix might be easy... It's been like that since January 2013, funny it took you so long to notice ! I did that because 2 transparent dialogs with plenty of text on both results in an unreadable mess. Yep normal, didn't add any option yet. Well I am not sure how you do that, I already tested this scenario by forcing the detection of my own gamepad as an old joystick instead of these game controllers, so I could test remapping the hat, which I did for the direction, and it worked. I'll retest to be super sure, but if it works again I don't see what I'll be able to do about that... ! Catastrophe ! And weird I don't see why it happens, I'll have a look... Totally unrelated, notice the shaders currently in raine come from an old version of retroarch.

?!? I thought you had access to only 1 pad in xp ? So the version is perfect in xp now ? Well good news, even if I didn't do it on purpose ! To be more precise : I added some code to reset the joystick's indexes when they were obviously wrong as in your case, but I didn't think it would work that well, and I was unable to test it with my current setup anyway (might be because my xp image is based on tinyxp, which is very convenient to quickly test something, but maybe they removed something which was useful here...)

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.