Tux

In fact it's not so much the driver itself, it's what kind of hardware there was inside. There is a last potential in raine which was never used in all these years : starscream, its default 68000 emulator can also emulate a 68010, but there is no game using a 68010 in raine. Now it's more complex than just calling a function to tell you want a 68010 here, you have to assemble a separate version of starscream just for that, with all its function starting by s68010, making all this a mess. But I found lately that I can use the 68000 functions to prepare the emulation and just change the cpu type at the end to actually run the emulation, and it should work, so it was worth a try after all this time... Then something interesting. Well some old atari hardware was intriguing, using a speech synthesizer despite their old age, these are pre-1990 games, usually the games of this era are very primitive. I even remember this kind of chip, they tried to sell some for the old 8 bit computers like the oric, it was very expensive, so nobody bought them, but it was still intriguing. Not something too complex though, the gauntlet driver seemed fine for that, it's not exactly easy, but at least it didn't look too complex, and there is a last reason for that : Neil Corlett, the author of starscream wrote a gauntlet emulator for dos a very long time ago, mge, but he didn't release the source and so this thing is totally forgotten now (and it's too bad, I would have loved to have a look at certain parts of this source). That was it, it was going to be gauntlet then ! Well I must say it's maybe the only game where I never played the arcade machine and I didn't like it, it was obviously some cash machine, something made to just get more money, making the conversions for the computers of the time actually more interesting. But still, it was worth trying this. Well there was a 1st problem : the slapstic, which is some kind of parasitic chip connected to the rom, which intercepts the address bus requests to make things more complex. There was an incredible work done by mame in the old days to document this chip, they even made some very clear and portable source to decode them (in their old versions, since then it was contaminated by their c++ frenzy and has become very obfuscated and not portable at all, but I don't care, I just used an old version). It almost worked directly in raine without modification, almost, it gave me some small problems and this thing is not easy to debug, but anyway. After that, there was the fact their sprites for the "playfield" layer are inverted (they should be xor-ed with 0xffff, it took me a very long time to find out because I am not good with sprites problems). Anyway it was an interesting challenge. After that the real stuff started : the inter-cpu communication (there is a 6502 for the sound with the 68010 in this game). The code to synchronize the chips in this game is crazy, the main cpu sends a reset request, in its reset code the 6502 checks if there is a sound command waiting, if there is none it enters an infinite loop and it's game over. So it must receive a sound command, but not the nmi which goes with it because if it has the nmi then it can't see there is something waiting ! Just crazy ! Anyway to sum up things at this point : I finally have something working (except I didn't add the real sprites yet, just the layers), but only with the C version of the cpu emulators ! If using the usual asm versions, there are serious inter cpu communication problems making the sound almost completely broken. The 68010 emulation in starscream was broken for some reason, I fixed it last night, a problem in the rte instruction, but now the result is exactly the same as using its 68000 code ! And there is also a problem with the 6502 asm emulator apparently. Well the good news is that it's working great in 64 bits ! It will probably be the 1st game working only in 64 bits, becasue debuging these asm cpu cores is extremely complex and time consuming, I already spent quite some time time on them, fixed some bugs in both, but I think I had enough of it, there is not much point pushing things more than that at this point. The funny thing is that the sound works very well, I had no problem on this side ! Actually in 98-99, mame and raine used the same sound drivers, so I just took some old versions for the pokey and the tms5220 chip since these are old drivers in mame, and they worked with just some slight modifications to adapt them to some things which are different in raine. They work well, but the speech synthesizer would be very hard to use out of this emulation, there is no high level interface, but it gives quite incredible results if you think about the year it was made... ! I still need to clean things up, there is also kiki kaikai which is broken (I found this while cleaning up some headers !). So I'll take some more time to finish this. It was an interesting experiment even if quite frustrating in the end I must say. I think the code used by mge was heavily hacked to be able to work in these conditions. It would have been interesting to see how it was hacked. The slapstic doesn't use a simple test, and there was also the inter cpu communication to patch to make it work, really too bad he didn't release the source, I would have been very curious to see that (his official site has gone with his mail, there is a page about him there, because he got famous about some rom hacking tools too : https://www.romhacking.net/community/99/ )

at least it's not that, but sorry I can't help you, no xp boot here, and virtualbox doesn't support 3d in xp anymore making my xp virtual machine totally useless. Well, keyboards are underrated !

yeah I can't test on xp, you can try the advice, remove the gamecontrollerdb.txt file and see if helps. If it does, report here !

Ok, in good way, all major problems fixed, but I'll take more time to finish cleanly this. I got distracted by something else which made me find some other unrelated problems. Anyway... !

Sorry to tell that I have much more problems than what I thought, I didn't choose an easy one too, it looked interesting and not too complicated, well finally it's quite crazy, and there are differences of behavior between the asm cpu emulators and the C versions, which is a very bad news, and I am deep in tests now... !!!

For now don't be too impatient, it's a crazy idea which will take quite some time, especially since I don't want to spend all my time on it... Oh well, we'll see in 1 or 2 weeks...

Yes the last changes about roms was probably the toaplan2 update, which was in january 2021, it took me quite a long time to succeed this sdl2 transition, and 0.91.13 is after that, in february 2021, so you are lucky ! Actually without roms raine gets them from the internet archive, but their romsets are from 0.91.4, so a few roms for toaplan2 are bad sadly, maybe they'll update one day, but they have almost everything working anyway. I might add something new soon, if I find the time and the courage !

mail notification ? It probably arrived in your spam folder. Try to find it there, use the button to tell it's not a spam and next time it should work... By the way the forum also displays a kind of popup if you leave a window open on a subject to tell you a new reply has arrived, it's not a window popup though, you have to display the forum's window to see it.

Don't talk about new year releases again ! Anyway it's just a quick fix of 0.92.5 problems : crash if opening the sound options dialog, leaving it, and opening it again (!) Bad playing frequency of external audio tracks (except the raw format ones !) And there was a bad entry added to the hiscore.dat hosted here, it's probably me who added it, but a very long time ago, it was for viewpoint, and the syntax was a mix between the old format and the new one, and the hiscore parser didn't like it (what a surprise !). Since this file was here for more than 1 year, I fixed the parser to accept this syntax too, even if it's the only entry of this kind in the hiscore.dat ! And I added the hiscore.dat to all the binary packages, linux & windows (going from 2.5 Mb to 2.6 Mb, what a deal... !). Let's forget 0.92.5, I'll just keep the thread for the infos about what's new. http://raine.1emulation.com/download/latest.html

No worry it's fixed, it was a bad understanding of a frequency parameter... It worked with raw audio files, but not with normal audio tracks, and it was noticeable only if using a frequency like 22k like here. Irritating, you'll get a new binary, but I just found something else about the hiscore.dat file this time, I was using another file here and got a surprise when I used the one currently on the web site... Talk about a disastrous release !

No, not so far. Seems like some audio played too slowly ? Doesn't make much sense, it's a wav or mp3 track isn't it ?

I just updated the instructions on how to compile, it's now very easy to do it in windows, you can get almost everything automatically, so it would be nice to get some feedback from someone wanting to try that. The instructions are there : http://raine.1emulation.com/download/install.html and they are also linked from the bottom of the latest version page. And the crash of the sound dialog is fixed in git of course !

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.