Tux

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.

Err maybe you could have reduced the amount of text here... ? Anyway it's fixed in git, it's just the parameter of the callback to remove, it's useless, never been used, it's some code from mame and in mame they pass a parameter here. We don't. It's fixed in git, so if you update your git repo it will be fixed. I guess you might need an updated PKGBUILD file if you don't update your git repo by yourself... ! edit : updated the PKGBUILD files, 0.97.5c for the 64 bits, 0.97.5d for the 32 bits because there was yet another incompatible pointer type in the z80 asm core used by the 32 bits version. These are minor problems except they are making all the compilations of all previous versions to fail now ! Oh well... and in the meantime since last binary release wml had become incompatible so I had to update this too... ! Anyway everything updated and working now.

Nope, I do it regularly in linux. Well sorry, it means something in your config breaks it, I can't guess what it is. After looking a little at the code for memory, this key has a very simple function : it just disables the opengl double buffer so that the game doesn't wait anymore on vsync. If you are using the sdl driver instead of opengl, it does the equivalent by calling the corresponding function. Anyway I know you can force these vsync setting if messing with the nvidia control panel settings. If you did that or something equivalent, I can't do anything for you. But anyway it just means something on your system prevents the double buffer from being disabled, I can't guess what !

del key by default ! (but it's quite raw, and depending on your configuration it can be extremely fast sometimes !). while the key is down, turbo is active, it's more a turbo than a fast forward, it just removes all speed limits while the key is pressed.

Nope sorry, no pi here, so no pi version from me !

Yeah nothing major this time, it's more because a few things were committed to git this week to finish properly stuff in 0.97.5, and since there's nothing in the works for now it's better to release some new binaries now rather than wait an indefinite amount of time... So the changes : - Add a configuration for the joysticks dead zones in the inputs dialog, all joysticks share the same setting, don't complain since arcade joysticks don't use precise placement, it's just up left down right and center that's all. - cheat dialog: fix bug when text for the status bar is too long to fit on the screen normally the bar flashes and you can click on it to get the full text. Except the click has been broken since the transition to sdl2 ! At least this feature is not used often, which is not a surprise. - new region switches for xmvsf, mvsc, hsf2 - mshvsf: Enable "Norimaru" for all regions. It's an extra character which was reserved for Japan only previously, but it didn't make much sense to keep it only for Japan after adding a region switch to this rom. - And ffman1985 produced a new console script for sf2hfj. That's all, and this time it should be the last release for quite a while ! AppImage files updated too by the way, since sdl was updated it was too bad not to include the updated version... I didn't update the sdl2 dll in the dlls package for windows, you can grab the updated version directly from github if you are interested, but it's really about minor fixes inside, nothing major. win64 dll: https://github.com/libsdl-org/SDL/releases/download/release-2.32.2/SDL2-2.32.2-win32-x64.zip win32 dll: https://github.com/libsdl-org/SDL/releases/download/release-2.32.2/SDL2-2.32.2-win32-x86.zip I didn't even update the version number, but you can check the date of the binary either in the archives or in the about dialog, compiled a few minutes ago!

Done in git, notice that dead zones are not really necessary afaik in linux, at least all the joysticks I could test don't return anything when the joy is at its default position, which is the expected behavior but it means no dead zone necessary, but that's not what happens in windows at all ! That's why I added this big dead zone... At least this way people will be able to fine tune this... ! It's in the inputs dialog, like mouse sensitivity, same principle, a slider.

Well the time of cfg editing was mainly for the dos version, where adding an option to the gui was a nightmare. A good point of the sdl & sdl2 version is that the gui is redone, and it's much easier to add stuff, so no cfg editing required anymore. Well I guess I could add something for the crazy guys like you... !

Yes it has, I remind you that I built the 2 appimage with distributions based on this ubuntu ! As mentioned in the downloads page for the i386 appimage: dpkg --add-architecture i386 followed by apt-get update apt-get install libgl1:i386 libpulse0:i386 After that you should be able to use the i386 appimage!