Tux

I am sorry to inform you that in this case, inputs -> d-pads for movement : no You'll still be able to use the d-pads for movement by mapping them explicitly. Sorry the dead zone is too big here, these pads were not supposed to have one in the beginning and I won't resurrect the old calibration screens because of that. Try that and see how it works... Curious... I can't test one now, maybe one day. Yeah it's a side effect of what I chose to do here, since I don't have the masks for the priorities I decided that these big 32x32 sprites should mostly be use for background and not foreground, so I force them in the background when they are at the highest priority. It allows to have the shoulders of the giant drawn correctly. I'd say this glitch is minor in comparison, for now I can live with it...

Finally more time to finish this one... I even thought about adding something new to emulate for a while, but too many things to do for that for now, maybe later... So the main fixes are around the game controllers, and the dead zone of some which canceled the moves from the d-pad. Also there are about 100+ new recognized game controllers for linux, and 400+ for windows ! (more people would use windows ? What a surprise !). All these new controllers mappings come from there : http://raine.1emulation.com/download/latest.html The other big part is the improvement for cps2 rasters, and the priorities in xmvsf, notice the priorities are still not perfectly emulated, there are probably places left in some cps2 games where there are problems. Except that most of the emulated games are now rendered in 16bpp because most of the emulated games have color palettes of 16bpp or less. 2 exceptions : the taito f3 games, and macross +, for these 2 it's still 32bpp, for all the others it's 16bpp. The reason ? Smaller bitmaps, so it's faster to draw and faster to render to screen. And there were problems with some taito f3 games, especially in 64 bits, but even in 32 bits there was a black screen for puchcar on boot because of a recent fix. All this should be fixed now... It's almost a Christmas version this time ! http://raine.1emulation.com/download/latest.html

Congratulations, it was merged because of your direct post (the pull request for the mappings), I'll be able to link directly their repository which will be easier, thanks. And I added some hack to draw correctly the giant boss in xmvsf, I am not proud of it, but it works. As long as I can't emulate these broken priority masks I'll be forced to add hacks like that, but anyway it should do for now...

They replied this for the mappings : not too sure on these.. could you please ask your user to refer to the Windows game controller dialogue and make careful note of what each of the buttons are registering to be sure ? for example A = 3, B = 5, C = 7, etc. thanks ! Well, it's really becoming too complicated just for something which should have taken 5 minutes. You can check that if you want, if you don't I'll understand and that's really no problem, I already told them that at this level it would make things easier if they just say they refuse the pull request ! I already merged these mappings here anyway.

It's finally fixed, it's the kind of detail which pisses me off ! Your savegame can't be fixed automatically, if you load it while the rasters are active it will continue to crash, BUT ! if you make another save now, it will be "rasters resistant" ! And you can fix this one by doing this : launch the game as usual, then activate pause, load your savegame, once it's loaded and still in pause, save... ! Done it's fixed, now you'll be able to load it with rasters active ! It was a mess to fix, and that's just for cps2 rasters, but anyway I might use this one day in more drivers... !

Yep, that was it, yes you misunderstood for the axes, a d-pad is not a stick, but anyway. Thanks for the updated mappings, I just posted them to the pull request, and I just sent the photos too, it should be enough, thanks for that. Well the issue of the blank window hasn't shown for me for a long time, it might be related to the video driver, I am not sure. I am able to test only on my nvidia desktop here, the laptop doesn't have windows ! (you know people that the linux world doesn't have all these problems ?) After looking, I'll avoid the "d-pad only for movement" for now, on the modern pads with 2 sticks it makes the 2 sticks totally useless, it's obvious that it's just a way to work around a bug, and sticks can be used for something else too (combinations can be mapped to a stick direction for example). So we'll try 1st with the dead zone filtering only, and if some problems still happen for some people, I would advice to simply disable the feature in the inputs dialog in raine to use only the sticks for movement (but it shouldn't happen with such filtering, if it still does, there is quite a serious problem with the pad). By the way it's not a sign the game controller is bad quality, my ps3 "six axis" (that's the way this model is called, no rumble functionality inside, but still the bluetooth inside) has lasted for more than 15 years, that's quite impressive for a game controller even if I didn't use it very much all this time.

Yeah it could be a good idea to be able to use the dpad only for direction, fixing this problem for good. Also I'll limit the dead zone filtering to when using the dpad + the stick for direction only. There was no magic here, I just added some printfs for all the events raine recieved for the controller, and sometimes it received storms of moves which never seemed to end, actually it's possible to end it by re centering the stick manually, but it's not so easy to do. With this, the problem became quite obvious ! No didn't see your fullscreen -> windowed problem, it's an old problem, windows only. So you start the emu in fullscreen, load a game, then use alt+return to switch back to windowed mode ? I'll try to have a look... So you used already the sega layout in the mapping you sent, and the playstation one for the other ? By the way all the arcade cabinets (or so) use real sticks and not dpads but it's right they are used like a dpad, contrary to the sticks on our modern game controllers. Edit : can't seem to be able to reproduce your blank window. Normally if it happens pressing esc brings back the gui and after that it's ok but still I'd like to be able to reproduce it. Tried starting from fullscreen with a game loaded or not, switching using alt+return or the gui, the whole thing in opengl, everything worked fine. And tried in windows of course. Oh well... !

Ok, I finally understood ! The problem is simply that the sticks on the ps3 / ps4 controllers are too sensitive ! The stick gets very easily moved from its center position and once that happens it keeps on sending move commands around the center position. While you use only the stick for direction it has no consequence, it's just a rounding problem, you don't even notice it. But if you use the dpad for direction which is mapped to the same stick, the direction gets continually cancelled by the stick movement around the center position ! There are 2 solutions to deal with that : deal with the dead zones of the joysticks, that is, ignore these stupid parasite movements around the centre position, problem being this dead zone can change from 1 joystick to the next so we would have to add a way to define the dead zone for each joystick or try to define 1 large enough so that it will work everywhere. Or decide that using the dpad at the same time as a stick for the direction was finally a very bad idea, and just forget it and remove all the code about it ! I'd say I am for the last solution, this thing was too much trouble. You'll still be able to use the dpad for direction if you want by mapping it explicitly in the inputs, but in this case it will replace the joystick, and you'll be able to save that as custom inputs if you want, that's what was done in sdl-1.2. I'll sleep on it and decide tomorrow, but that was the problem, something stupid finally ! The sdl2 mappings for the game controllers are still useful to have sane defaults for all these controllers, but that's all. After some more testing : linux has some builtin compensation for this dead zone, it's impossible to trigger it on the ps3 controller. On windows, it's very easy, just move very slightly one of the sticks, it will start to report continually some movement, for me it's easier to do on the left one than on the right one. So it's a driver problem in the end... ! I am tempted to try to ignore the dead zone at our level, it's not hard to do : central position is 0,0, extremes are 32767, -32767, when this dead zone problem happens it sends moves around position +-1000-1200, so I could just ignore anything < 2500 in absolute value, it should get rid of all this mess in just 2 lines. I'll try it, it's just 2 lines of code. But after this, if I have ever some other problem with this, it will be time to remove the dpad as a directional stick ! The shoulders problem is yet another problem with the priority bitmap in cps2. It's not fully implemented in raine, it's a very complex thing, they use masks instead of simple priorities... It was already broken in the versions before the rasters it's not directly related to them, it's "just" a priority problem, but a very complex one, so no promise here... !

No need I can do it even in linux, left and right, I thought you knew already. In fact until yesterday I thought it was simply because the ps3 was becoming too old, before getting a doubt because of you. The way to reproduce it before this version was simply to turn around the dpad until the left/right direction becomes unresponsive. I couldn't do it with this version, hence the idea that you test it. I might be able to get a ps4 controller for testing, but it's not sure, and it's a hassle... Yeah I know it looks weird, but I don't know what it's supposed to look like ! Yeah it's just that xbox & sony are the 2 main ones, they just represented the less known ones. For sony it's X = A, O = B, the square = X, the triangle = Y, I thought you knew that, everybody who tries to use a sony controller on windows has to learn this since windows tries very hard to force everyone to use the xbox controller convention. It's exactly the same layout as the xbox controller this way. Yeah I agree your 1st looks like the sega, the 2nd is a little extreme since there are no sticks, but I guess it can be useful to know at least where the dpad is. It can't redirect the dpad to any stick in this configuration though, but it should work anyway. You didn't say if you need to upgrade your mappings to follow their choice of button layout, but probably for at least one of them. Well it's not an emergency but try to do it so that I'll update them and send all that... It's your mapping ! Well I don't have many ideas on how to follow on that for now, I'll try to get a ps4 controller for a while at least, it will be easier. Maybe the thing is easier to reproduce in windows than in linux ? At least it works better for 2 of your controllers, the xbox one already worked, so it's almost perfect, just the f*** ps4 one which has some problems left...

And then I have a new binary to test for you, 64 bits since it seems it's what you use. The exe alone, drop it in a raine directory so that it finds its files. It adds all the hints from testgamecontroller, the sdl2 test program since some of these hints are not even documented, and remove a SDL_PumpEvents which shouldn't harm anything but which is useless. I noticed the dpad on my ps3 controller seems to work better in this config. Which is strange, but anyway. Test that on your side. It also includes the update for the rasters. These attachments are quite convenient, I wonder if there is a size limit ? I might delete the attachment once tested. Also I found a user maintained database of gamecontrollers for sdl2 on github, and the 2 mappings you sent were not in the db, I just proposed them ! I'll probably use their db in the next version... It's here : https://github.com/gabomdq/SDL_GameControllerDB ... and they replied : Hi, thank you for these! Can you please refer to the mapping guide for button layout to ensure the mappings are correct? https://github.com/gabomdq/SDL_GameControllerDB#mapping-guide Thanks again. so if you can take a look... ! raine.7z

It's fixed, it was quite easy, I had a doubt about sprites priorities being updated only on vbl so there was a commented piece about that, it was almost only about uncommenting it (and updating this part). Well you clearly see the screen separated at the places where the raster has an interrupt for the save state you sent, which gives it a very weird look, but apparently it's the way it's intended. Anyway the background is now behind the sprites which makes it playable despite its strange look... For that I can't do much, it's because the savegame is done with the speed hack enabled, but it's disabled when the raster becomes active, so if you load it then the 68000 arrives in the middle of nowhere and it crashes if using musashi in 64 bits (with starscream it's not a crash but the game is frozen anyway). To fix that I would need to find a way to save the modifications of the rom made by the speed hack, which is not obvious... I'll think about it...

?!? I really don't have any idea how it could happen only in this version and not with the sdl-1.2 version... Even the way you describe it : if you can't maintain a direction, the source of the end of the release of the direction can come only from the controller (it works by events, it means an event was sent to release the direction). Anyway we can stop talking about that, for me it's exactly the same in linux, windows, or with the sdl-1.2 version and I really don't see how it could be different, I have absolutely no idea how it could be different... Yeah this bug has been fixed in the very 1st changes for 0.92, and no I won't maintain another sdl-1.2 build, even if this version can be compiled for it. Crazy story... ! And Augusto has totally disappeared from here apparently... !

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