Tux

After some investigation, this address is a lot less interesting in windows than in linux. In linux all these asm functions go to the same area, which makes sense. In windows, following their motto "why make things easy when you can make them much more complex", they used multiple regions to store these functions, sometimes a region contains many functions, but sometimes only 1. You can get the address of the region using VirtualQuery, but after some tests I need 4 VirtualQuery calls (followed by 4 VirtualProtect calls) to get the same result as what I did here in 0.91.21 in a single VirtualProtect call, and in both cases I can't be sure I didn't forget anything ! So for now I'll keep the single VirtualProtect call, at least it's shorter ! I tested taito f3 (68020), matmania (6502), 68000 + z80 (neogeo/cps1/2), and dondokod for the rotating layer which also uses some asm code from memory. And thanks !

Ok captcomm fixed, it was a typo error, thanks for the info ! (and it didn't make it to 0.91.21 !)

Always the most recent version to use with the latest version, dates are displayed in format year/month/day beside the files so it shouldn't be that hard to guess... !

I'll look for the b1+b2 bad mapping, it's probably something stupid that nobody detected until now. For the assignment mess when you plug a new controller, well there are functions to simplify assigning a given controller to some inputs in sdl2, so if I fix that now, I'll have to redo it differently in sdl2, and really when I see how the windows version is getting broken lately, it would really be a good idea to get at least a basic sdl2 version working... So no promise, and it will probably get delayed then...

Tsss, shortly after 0.91.20, but big fixes again... The biggest one is about the 32 bits asm functions which suddenly started to crash in windows. I didn't know because I test in linux and wine doesn't care about the memory regions protections ! What probably happened is that this new protection came with the update of gcc, like what happened in linux. The difference is there is no /proc in windows, making things more messy. If someone knows how to get the base address of the region containing a given function, tell me ! For now I just used some rough approximation... Anyway normally all this asm code works again, assuming I didn't miss anything. The other big one is that I broke the init of all the neocd games in 0.91.20, sorry, it was easy to fix, but it made a lot of games unloadable ! And the last one is the return of the opengl blits : to fix the asm code I needed to test this in the real windows, and the gui is becoming almost unusable without this feature. So it's back, but this time it's optional, you can disable it in video options / Renderer options / Opengl blits. Like last time, it breaks emudx games and neogeo games using rasters, so it's not an ideal solution, but it's better than nothing, especially if you want fullscreen ! The real fix to that would be sdl2... ! They are enabled by default in windows, and it's saved in the configuration of course. And I also added some test before saving the neogeo backup ram because mine was probably saved at a bad time and it corrupted it. You'll see a warning if it detects it can't save the backup ram. Afaik, it happens only from the test mode. http://raine.1emulation.com/download/latest.html

These are rasters glitches, which are really hard to fix, and since I find these games uninteresting, motivation is super low... But this is open source, anybody can fix things and send patches, I'll accept them !

I was about to protest about the lack of details, but I was able to reproduce that very easily ! Yeah, it's because of a different way to call the same thing : for Musashi it's GetContext, for starscream it's SetContext !!! I made the mistake to try to simplify some piece of code and put GetContext for both, it can't be done ! Oh well... !!! It's a 1 line fix (3 actually because of the #if which goes with it), so I'll probably just make a new win32 binary for that... At least it shows that some people are still able to use the 32 bits binary in windows ! It's related to the neocd init, so it's likely that no neocd game will work with the current raine32 binary, I'll try to upload a new archive for that then... sorry ! Ok, you'll get a 0.91.21 for that tomorrow, which takes also back the opengl blits for windows but optional this time and enabled by default in windows, and it also add a verification before saving the neogeo backup ram... but it's too late to release now, going to bed !

Ok, after testing : the 32 bits versions crashes all the time, could be some new security feature related to asm. But even the 64 bits version is very fragile, when the game has started calling back the gui usually closes the program. Best results with 0.91.18, that is the last version which used the opengl gui (with the known limitations known that the emudx games don't work, and the neogeo games using rasters neither, but it's much better than this crashing disaster we had here !). Since even the 0.91.18 32 bits version crashes when loading a game it must be something related to rights executing asm code (self modifying code). I might have to investigate about this... Well try 0.91.18 64 bits, if you are willing to go with the limitations, I might make a 0.91.20 using the same tricks...

I love this precision : 32 or 64 bits, which romset for example, at which point ? cps1 or cps2 ? There is an option to disable speed hacks for neocd/neogeo, not for cps1/2, it wasn't necessary so far... It's obvious this kind of behavior is not normal and has not been found yet, there are 1070 romsets in raine if I remember correctly, plus I almost never play with it anymore except to code, and it's only in linux, so the chances to find what you are talking about by chance are more than slim ! If you saw this with the 64 bits version, the 1st thing to try is the 32 bits version, as said too many times already, the 64 bits version is still experimental even though it's working better than what I expected already, big bugs are still found in it, like what was found for 0.91.19. (and I almost only use the 32 bits version here !).

After some tests, in normal play the backup ram is "locked" at the end of each frame, meaning it can be saved or removed without problem. The only place I found where it's not the case is in the service mode ! Here the card is left unlocked, maybe it's how I saved mine at a wrong time. Anyway I added some test to prevent that, the emu now displays a message box to warn if the backup ram is still unlocked and refuses to save it in this case. I'll see how it goes, but it's probably better this way. I could fix the stuck backup ram manually by removing a duplicated entry, I just removed the 1st one, and it was back to normal again... The format is documented here : https://wiki.neogeodev.org/index.php?title=Backup_RAM (it was byteswapped when saved by raine, I changed that so that you can edit it more easily in a hex editor in this kind of case, it's able to read the byteswapped format of course but it will save differently now).

I had this happen lately : while testing irrmaze, it didn't have any soft dips, which is a bug, I think almost all the neogeo games have some softdips except some prototypes. The backup ram was full but it's supposed to rotate the games inside once it's full. For some reason, mine didn't rotate anything anymore. I might have done something wrong with it, some testing gone bad maybe, but the bios doesn't display any error for that, it's just that any new game can't create a new slot in the backup ram, and it had some consequences on the game play, it had some strange settings because of that, no instructions, no display of the credits at the bottom of the screen, but except that the game seemed to work fine. I don't know why the games didn't rotate anymore, I kept a backup of it for now. Fixing it is easy anyway, either delete the file savedata/neogeo.saveram, or go into the bios, hardware tests, when arriving at the stage where it tests the backup ram the unibios proposes to reset it if you press a+b+c, it's equivalent to deleting the file so it will be re-created next time. I just tested with a new backup ram, loaded more than 8 games, and this time they rotate normally... There is probably a bug somewhere, but for now I don't know exactly what happened... ! Maybe it's linked to switching from aes to mvs in the unibios, not sure, just an idea...

I found this in the mame source (which is still a good source of info usually... !) : /* special BIOS with trackball support, we only have one Irritating Maze bios and thats asia */ ROM_LOAD16_WORD_SWAP("236-bios.sp1", 0x00000, 0x020000, CRC(853e6b96) SHA1(de369cb4a7df147b55168fa7aaf0b98c753b735e) ) Lol, by looking better I realized that this bios is actually in my neogeo.zip file and already referenced in the bioses in raine as "irrmaze bios". I just tested it : for players there won't be much difference compared to what you get with the unibios for the games. The only actual difference is that the test mode really tests the paddle this time, you have to navigate the menus with the mouse, and it's in english, so usable. So it's a bios which should be used only with these 2 games then... ! I thought it was lost because I didn't find this bios in the mame I use for reference, but it might be because they treat this bios differently since it's for these 2 games only... My bad then but the rest of the infos are correct, the workaround for this is only in the unibios, the "standard" or official bioses don't reference this at all.

This is to address the bugs found by Augusto (some of them at least) : - fix burning fight and "fatal fury 3" in 64 bits - fix the inputs for irrmaze and popbounc : this is very specific to these games since they are the only neogeo games which can use a paddle. Originally there was a specific bios for these games, but in asian only and it's now unavailable. Unibios has a workaround built inside apparently, and so you'll need a version of unibios to run these games with the mouse (it might be possible to use popbounc with the joystick). For popbounc, you choose which input to use with the soft dips, you can change this in real time in the raine dialog for that, in "neo-cd/neo-geo options" once the game is loaded. Tested only with unibios 3.2 and 4.0, works with both, mouse is not recognized with the standard european mvs vers 2 bios. Hum, don't try to move the mouse while the game is initializing... ! - added some basic setting to slow down the modern mice ! You can configure that in the inputs dialog, the setting is saved when you quit raine (with the quit command as usual, closing the program by any other mean doesn't save the config). It can only be slowed down, modern mouses are already too fast for the low resolution of these games. This setting should be used by all the games using the mouse of course... - a few misc fixes, like the break console command which didn't work anymore with starscream - recent versions of curl forbid spaces in the urls so I had to work around that, this fix is useful only for linux, I didn't update curl for the windows version. http://raine.1emulation.com/download/latest.html

For popbounc, it's the same problem as irrmaze, it's related to the paddle, afaik these are the only 2 games using this. I had tested irrmaze a very long time ago, and never noticed it had a problem when using the unibios... oh well, I guess this one is interesting too then, I'll look into it later, thanks for the info... edit : after looking, yeah it's a crazy piece of software, especially for irrmaze : it's supposed to use a specific bios to handle its paddle, except the bios has disappeared, and it existed only in an asian version anyway. The paddle is mapped in the memory area of the standard controls (stick + buttons -> paddle). Which means that the test mode for this game actually tests the neogeo standard inputs and not the paddle, it would require its specific bios for that ! It can be worked around though, just don't move the mouse while the game initializes. It's quite a crazy game too anyway, you have to move this ball in a maze with an ultra sensitive control (maybe it's because our mouses have a too high resolution now... ! I should maybe try to find a way to scale that...). Anyway it's fixed here, but you need a new binary for that. Pop'n bounce is a more modern game using this, it's using a soft dip setting to decide if it uses a paddle or the standard inputs. You can change the setting in real time while playing using the raine soft dips dialog and it works, the mouse activates when you choose the paddle setting. Here again the mouse is very sensitive, and you need the new binary for it to work. So I'll take more time to see if things can be improved at least a little... edit again : I added some basic setting for the mouse sensitivity. I am not sure it makes things really easier, but it gives the impression it's easier, and it's fun to configure (from the inputs dialog of course), so I'll keep it for now, it's usable in all the games using the mouse of course... For the 32 bits/64 bits version : well you should know that raine has always been full of assembler code, and this code can work only in 32 bits. So this version is of course more tested and more reliable. The 64 bits version works quite well most of the time, but you can still find problem in it as you discovered, but I didn't expect to work that well for most games anyway.

Try the 32 bits version, why does everyone prefer the 64 bits version ? As it is, raine true version is the 32 bits one, the 64 bits one was made so that it can continue to be used on non intel architectures. Anyway tested only for burningf, but the problem seems to happen only with the 64 bits version. Sorry but I lost all interest for this for now, it's enough for me to know that the 32 bits version works, I might eventually have a look at why this stupid 64 bits version has a problem here, but it won't be now. I took the time to investigate the crashes for burning fight and fatal fury 3, both were due to oddities with musashi, so in 64 bits only. They are fixed in git, I might make a binary later... or not, just use the 32 bit version for now, it's fixed in the source that's good for now. Didn't look into your graphic issues, sorry not interested for now !

My bad, yeah you have to choose, either the dpad or the stick, but not both at the same time, yeah I know, life is hard... !

Nowhere. You can try to grab the .xz file, it's just a tar, use tar xvfJ to extract it, and try to run the binary inside (it's intended to be extracted at the root of the fs). You might be lucky, otherwise, compilation, or wine !

Yeah but it's still quite simple in the way it works, a lot happens in 1 frame though, but there are very separated parts and most of them never change now (except when trying to change the underlying lib, sdl !). You can still compile raine with only 1 driver inside, you can even decide you don't want the console (and the cheats which come with it now) to make an even smaller binary, then you take only the cpu cores you need... you can still make a very tiny raine (and it's easy to do if you know how to compile it, there are scripts to make that very easy if you have perl installed). Anyway...

Yeah well I don't intend to learn italian just to be able to read it !

The region is just initialized after the 1st loading sequence, so if you have loading animations you must wait for the end of the 1st sequence for that. Before that there is not even a Region displayed in the menu... anyway !

Well I don't know what you're doing wrong, I just downloaded nam-1975 neocd to be sure, no problem here, the config you are showing shows japan as the selected region, I tested it shows indeed Japan as the region while playing and you see the Japanese chars, even if you quit and reload, end of the problem for me, be sure to use the latest version.

Thanks for the tip, I'll give it a try, yeah browser extensions are multi-os but not always multi-browser. Mine had problems with some sites, this one seems more polished, so I'll happily test it, thanks !

Hum, zzap is still alive on this site anyway, it was part of the backup, and I still have a backup here, and I think you should have another one on your side, so it won't disappear anyway ! But it looks nice !

Which was originally a separate emulator by MikeDx (Mike Green in real life), I just thought it was too bad to let it disappear at the time and I proposed him to merge it in raine, and he accepted... Everything is not perfect, but at least it runs on modern hardware in any resolution using opengl ! Mammoth project if you look at the big picture, but raine is still quite simple in the way it works, even if it got bigger along the years. But yeah there are some complex parts allright, but it adds to the fun ! Anyway glad you liked it !

Eh, I don't have that much to say about all that... in fact I am surprised I lasted so long, well along the years many times I thought about giving up and sometimes I spent months without touching the code, but I always finished by coming back to it. Now I play less and less with raine, so it's really time to finish this, that's all, but it was good while it lasted for sure !