Tux

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.

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.