Tux

Yeah dependent on blend files, and it's normal the blend files just affect some transparency to some sprites, if the sprites are used more than once you run this kind of risk, and it's clearly the case here.

Are u sure there's something wrong ? Maybe it's just a way to make sure the subtitles stay readable even with a white background ! It's not the blend files, they add transparency for some sprites, that's all, they wouldn't hide anything. Hum, there is a slight change in the intro when disabling the blend files, you can just rename the directory to do that fast, or there is an option in the gui to disable them. I am not convinced your save states show a real bug though... By the way did you know save states are also dependent on the bios used apparently ? Using the universal bios 4 with them creates a crash on the 1st one, the 3.2 version or the old europe bios both work. Anyway... !

It's fixed, but I forgot do do it before the release, it's very minor anyway, just a typo error which was unnoticed for very long, the update is done but it doesn't show in the dialog, you can just exit from the dialog then call it again and the input will show. It will be in next release. And the change for associations is in 0.91.1 of course !

I just posted 0.91.1. Since last night : - lots of hex numbers were not identified in the cheats conversion from the xml, much better now (particularly for the masks) - cheats using watches with loops inside are now supported ! - you could not disable sound, not sure if it was for all drivers but probably. Setting emulate sound = no and then going back to the game was reseting this to yes ! I guess nobody tried to disable the sound for a very long time ! It's fixed, but notice that some games don't like to have sound disabled and you can get errors if you try to do that (in neogeo for example, you get a nice error about the z80 !). That's quite a lot of fixes, oh well the conversion was huge, I couldn't hope to have everything right in 1 go, let's just hope it's closer to perfect now ! Still the same link : http://raine.1emulation.com/download/latest.html

Thanks for the good news, I'll try to have a look at this gui stuff before releasing 0.91.1, it must be minor...

Hey thanks for the info, I use arch too and didn't even think about checking raine package in aur ! It's a little outdated, still using 0.64.16 here, but I didn't tag git for 0.91 yet, and there are big changes in the way it's built for 0.90 so it's no big surprise. Well I'd say it's probably a build problem actually there since as you say the windows version works well here, if it was only neocd I would say a problem with sdl_sound, but since there is neogeo also in it, I am not sure... Eventually drop a message to the maintainer of the package and you can tell him to post here if he needs. (I'd like to give a link to the aur package on the download package, but I'll avoid to do that if it crashes on things like that... I'll eventually try it, but it's an optimized build without debug symbols so it's hard to guess what went wrong here.) edit : I tested it, and I confirm the crash, I would say it seems linked to the sound, but not sure without a debug build, there is no message to see, just a crash as soon as the game tries to emit a sound (after the neogeo bios logo). I'd say rebuild in debug mode and run it from gdb, but here you can't do that with that binary, post to the maintainer then... I can ony confirm it shouldn't happen. edit 2 : found the cause, I looked into the build directory, it's just that he forces an optimization for "generic" cpus, and apparently there is something there not appreciated in the build. Actually this file is forced to pentium3 in git since 2016... and it was even in the source archive he used, I checked. He used x86_64, which is not a good idea, 0.64.16 is 32 bits only ! Anyway he should just have used the default cpuinfo instead of trying to change it. I can attach the fixed binary to this post, but you should really send a message to the maintainer... and he is behind by quite a few builds already, this 0.64.16 is from december 2018 ! More than 1 year late. Oh well I will give you instructions on how to fix it rather than attach the binary : just go to the directory where you have the PKGBUILD and all the other files, type : cd src/raine-0.64.16 edit the cpuinfo file so that it should be like this : _MARCH=-march=pentium3 -mtune=pentium3 CPU=pentium3 then type make clean make -j8 (-j followed by your number of cores). It will make a new binary, now just copy the raine binary you will get to /usr/bin, you are done. Or alternatively you can edit the PKGBUILD file, and remove these 3 lines : # 'detect-cpu' script does not recognize most recent cpus, use generic optimizing echo "_MARCH=-march=${CARCH/x86_64/x86-64} -mtune=generic" > cpuinfo echo "CPU=generic" >> cpuinfo then save, and delete the pkg and src directory and the xz file, re-run makepkg -si and it should be ok this time !

And quite a few bugs found again (related to cheats of course). 0.91.1 is under way... probably tomorrow ! The biggest one : "Set" cheats were running continually instead of just once ! And the watch cheats were forgotten in the conversion, the result did nothing simply (those which display something instead of changing it). And a few errors with hex numbers in some cheats. And don't try anymore to load cheats from the parent for clones, we now have all cheats, and when a clone has none it's probably not a good idea to try those of the parent, for example : pacman25, the invicibility cheat has a surprising effect ! And a bug when reading scripts which did not finish with an empty line, it often produced a crash when trying to activate the last cheat of the list ! 0.91.1 should be much better, but I prefer to do that in the morning !

Ok, I finally had an idea, if you used too often save and load, it's possible you saved or loaded in the middle of a sound command, the z80 accepts commands on more than 1 byte often. So I added something to save the status of the sound command now. The bad news is I can't do anything about your saves, they don't have this status saved, and I can't do anything about it. You'll just have to test again and see how it works... It's not even guaranteed to be better, I am not sure to perfectly emulate what the z80 does with these associations, maybe there's something I missed there, but since I don't have all the sound commands you received I can't do more about it. So here is the binary only, based on 0.91, test if you can and report ! raine-assoc.7z

Yeah yeah I know, 0.90 was supposed to be the last, but there was this mistake about cheats where I forgot the very old cheats.cfg file before realizing it was incredibly outdated... So here is 0.91, with the xml cheats from mame converted for the raine games. The cheats are included in the binary archives of the emulators, which makes them somewhat bigger (2.2 and 2.4 Mb, which is still very small for archives nowdays !). So thanks go to puggsy and his team for the work around this, I know how long it is to find cheats at least ! I picked the colors idea from them too, I found nice to have off in red and on in green for the cheats interface ! Except that when a cheat needs a parameter, it opens its own dialog which makes a huge difference from what we had before. There are tons of new cheats, some improve the playability of the game, try those around arkatour, or any arkanoid clone, there is one to choose the ball speed and prevent it from accelerating ever again after that, very useful to train, and you can even choose that you don't loose if you loose the ball ! (which is really the ultimate cheat in this kind of game !). The cheats are in the scripts directory. The neocd games use cheats from the scripts/neocd directory if there are some, but since there are very few there, they use those in scripts/raine if there is nothing. Some games have a different memory map in neocd, but those interested will have to test. The conversion from xml was made by a perl script, it's in the sources in git (bonus directory). I think that's all there is to say about this one, have fun ! Oh yeah, a link to the download page can help since there is no icon around the forum for that : http://raine.1emulation.com/download/latest.html Oh, and there is no cheats.cfg file or neocheats.cfg file anymore because they are not needed anymore ! And I can't guarantee all the cheats will work, because I couldn't possibly test everything, but I can promise most of them will work... !

Well the 1st still points to track 22 (the file, because it's not sound command 22), except that the z80 receives a command to stop the music as soon as the save is loaded, no idea why. The 2nd is muted for I don't know which reason, that is the virtual cd audio which serves for playing these audio tracks and which is saved in the savegame has its status which says "do nothing", which it does very well, so I her nothing here too. And for the 3rd I didn't have the mapping and didn't try to add it, so nothing also here for me. At least I don't have the "many tracks playing at the same time" that you seemed to experience. I wonder if you didn't hit some kind of buffer overlow by loading/saving too much ? Normally it shouldn't happen, but there seems to be a problem somewhere, and for what I can tell it works very well in a "normal situation" : tried to save during the intro sequence, it reloads perfectly with music playing exactly where it was when saved. I think I'll try to keep this a little more, maybe do a few tests to see if I can hit a buffer overflow, but not sure. I am ready to release the cheats at least, quite huge, but it's not an emergency at this point ! After testing some more : no idea how you broke the restoration, if you find something more about that I am interested, but meanwhile I think I'll release 0.91 with all its new cheats !

it sounds like a problem with the music associations when saved, strange that you didn't notice that earlier, I'll try to look into that later, for now I am quite busy with the cheats, plus your saves are for the 64 bits version, and my debug build is always 32 bits because it's way faster when not optimized...

It's not because of you, but I just converted the mame cheats for raine, which makes a huge update to the cheats ! The reason is more because I forgot the cheats.cfg file in the 0.90 version and I realized it's totally outdated and should be replaced by scripts. So I started to convert it to scripts, but then I realized a few cheats had disappeared for some games and quite a lot of games were without cheats, so I started to look at the xml base in mame, and good surprise, it's some nice xml readable by humans for once ! And in fact the scripts allow to execute all this quite easily if it's converted first to the right format, what I did then... It's an old story, originally the cheats were maintained by Stephh from the ultimate patchers, but he slowly gave up everything about that, and I was too busy elsewhere to realize the cheats needed some big update... Anyway it's done now, it will make a nicer last version ! Still a few clean ups to make, and I'll try not to forget anything this time so it will take a few more days ! Thanks to the covid then, it gave me plenty of time to do this !

Didn't know that, and it's windows specific of course, no idea why it happens for now... Edit : it's fixed, it's just that this options menu is dynamic and had grown too much, in linux there happened to be an empty region after it so you didn't see anything, not in windows and so you saw the next menu : about. It's fixed and there is a safeguard in place to be sure it will never happen again ! Because for gui lovers game options / load and save game is enough, here you do that in 1 click. I don't see the point in selecting a save state with the gui if it's to use it with the keyboard afterward. By the way the save is for the 64 bit version, if you try to load that in the 32 bit version the game resets. EDIT : just added an alert when trying to load a savegame in the wrong architecture. Notice that sometimes it works anyway so I won't forbid it, such as when you saved in a given stage, and load from a different stage, usually both stages use the same main loop in the program and only the ram changes, in this case usually you can load the game without any trouble. But in any other case, the emulated game will probably crash and sometimes reset, so it's probably a good thing to have some kind of message, even if the message here is not super clear, it just shows the IDs in the savegame which couldn't be loaded, usually related to cpu names... I don't know, maybe you hit some incompatibility with either the C cpu cores or some cheat combination. The error message you see is because the cheat is enabled when you boot the game, which is probably not a good idea, try to enable it only at the time it's needed and the message will disappear. What I can say is that I quite extensively tested this one when I was implied in the cave driver development, and I never saw something like that, so it's either the cheats or the 64 bits version, try to do some more testing to pinpoint what happened here... By the way you didn't tell which cheats yo used, they are not saved in a savegame...

Finally re-uploaded both binary archives with a filled config directory. Missing files were : neocheats.cfg : cheats for neocd/neogeo cheats.cfg : cheats for other games debug_dips.txt : info to access debug dips for neogeo / neocd sorry again, new builds, new mistakes... !

I just noticed I forgot the cheats.cfg file in all the 0.90 versions, so you can either get it from a previous version, it hasn't changed since 2017, or get it from here and drop the file in the raine config directory...

0.90.7 released, the only changes inside are the custom inputs which are all saved now instead of just what changed from the default inputs, and the small gui fix for dialogs which could have the text of their dialog bar cut if the resolution was too low.

The crazy numbers : just scancodes for the keys and encoded event for the joystick or mouse. The box title glitch in the previous post ? Oh, you found what these weird entries starting with a $ in games.cfg were, these were inputs saved for a specific configuration ! Yeah glitch fixed, very minor too.

After looking at that some more, I confirm, no bug here, or at least no other bug than the fact that it saved only changed inputs. I looked at your example with kof97, you look at button 1 & 2 with the joystick, except these 2 are NOT saved in your games.cfg, it's readable, you can check it, you have : kof97:keyconfig] use_custom_keys = 1 Def_P1_Up_joystick = 2049 Def_P1_Down_joystick = 2305 Def_P1_Left_joystick = 1537 Def_P1_Right_joystick = 1793 Def_P1_Button_3_joystick = 262145 Def_P1_Button_4_joystick = 327681 Player1_B1_B2_B3_joystick = 393217 Def_P1_Start_joystick = 655361 Def_Coin_A_joystick = 589825 So nothing specific about button1 or button 2, so they were just overwritten when you changed the default config, normal. It required someone making a heavy use of custom inputs to realize this, and even for you it took you quite some time. I even remember why I chose to do that this way the 1st time : because it was creating smaller config files ! I didn't realize that it would create problems ! Anyway now all the inputs are saved when you use custom inputs, so you won't see that again, you might want to reload all these games so that they update their config in games.cfg and after that you'll be fine. But by looking at that there is a weird config saved for you : [$ascii_controller:keyconfig], this one doesn't make any sense, but I don't know how it came here, nor when. I had something similar in mine, it looked like [$6_buttons_sf2:keyconfig], weird too, normally the 1st part before the : should only contain the short name. So I don't know if it's an old bug which was fixed a long time ago and just left some traces in games.cfg, or if it's a bug which is still somewhere now... I guess we'll need to wait and see for this one. I deleted this weird config in mine. I also had a dipswitches config saved in the middle of a key config, this should never happen too normally. You don't have this in yours, here again it might be something very old, and I even found a part specific to the dos version in mine, so this file was used in dos too... oh well I deleted this part too, I guess I'll have to check it from time to time then...

No, can't reproduce that, when I wrote the passage you are quoting, I did it on the emu at the same time to check, I guarantee that it worked as I said. Anyway it now saves all the inputs when using custom inputs for me which might create some differences, and I won't revert the changes to retest that.

It's not really a bug, it always worked like this, but since nobody is courageous enough to maintain some real documentation, it was lost. Anyway custom inputs inherit inputs from defaults of course and what is saved in custom inputs is only what you changed ! That's why by editing some default inputs you can affect games using the custom ones. I must say it's a little strange to save only what was changed, but it always worked like this since... err no not since the begining, actually it worked like this since the switch to sdl apparently, so since 0.50, it was an error on my part when rewriting the inputs code... So for example if you set custom button 1 to v in sailormn, then set default button 1 in another game to something else, sailormn will keep its v since it was saved in custom, but if you edit any other default input, it will inherit it. And you don't need to setup a new installation folder all the time, I always make sure there is no config file in the archive so it doesn't overwrite them, I can make a mistake of course, but it's extremely rare since I don't run the windows binaries in these folders usually. Ok, I'll remove the test, it's easy to save all the inputs when using custom inputs. But I won't make a new binary just for that, you'll have to wait until something more serious is found !

Sorry can't help you, I don't use dat files. I guess you should ask at this "dat workshop pro" site then... !

Ok, finished, fixed also the display of the Region menu when you 1st load a game, it was just displaying Region without anything until the game is run, it was just silly, a misplaced initialization, should have been fixed long ago... It also contains the new limit to 320x200 for the game bitmap for those crazy enough to play with this kind of setup. Anyway 0.90.6 released !

After all I fixed it because it was an interesting bug as a matter of fact, it was because of compiler optimization which changed the address of a variable and I didn't think it would change. So it forced me to change quite a few things so that it doesn't depend on a changing address. I am not making a binary yet, I'll take a little more time to see a few things...

with the command line : ./raine -gl|grep Sailor sailormo : Pretty Soldier Sailor Moon sailormn : Pretty Soldier Sailor Moon Ver B So the main appears as "ver b", the so-called clone is actually the 1st version and appears just as "pretty soldier sailor moon", and the file is sailormo, o like old. You have the eye for detail, the region switch was broken probably a very long time ago and nobody noticed till now, which is not a big surprise since the only thing it changes is the copyright screen and nothing else... ! From what I vaguely remember the region is in the eeprom, clearly it was lost somewhere here. I don't guarantee I'll fix it. And of course the company which produces it doesn't communicate about any changes made, so you can't know if there are really differences between the version b and the original, usually the changes are very minor though. And no, clones and regions are totally different, although there are a lot of clones which change only the region (for some games the region can be changed by changing just 1 byte, and it's the case with this one).

With a sailormn.zip in your roms directories the game appears in "available games", even if it's an empty file, it would take too much time to check the contents of the zip file just to display what is available. So check your setup, something is wrong somewhere, your sailormn.zip is not where it should be.