Tux

I just noticed I released a debug binary by mistake for the last release in september instead of the normal optimized one... ! Since debug_mode = 0 in the config file it should be reasonably fast nonetheless except probably for the sh2 games (gunbird2 and so on...). Oh well I fixed quite a few games lately, found some old games were crashing at start, so I went on a a big hunt to fix as much as possible, so I should probably at least make a new binary for arch... edit: done, 0.97.6 is arch only for now. Actually you could have seen it was a debug build by launching it from a terminal, it would print "[private beta version]". Not really private this time ! Anyway, if you are curious of all the changes, well these are just fixes, but quite a few of them. Also the DAC sound generation is improved but it changes only those very old games which use a DAC (which is the simplest form of digital to analog conversion chip). Some old games like omega fighter (a z80 only game) and all those from the upl driver were crashing at start. And I finally fixed the tiles rendering in hewksun, I never knew these were bad actually, this driver was from Haze and I checked crospang from the same driver, but not hewksun, no idea why he never told there was a problem with this one, and it was actually tricky to find. Except that quite a lot of bugs found by the "sanitizer" which is activated in the linux debug builds, but which should be harmless in most cases. Anyway it's a better version, and optimized this time!

And after taking a closer look at that : finally it's more a very well done skeleton than anything else, I mean there are mistakes everywhere, I don't even understand where it got its roms from, there is no crc showed and I didn't find its names anywhere. So you must check and fix everything inside, but I still find one positive point to this : it produces some very nice code with lots of comments, it's rare to put so many comments in a driver even when trying to take some time to do things well. And there are some quite original approaches : instead of allocating the ram zones as usual, it declares them as some static arrays, it works, and you can even say that since the memory usage of these drivers is ridiculous compared to what we have in our machines now it can be used this way, but if every driver does that, it's going to make quite a lot of wasted memory in the end ! So it should be fixed too... Also there are some crazy parts in the original hardware, the byte read/writes of the 68000 are not directly connected to the ram as they should, so it can do a write byte to address 3 to send a byte to the sound z80 for example. All this part is totally ignored by this driver as it is, so all the complex part is still to do. But still, it's more than I expected, and it can be used as a starting point, even if there is a lot to do after that. Too bad, no magic here which would made drivers development easy!

If you are curious, I had a little more fun with claude, I asked for the english version of this source, committed it to git and then started to explain the changes needed to make it to compile, and it followed, even for the dipswitches which are *VERY* different from what there is in mame! You can see the latest version here, it's almost 100% from Claude, I only changed manually the MSG_xxx consts which were not defined, and left the undefined sound which helps this driver from compiling, but you get quite a beast already ! The only regret is that it doesn't remember all the explanations I just gave him, it's erased when the chat ends, so if ever I want to do more raine experiment with Claude, I'll have to re-explain everything, which took quite a while this time... Anyway final result here : https://github.com/zelurker/raine/blob/master/source/games/sega16.c Again it's still not a working driver, it's here just for info.

It's not a finished driver, he tells it in the description, he calls it a skeleton driver but it's more than that though, and there are mistakes to fix so you are supposed to understand this code to be able to use it, but I am quite impressed yeah. Claude is the best for coding questions from what I heard, I didn't expect it to succeed at such a question! There is still work to be done to make it a usable driver, but the start is often the most boring part, so it's already quite a feat! Maybe it could be used to make some modifications or add some clones or games to some existing drivers too.

Hey, with all the buzz around AI lately, and particularly around Claude for coding, I had the idea to ask it first if it would be able to write a raine driver, the answer was surprisingly yes, and it gave a long commented source as an example. So I pointed it to this thread, and asked him if he would be able to give a base driver for these games. And since this thing fears nothing, the answer was again yes, with a bold source to start the emulation for golden axe ! It's based on the mame source for the info but he made an impressive conversion work, even if there are a few small mistakes and it's still just a start, this kind of driver is very complex, but it's an impressive start nonetheless. I won't post his direct answer here because I asked in french so the answer was in french, with comments in french in the proposed source, but it's easy to get the same answer by asking the same questions. I did it from the AI interface built inside firefox, I had chosen Claude, basic connection using just my google account that's all.

No specific reason, I just never tried it, the goal of raine has never been to emulate everything, it's quite a lot of work usually even with some info from mame because we make things quite differently, so I was adding stuff only when I had some good dose of motivation, even if I played in the arcades these games a long time ago I never had the idea to try to add them to raine.

Yeah same thing I find these beat them all quite boring now, but I played them when they invented the style ! (but from the few minutes of video I saw they seem to replicate the game very closely, just changing the drawing of the sprites to make them more realistic but keeping everything else).

For the fans... : http://store.steampowered.com/app/3012220/

I made a quick picture on civitai to see what I could get on this theme, without describing the outfits because I assumed they would get their default outfits and finally they ended up inverted, Ryu in red and Ken in white. I guess it could be fixed with a more descriptive prompt.... Anyway that was just a quick experiment, I'd say they look a little too much like Mr muscle, but overall it's not too bad : Oh yeah the hadoken, the blue energy ball between them is quite a failure here... !

Actually I don't love fighting games, it's just that there are lots of fighting games in cps1 & cps2, but I don't love them ! I liked playing some very old fighting games a very long time ago against a friend on an atari st, and I played matmania with my cousin in the arcades too, but except that no, no love for fighting games sorry ! And no I won't buy an italian version sorry! I totally missed this dash story because I never had to handle these cps cartridges directly of course... thanks for the info !

I didn't even know what your "cps-dash" was ! You won't find any reference to dash in the raine cps drivers by the way. It's specific to sf2ce apparently anyway ? Some video chip at 12 MHz instead of the usual 10. Oh well... ! Yeah I think the main reason for cps2 was the sf2 bootlegs, apparently Capcom didn't appreciate that at all and wanted to get rid of all these before getting some cash from the sf2 success... it's a little pity all these fighting games in cps2, but there are good games in all categories anyway (except racing !).

Yeah I forgot about these hardware differences because I am too used to the emulated version where all this doesn't make a big difference, and there is no real difference in the driver for what can be accessed in the gfx banks. For the cpu, cps1 qsound was at 12 MHz, cps2 is indeed at 16, it's 1/3 more, so not so much. But anyway it's still right to say that cps2 is an improved cps1, so there can't be any real competition between the 2. It's very rare to see such a high frequency for the 68000 but they even used cps2 after 2000 ! It's not an easy driver, quite a lot of crazy stuff inside between these weird ports, the sprites which have 3 layouts sharing the same memory space, and the encryption of course, but at 1st I was only interested in cps1, to be able to compare to a very old cps1 emulator which was entirely written in assembly, I forgot its name, callus I think. cps2 came quite later, but since there were not so many differences between the 2 at the hardware level it would have been a shame not to add cps2. I guess it was not so easy to extend callus, and it never emulated cps2, and callus was closed source anyway. For the picture notice you can also get very good results using some AI these days, if they have been trained with your fictional characters you can get impressive results, and it shouldn't be hard to find some trained model for Ken and Ryu here. You just need to be very precise in the description of the picture you want... !

Nice picture ! I'd say it's hard to believe cps1 and cps2 share mostly the same hardware because usually there is quite a big difference graphically, so they probably improved the way they are making games quite a lot between cps1 and cps2, and this is the main difference, also cps2 uses qsound all the time when it's used only on a very few late cps1 games. You could say cps2 is a high end cps1, with encryption and the "suicide batteries" as they were called, not such problems in emulation but still... ! Anyway cps2 is just cps1 + encryption to make sure there would be no bootleg (and it worked !), and so they could spend more in it to have higher quality games. It's not the same for cps3 which is a completely different platform, nothing in common with cps1 or cps2 except the fact that it's from capcom !

Thanks !

You can also try to create a new user assuming this strange behavior is not the default on your system. From what you wrote you are limited to 70 fps, this seems to be the hard limit of your vsync. From memory because I have not seen these settings for quite some time, with the nvidia tool you can choose if this kind of thing can be chosen by the application (this is the default) or forced to a setting. Of course it should never be forced, otherwise you get this kind of thing. Actually I made some more tests here since I have a nvidia too and I can't reproduce your problem, the nvidia settings for double buffer are just ignored, the application always has priority. The only thing I can change from nvidia-setting is the glx information to display fps, I can enable this if I want. Not a problem for me, I prefer things to work this way, but it means I can't experiment with your problem so you are on your own here, but if you find how you did this exactly I am interested! For the numbers, if you are limited to 70 fps or so, it means an acceleration of about 1/6 for a 60 fps game, you would probably not notice the difference. Here when using this I reach a little more than 2000 fps on sf2 which means 33x faster, that's a little too much I must say, you can't be very precise at such a speed. And it's about the same speed when using the 64 bits C version and the 32 bits asm version (they are both above 2000 fps, the C version might be a little faster but at this level it's not sure!). I thought about limiting this turbo speed, but after all it's quite fun to go that fast, that's why the function is enabled only while the key is pressed, to be able to maintain it for only very short periods of time.