Tux

Nope the save states can't be fixed, new save states should be ok though. If you can reproduce the problem with a new save state, I'll be curious to know how. For the gui crashing the 2nd time you open sound options : my bad, sorry, you'll have to avoid to do that for now, and don't worry I can reproduce it without problem here, something to do with an allocation of strings I added in the end without testing it enough. Yes you need the hiscore.dat file in the raine directory. I thought about putting it in the release archives, but it almost never changes, although now that it's stripped of unneeded stuff it's 70k only, so maybe I should put it in the main archive now. Anyway it's at the top of the extras download page.

Slow version this time, just some improvements for the sound, you'll find details here : And added galaxian emulated sound, you'll see the details at the post below this one here : Except that a few more fixes, the more outstanding one at least for me was a bug in the hiscores which could wrongly reset its status for some game, I found out on some very old one, "ms pacman attacks", which is available from "multipac 1.5", it lost its hiscores a few seconds only into the game ! It probably affected some other games too. Lots of small fixes for emudx games, it's been a long time since I didn't touch this, by the way the initialization of emudx games crashed in 0.92.4, so if you want to test that you need this version ! Also a lot of sound chips now correctly save their state in the savegames, games like batrider now restore correctly their sound finally (yeah it should have been done long ago... oh well !). http://raine.1emulation.com/download/latest.html

Don't worry it's been fixed on december 31st already, but it's a slow time for now, hesitating between a few options, so finally except hesitating I haven't done much since January 3rd ! Oh well, I'll release a new binary so you'll get the fixes for that. For info, I talked with Mike about the 1st screen of donkey kong (when you insert a coin) and a few other things too. What there is now is not optimal, because all the game sprites are not available in the dx version so I can't draw what I want on screen. I think the best option is to revert to the emulated graphics just for this screen, and start the emudx game only once kong is at the top of the ladders and has jumped. But I didn't do it yet, so you'll get the "in between" version, with ladders drawing and disappearing while kong is climbing, really not optimal... And galaxian sound too... Anyway !

Very old stuff : I found lately a forgotten file in the git repository, galaxian.c in the sound directory which was a beginning of the emulation of the sound for galaxian, which I had started around 2007, and then completely forgotten, it was imported in the initial commit to git in 2009 and I didn't even notice ! At that time I had given up the idea because the sound for galaxian is quite crazy, there is no sound command, no dedicated cpu for the sound, and the main cpu directly plays with frequencies to generate sounds. Which means you have some basic square signal generated at a very low frequency which must be converted to a playable frequency, and then it changes the base frequency of the signal in real time... ! Add to that that the background sound you hear during gameplay is generated by 3 samples playing at the same time at slightly different frequencies, + 2 channels for the sounds, controlled by timers too because otherwise it's not fun... ! Since I was busy with sound options lately and I felt more comfortable with sample rate conversions, I gave it another try, and this time it's good, galaxian finally has an emulated sound. By the way this game is supposed to date from 1979, it's amazing what such an old game can do ! Until now it had only emudx samples, but it really felt incomplete, in the real game you have a background sound which slowly accelerates when there are fewer and fewer enemies on screen, that was really missing from the emudx version. You can still choose to have emudx sprites and/or emudx sound to compare anyway !

Slow progress, while I was in the audio functions, I added the ability to change the audio driver and the audio device from the gui. For the device, most computers have only the default sound card, but for the one I have plugged to a tv, it has actually 4 devices, 1 for the analog output, 1 for the digital output (the digital plug behind the computer, that's the one I have been using for many years), 1 for hdmi 0, and the last for hdmi 1, these 2 hdmi being what the video card exports. Which finally allows me to switch easily the sound between the stereo and the tv, I had never actually used the sound output on the hdmi until now on this setup, it doesn't sound bad... For the driver, it shouldn't be useful for most users, for wndows it's directsound by default. For linux it's pulseaudio if possible, otherwise alsa, otherwise dsp. The names of the output devices change depending on the selected audio driver... ! And each audio driver can have a preferred frequency, so the default frequency changes with it. Also the neocd raw audio tracks which worked previously only if you had set your audio output at 44.1 Khz (cd quality), now work with any output frequency, and it doesn't sound bad at 11 Khz actually ! (at least for the game which I tested, which was viewpoint). The conversion for the wav/mp3/ogg/flac format was already done automatically, there was only this raw format which had no conversion and which required 44.1 Khz output.

Well apparently the status of the ym2610 (the sound chip used by neogeo/neocd games) isn't saved, I had even forgotten it was not saved because it's extremely rare to have a problem of restoration with it. Actually the fm part is saved, but it's almost never used in these games. The reason why is it's a mess of pointers inside. To sum up : you were just out of luck on this one ! I'll see if things can be improved at least a little... Ok, just added save ability for quite a few sound chips, including the 2610 required here, but quite a few at the same time. These were things to do for a very long time, but since it's boring and I had to find a way to translate some pointers 1st, it stayed like that for ages. For the pointers I simply manually added a name field so it can now recognize them. I didn't test everything, some games didn't even save the z80 ram, so it was sure to loose all sound in most cases when loading a savegame (all the gunbird driver and quite a few toaplan2 games were like that). Anyway it should have been done long ago, but better now than never !

Glad to know this controller problem is finally in the past, I think I'll take a little break and look at what you found later. It's strange you find it now with all the tests you have done with the neogeo/neocd driver, nothing has changed recently in the way things are saved for this driver, so why now ? And if it's something which is not saved then maybe it can be reproduced only if I load it from the same place as you ! Anyway didn't test it yet, I'll look into it later. On my side when I tested with kof98, I loaded kof98 neogeo first and had a crash the 1st time. The crash happened at the very beginning of a fight, probably dependent on the background scenery, I have not been able to reproduce it, but there might be other problems to find then... ! edit : more info needed, when did you create this save ? With latest version ?

As you said here, it's a different bug, just something which survived because I almost never use a pad in the gui because it's inefficient (even though it's fun with the autorepeat). It's just a gui bug, when you press the controller button to return to the game, the game thinks your button is still down while it's up, to work around that just press the button again when you'll be ingame, you'll notice that the character won't play its fist animation (if it was button 1), press it a 2nd time and this time you'll have the fist animation, you're back to normal and you can do the double-tap again. There was still a little bug in my cancel sticks logic, I made it global so that if you play on 1 pad using the d-pad and another using a stick, you would create havoc, the 2nd pad would cancel the 1st pad ! I fixed it here, but it should already be ok for 1 player on your side. I'll fix the gui problem with the pad later, thanks for your report anyway ! edit : you got new binaries for windows, december 22nd. The gui bug was actually recent, it's because I added something so that the game part can pre-process the gui events to simplify the code and avoid to duplicate things. It pre-processed the buttondown event, but not the buttonup, yeah I might have gone a little too fast on this one ! Anyway 2 new binaries, probably the last ones for 0.92.4 this time, it's for windows only of course.

Hehe, thanks for the support anyway, yeah I tend to use the keyboard a lot too, especially for arcade games... !

Got a new idea for this mess between d-pads and sticks, and easy to implement, so I just uploaded a new binary still with the same version, compilation date december 21st this time, I hope it will be the last ! The idea is very simple, I should have thought about it earlier : when receiving an event from the d-pad, just cancel any event coming from the sticks until a stick move of at least 16000 in value, which is half the maximum distance it can move in any direction. This replaces the previous dead zone detection which didn't work with some models. This filtering is done for the games and for the gui, so it should fix everything. Update for linux unnecessary since linux does that at its driver level ! (the idea came while playing a native windows game which was using the ps3 gamepad, I could use their menu using the d-pad, so it occurred to me that the only way for this to work in windows reliably was to cancel the stick events in this case... ! The game very probably used sdl2 for its input)

Maybe it can be improved, but it's not a simulation... we'll think of something eventually... It works when you put the setting to no because it's back to what there was for the sdl-1.2 version : the d-pad totally separated from the sticks, that's also why after that you need to reassign it in the inputs if you want to use the d-pad. But the gui accepts movement from everywhere : the left stick, the right one, or the d-pad ! So your problems are back for good, the move is canceled again here. Well as long as the sticks are not used for analog inputs maybe the dead zone can be increased... Not sure about that, I'll try to borrow a ds4 controller to see how it behaves in windows... I thought 2500 was already very big for a dead zone, it's quite scary that this thing needs something bigger, for me everything works perfectly here with these settings (ok I almost never play in windows...). For now you can always use the stick or the keyboard, autorepeat works with the sticks too, or use the keyboard it's way faster to control the gui ! There were much worse cases with the sdl-1.2 version, that was the main reason for upgrading to sdl2, and I delayed it as much as possible. Here I can't reproduce it for now, and it's easy to work around, you don't switch from windowed to fullscreen all the time if you save your settings, and when it happens just press esc to call the gui and have everything back to normal, so it's manageable. If you want to test, the other rendering option "sdl2 native" probably doesn't have this problem, but yeah it has a lot less settings too !

Ok, since I forgot to upload the linux version last night, I took the time to fix the dpad in the gui which I completely forgot. Actually xbox controller dpad worked, it's only the playstation dpad which didn't work since it isn't advised as a hat. For info in sdl-1.2 versions the playstation controller had no chance to see its dpad work in the gui because it wasn't seen as a hat at all. Anyway now the hat works in the gui only if the controller is recognized, otherwise you'll just have to use the stick or the keyboard. There was also a small bug in dealing with controllers events, this one probably could show only if using more than 1 gamepad at the same time. So I'll upload 2 new binaries with the same version number. Just check the compilation date it should show december 20... there is no proxy on this server afaik, so redownloading the file should work without problem. Just uploaded the 2 new windows binaries, and the 2 linux packages, mission done, merry christmas, and see you later ! edit : oh, and also I took back the options to control the automatic repeat of joystick events in the gui. They were removed from sdl2 for the bad reason that it's easy to do without it, actually I used only the 2 constants for the default delay and then interval for the auto repeat. Anyway it's back in the options, and it works (and the default interval is now 50 instead of 30, which was too fast).

the old mappings which contained only 2 mappings was replaced by this file gamecontrollerdb.txt, which contains 100+ mappings for linux and 400+ for windows. I don't understand why you have problems with it, and it would be too long to test and I am really tired of it. I don't have the 400 controllers used to make this, and I am glad I don't have them because I wouldn't have the patience to test all that. I'll probably make "d-pads for movement" = "no" the default for next version, which will avoid this kind of posts.

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