Tux

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.

This version of raine (after 0.50) is not designed for these low resolutions, it's designed to lcd screens which don't like this kind of video mode change. It has a minimum allowed resolution of 640x480 for the gui, and 320x240 for the game bitmap, if you go below that it will change all the time, so either use 640x480 minimum, or switch to the dos version which still uses the old blits, but since it's dos you'll miss quite a few things too, no cd music there, no opengl, and the gui is totally different, lacking most of the options we have now. But the dos version has all the vesa modes available and can work in 320x200, it was another era... you hit a coded limitation in resize() in sd/display.c, maybe I should have allowed 320x200 here, but you are the first one to actually hit it, and it's there since before I started using git, so more than 10 years already ! With a mode that low, it will change all the time to 640x480 to be able to display the gui, which makes it almost unusable in fullscreen. Oh well, I'll probably try to put 320x200 for an eventual next build, but I won't make a new build just for that...

Yeah the missing rasters in cps2 is known, it's tricky to emulate, comparable to the rasters in neogeo which gave me some trouble for quite some time, so since it's not used very much I simply avoided it so far, maybe one day where I am bored with a ton of motivation to fix things ! For your games, sailor moon is already emulated, called "sailor moon" simply, without the "pretty soldier" in front, but it's very probably the same one. For turtles in time, it's konami, usually not easy stuff. And did I mention I wanted to stop here ? It's a good point to stop, and there are even some people working to port raine to some strange new hardware now, so it seems ideal ! Anyway we'll see, I am mostly stuck inside for now because of the covid-19, but I find a lot of ways to keep busy ! See you, and thanks for the comments ! edit : you know you can display the games by category in raine, although the category "fight" is almost never used, and beat'em up is used instead. One of the most original ones if you don't know it, battle k-road, japan only but you don't need to read for this, the fights are very short usually, I never had the patience to play this, but you might find it interesting !

Ok, thanks !

No idea about your scaling option, normally it's done at the video driver level and is totally transparent for the applications, I didn't do anything for that anyway. But there were quite a few changes related to the scaling in windowed mode in 0.90, it might be the cause. It seems you were hit hard by the cps2 bug of last night, it was specific to the 64 bits build though. For your impossibility to load mvsc, don't know what you did, I just loaded it in the windows version to be sure, no problem. Remember there can be an infinity of roms folders for raine though, even if the 1st one is the default roms in its directory. You might want to try the command line -rc mvsc so that it tells you what is wrong with your mvsc (do that in a terminal or you won't see anything). (or -rcf ) Ok, added 2020, it gives me an excuse to call this one 0.90.5, even if the fix inside is really for the 64 bits version and specific to cps2. Anyway build updated, 0.90.5 released !

Specific to the c-only version (64 bits), works in 32 bits, I'll look into it... edit : ok, it's fixed, a speed hack at a bad area, it was undetected with starscream in 32 bits by pure luck, but it couldn't possibly work with musashi in 64 bits. It's moved to a safer area and it works for everyone now. Will make a new 64 bits binary later... It probably affects some other cps2 games, some big ones, anyway the fix works for all of them.

And new binaries posted : 0.90.4 !

dlls are in the dlls package associated with the right version. I had packaged symlinks by error for the dlls with the raine 7z for a few hours, if you have some weird dlls in your 7z file, overwrite them with the dlls from the dlls package.

For info, a new bug was just fixed, when loading a neocd game which changes its resolution after being loaded you got a totally distorted screen. This was related to a change on may 3rd 2019, so I guess I can take a little longer to produce a new binary for that (the fix is very short, it's just a misplaced function call). Found by someone working on a port, good news, I was hoping it would happen ! I'll try to make a new binary, probably tomorrow, this post is just so that nobody takes the time to report this one.

Argh, sorry for the version error, I edited the makefile too late, but that's the only change from the binary posted, the version number, my bad, too many things at the same time... I think I'll re-upload a binary for that with the right version number later, just so that things are cleaner. For the changes from 11/20/2019, well it was a 64 bit version only 1st, for the rest, there ae quite a few changes, I was tempted to send you to the git log, but I agree that the default version in github is a little terse, you need to click on the commits to get the details and it's not super convenient, so here is the current log until november 20th... Yeah I add missed a few bioses, not sure all of them are useful for an emu though, the 3.2 had only changes useful for the real hardware compared to the 3.1, but I hadn't time to look at the changes in detail... I added them anyway... ok I am good to reupload something then, at least it goes much faster than before, thanks for the post then ! edit : it's done, called the new upload 0.90.3 even if the only change is just the new bioses, just to make sure you have the new one. log.txt

Yeah I still have it too, thanks, everything should be fixed anyway now, thanks again Robert !