Tux

I just rebooted win10 to test this, no problem here.. Tell us if you find what's wrong... Corrupted rom ? Although I don't know any way a corrupted rom could freeze like that, usually it's a very fast error message... Good luck anyway !

Yes, 0.93 was for gauntlet in case you didn't know, and finally the 32 bits and the 64 bits version work, actually the 32 bits version even has the attract mode sounds working, which even mame has not, but this game is crazily programmed anyway, and there's no reason to be proud of that. I am not 100% sure everything works because I only tested in single player, but afaik gauntlet 1 & 2 are both working, the code is slightly different from what there was in this famous mge since I use the old excellent slapstick emulation from mame, and I am still not 100% sure it will work everywhere, but it should be good normally. Except that a few interesting changes : - finally fixed the annoying black zone which appeared when jumping in some super street fighter 2 games in cps2 drivers. The reason was again the cps2 rasters, it allowed me to fix a few bugs in the previous emulation. I didn't retest the other places using rasters, I'll just hope for the best ! - Also since most of these cps2 games used finally a 4:3 screen despite their 16:9 resolution, there is now the option to display them in 4:3, see the new "fix aspect ratio to 4:3" option in renderer options for opengl, it has now a new option "always" to force any game to 4:3. This is discussed in detail in the 0.93.1 thread here. - A fix when loading some games in the same session, like multi pang after super pang, it was because of something badly done when adding the new sound chips recently, it probably affected quite a few games, not these 2 only. - Some cheats had some serious syntax error, finding a variable which didn't exist and displaying the error message in a loop. The conversion was updated, and the cheats fixed (at least those I could detect). - For those using the "controller mapping", I had forgotten the case when more than 1 controller is using these special mappings, it's fixed. - And fixed a weird bug when trying to run the windows version of raine in wine. You can get this there : http://raine.1emulation.com/download/latest.html

There's nothing wrong or right about that, it's more a question of taste, some people love to fill the black border of a 4:3 picture on a 16:9 screen even if it kills the ratio, it doesn't change anything for the emulation, it's comparable to these buttons behind the cabinet to stretch the picture. Eventually you could try to get the same conditions as for the original arcade cabinet, but it's hard to get the information of the screen size for all of them. I got it for ssft2, I confirm this one is 4:3, and 1944 too (although 1944 looks very good in 16:9 in my opinion !). From memory the one I saw using a 16:9 screen was a marvel super heroes game, not sure which one though, it was in London, and it was quite a long time ago already... ! Actually ssft2 displayed in 16:9 reminds me of "super gem fighters" from capcom too, they just increased the "flat" effect for super gem fighters ! Maybe there is something more to learn about that, because standard resolution in these days was more like 320x224 or 320x240, that is a solid 4:3 resolution, 384x224 like here is quite far from that, so even if it can be displayed fine on a 4:3 screen, they probably choose such a resolution because they thought about using some 16:9 screens... but I don't know anything about that, just guessing. Anyway adding that is probably a good idea, it's quite astonishing the difference it can make. This function could make some games look ridiculous, if you use it on those ultra wide games like darius or darius2, it will look ridiculous. Well it's just a message which was printed on the console by the original program (if you have a console, so I guess you missed it completely in windows !). They did it like that, I didn't change anything about it, it's better to see it, even if you see a part of it, you can always resize your window, you can even do it while the message box is displayed, but I think it won't display more characters if you do it while it's already displayed ! You can try that, min font size setting is for that, but if you put that too low it will become quite unreadable, and it's useless since you can simply switch to a higher resolution. Ok, ok, just did it, it's funny how you are sensible to this kind of detail... ! Good to know !

For super pang / mighty pang, it's not that specific, it's because it had been so long since I added some new sound chips that I forgot a part of it, an order of things which must be maintained, otherwise you get this kind of crash. At least it's easy to fix ! For avsp, for me it's the same, at least compared to mame 232, the only difference being that the key file is not required in raine since it's in the source, and anyway if your rom is bad you can let raine get it from the internet archive !

Yeah well my git log starts in 2009, and there is a gap of a few years when I didn't use any source control tool, so I couldn't answer better than that. 2004 you say ? Quite old, but it didn't get a lot of love in all these years though ! (even the change I thought about for dkong, finally I gave it up for now).

I didn't find this specific problem yet, but I found 2 other issues : some problems with some cheats in this game which trigger an error about an unknown variable, it's a conversion error from the xml original, it's fixed for the games which could be affected (quite a few). And I suddenly realized that despite this game has a resolution very close to a 16:9 one (384x224), it was actually displayed on a 4:3 screen... So I changed the "fix aspect ratio to 4:3" option which was only yes or no before, yes fixing the ratio to 4:3 when it was very close to 4:3, now it's "no", "close" (which is the yes from before), and "always" which forces the aspect ratio to 4:3 no matter what. It's right that the display is better for this game using a 4:3 ratio, I didn't notice because I almost never play this... ! It's not the case for all the cps2 games though, I remember seeing a machine using a big 16:9 screen once. And actually this option didn't really work at least for the sdl2 version, but maybe it had been broken for longer than that, nobody noticed because the correction was very light before, now you really see it in action when it forces this game to 4:3... Anyway... !

Yeah when you see a "a" at the end of the version number it's that I forgot something at the very last minute, this time it was a new bitmap for the window big icon, which is actually rarely used, it's a blue bub from bubble and bobble with just more resolution, even if you almost never see it, it's nice to have it !

Well I had to redownload this to test, no problem here. Try the version from gametronik, a little long to download though, the audio tracks are in wav, I converted them to ogg once downloaded and tested, start 1, default character, story mode, won the 1st fight, stopped here.

Very likely yeah, to finish the description, it happens only when the player jumps, and only on certain stages. AFAIK, it's been here for years, but I must admit I had even forgotten this one. I might look at it one day, but not now... anyway anybody can try to fix it too !

afaik there is not even any samsho4 sp, I know a samurai shodown V special which I just tested and which works, but no samsho4 sp in arcade rom or neocd... !

I just took the time to investigate, it was just a draw far from the normal coordinates, this shouldn't matter normally, it's some 3d, not 2d, but anyway to begin with this shouldn't have drawn at these coordinates. Fixing this (just 1 line) fixes the problem, you'll get the fix in the next release.

Yeah I noticed that, it's specific to wine & sdl2-2.0.20, don't know why exactly I didn't investigate, but since it works fine in a real windows, I didn't bother. Good to know that downgrading sdl fixes the problem, yes you can use it without problem, it's supposed to be just a bug fix, I wonder what change triggered this... ! Here is the sdl 2.0.20 news : General: * SDL_RenderGeometryRaw() takes a pointer to SDL_Color, not int. You can cast color data in SDL_PIXELFORMAT_RGBA32 format (SDL_PIXELFORMAT_ABGR8888 on little endian systems) for this parameter. (not used in raine) * Improved accuracy of horizontal and vertical line drawing when using OpenGL or OpenGLES * Added the hint SDL_HINT_RENDER_LINE_METHOD to control the method of line drawing used, to select speed, correctness, and compatibility. Windows: * Fixed size of custom cursors Linux: * Fixed hotplug controller detection, broken in 2.0.18

- gauntlet finally works with starscream (you'll get 4 welcome when you start the game, but after that everything seems fine). Gauntlet 2 doesn't work though (with starscream), still some problems with the slapstick there... (it means it works in the 32 bits version !). - fix for timers badly saved in savegames made with the optimized builds ! This one was quite a surprise, and it's suprising nobody noticed before that, but anyway. You got a strange warning about a bad id in the savegame with previous version, for all the games which used timers, and there are quite a few. (I didn't notice because it happens only on optimized builds, and I use a debug build most of the time !). - Finally merged the controllermap program from sdl2 inside raine ! It's because of the findings from mer-curious. Anyway most people shouldn't need this, it's in case where your game controller doesn't behave normally at all, as a last resort. You can try it by curiosity if you want... ! The command is in the inputs menu, "Controller mapping", and it saves its settings in config/userdb.txt. By the way I could only test this with a controller which was already recognized as a game controller, for those who have a beast which isn't even recognized as such, you might have to quit raine and restart it after using this so that it reads the new gamecontroller configuration. I can't test all the possibilities here... ! http://raine.1emulation.com/download/latest.html

The idea is to allow to edit a mapping, either from scratch or to overwrite an existing one, and save it to a different file which would have priority on the old one. Now I wonder if it's not overkill... I think most people probably have some standard gamepad coming from a console, which is recognized directly, that's this weird adapter which caused trouble here ! So I still wonder if it's not too much to merge the mapping program, it would probably create its own window to create the mapping... I'll think about it...

No, I don't know what they used there, but no matter. It just means that I should merge the capability to edit these mappings directly in raine, I had hesitated to do that and it seemed useless, and you are the one who finds a pad with a super weird configuration where it becomes useful ! I'll try to do that then... What happens then, it doesn't detect anything when you move the direction stick or what ? (just for info)

I remember one from emufrance, in french then, so I'll probably not link it from here Ok, I'll try that... Try to feed it to raine then and see what happens (your mapping). Notice here is already a mapping in gamecontrollerdb.txt with the same identification for windows, I guess it's because of your usb adapter which can take a few different pads ? Well to test yours find the line containing the identification (03000000250900000017000000000000) and replace it by your line. Save launch raine, and see what happens. It's confirmed by the log file, it's identified as a game controller (Joypad to USB Adapter), they changed the name, or maybe it's because with a different pad plugged to that it works differently. I'd say there's probably a better way to use a sega saturn controller here, it's not normal that moving into a direction activates a button, but you might make it work with this mapping.

Lol, there is one very outdated, I hate writing docs. I did that at a time because I had found some fancy program for that, but finally I got bored doing too once more. Anyway the basic concepts didn't change, so for those who don't know arcade emulation there can still be some useful info in it. If anyone wants to do it, he's welcome to... there are some sites which built some info page for raine, some rather well done I must say ! Hum, not sure where to put that anyway, but it's not a bad idea. Yeah maybe... Wow, what a weird controller, I wish I could test this one directly to see how it works ! For the improved diagonal, don't hope too much, the games need to be programmed specifically to use this efficiently, here the games are still these old arcade games with 4 directions joysticks only ! It's surprising that it works in the sdl1.2 version and not this one though. Is it recognized as a controller (well it won't be easy to say if you don't see the directions)... Well raine prints which controllers it finds when you launch it, so try to launch it from a command prompt and redirect its output to a file : raine > log then quit and look inside the log file, not sure it will work, but it should. Do you still have the testgamecontroller program ?

For the keyboard (esc) and gamepad (button 2 which is usually B on xbox pads and O on playstation, it's quite intuitive... Exactly, actually that's me who inserts these spaces, I learnt to type this way, and I type very fast, so I don't try to change it... ! Yeah you are right, but most people keep the same old config from version to version, so it's always a problem to change the config name. By the way in dos it's raine.cfg, in linux rainex_sdl.cfg, and windows is historically raine32_sdl.cfg because the 1st version for windows was by Atani a very long time ago and he called it Raine32, so I kept the name since then for the windows version, just changed it back to raine.exe for the 64 bits version because it wouldn't have made much sense here... It's niice getting some feedback anyway !

You are really paranoid about that, I already explained in the other message that I just updated SDL2.dll in the dlls package, this is exactly the same file now, I simply packed it in the 0.93 release so that people don't have to redownload the whole dlls package just to update sdl that's all. There is always an universal cancel which works everywhere in the gui, that's ESC on the keyboard or right button on the mouse, or what is usually button 2 on a gamepad, I thought you knew this after all this time... At this level there are only joystick indexes, raine does not know if it's affected to any player or not, and you could even affect only some of the inputs to 1 player for what it knows, so I can't do that. This dialog is just intended for someone wants to use a particular joystick and doesn't want to reaffect all the inputs, then go to this dialog and swap its position with another one. You see these indexes in use in the inputs dialog, either for default or custom inputs, you see the joy inputs appear as "joy n (name) button or stick", n is the joystick index in use here. Glad to see you were not able to find any outstanding bug this time anyway, at least things are improving !

Of course you can test that, the update is a minor one, 2.0.20 is mainly a bug fix release, even if you remove the new dll and use the old one it will most probably work. I plan to just put the new SDL2.dll in the old dlls package later. edit : done ! This release as all the others was simply made to be unpacked over an old one, replacing files. Of course if you install it in a new dir it's a little awkward if you unpack the dlls package after it, but anyway it doesn't matter, it should be compatible. I just replaced the dlls in the 92x packages, but I didn't retest any 0.92 version, it should work anyway.

Ok, don't do that, there are 2 shells, it builds depending on the shell you are running, if it's mingw32 it tries to build a 32 bits binary if it's mingw64, it's a 64 bits binary. But anyway I found a forgotten -lSDL_sound, just committed the change now, use git pull to update the makefile. I didn't notice it earlier because the lib doesn't even appear in ldd in the resulting binary, and I have a SDL_sound lib in my path so it's working here. I needed someone to test this in real mingw32 to find it, sorry for the problem and thanks for trying this !

You forgot to tell how you did that, what you try to build... it seems to be in mingw32 ? Well normally there is no SDL_sound, it was merged inside for SDL2. But you might have found an old place in the makefile where it's still used... I'll check in mingw32... Ok, after checking there is something you did obviously wrong here, but I don't know what it is. Did you check the short guide on how to compile ? It's there : http://raine.1emulation.com/download/install.html Normally from mingw32/mingw64 native, you don't need to edit the makefile at all, just git pull to update the source, eventually edit it if you want a debug build, and that's all, just make. Here your try to use x86_64-w64-mingw32-gcc as gcc, did you try to uncomment 1 of the targets ? It's useless in mingw, it autodetects what you are trying to build from your environment, and adjusts, these targets are useful only when you crosscompile and it can't guess, usually from linux.

Ok, particular version since it adds 3 gauntlets games (the main one, the spanish version which doesn't speak spanish so it's not really interesting, and the 2) which work perfectly with the C cpu cores (64 bits version), but not well at all with the asm cpu cores (32 bits). I might return to that with new ideas later, but since the changes are already becoming quite big, it was probably a good time to release this. These games are really a playground for hackers with all the crazy stuff inside, I might play more later then... ! About the games themselves, these are really multiplayer games, you can test this in solo, but you won't get far. By the way, big thanks to the advancmame team which maintained an old version of mame which can still be compiled nowdays, I used this for testing stuff while trying to understand how things worked, very convenient... Again the new games can be played only in 64 bits, they can be launched in 32 bits, but don't complain if there are problems ! They were some big beasts finally, adding 2 new sound chips + the slapstic support. Ah also despite the original hardware having a 68010, I found they work very well with a 68000 only, so I left the 68000, it's easier. You'll notice the binaries are 1 Mb bigger than usual, that's because they contain an update to sdl2 (I'll update the dlls package later), the updated history.dat file (which won't be in all releases but this time it was updated with the new games info). There are also some new cheats for the new games but these are small. Except that, a lot of fixes as usual, this version is smarter with internet archive so it's able to get its files from more directories so it's already able to get the gauntlet roms and the updated toaplan2 ones. It also removes the ssl verification which gave me an error when I tested this in windows (I wonder if it ever worked in windows, I don't think I tested this in windows ?). Other fixes for the ksystem games which were still trying 8bpp functions (kikikai, knightb and kicknrun, very old games too), for toaplan2 (there was a high probability of crash if loading more than 1 toaplan2 game in the same session), the gui (mouse wheel support was not perfect), the console (basic support for the 6502 which also allows to use cheats for games using only some 6502, never noticed they didn't work before, too many things to test, really... ! And some fix for the 68000 breakpoints too). That's all ? Yeah I think... Ah I had a problem when testing the windows binaries in wine, but they work well in my native windows 10, so I released them anyway, I'll make some more tests with wine later. And the linux binaries will be updated soon too... http://raine.1emulation.com/download/latest.html edit : for the linux binaries there was an update to muparser in arch just now, my 64 bits version is now 2.3.3 while the 32 bits version is still 2.3.2 ! So well the 32 bits version can't be compiled for now, I'll fix that tomorrow. edit 2 : finally I updated my 32 bits libmuparser manually so that I can compile this. The pkgbuild and the archive are posted, but you won't be able to compile this on your side without muparser-2.3.3 in 32 bits ! You can use the archive though (.tar.xz), should be binary compatible with 2.3.2.

I forgot to mention that joystick indexes appears only if 2 joysticks/gamepads at least are connected, but anyway... Well I just found a story about some people who are like you, but on windows 10 with a logitech gamepad : https://answers.microsoft.com/en-us/windows/forum/all/logitech-gamepad-f310-not-detected/4f8d2803-8d79-426c-b769-70d330821ecb What a wonderful os windows is, really... ! I am afraid I can't help you more, there might be a way by upgrading something on your xp, but I am no xp expert, I can't guess here.

Things you can try anyway : after loading a game go to inputs / edit default game inputs, do you see a gamepad in the 2nd column, if so you can probably customize it ? Also after loading a game, have you the command "joystick indexes" in the inputs menu ? If so, it should list your detected joysticks/gamepads. If you see nothing there, it means they are not even detected, in this case it's a lost cause, nothing to be done. xp support is experimental now, it's really becoming too old. There are better alternatives for old computers, like linux, which can run well on old computers and which is always updated !