Tux

And now I have the info in text and picture in the status bar at the bottom of the screen, this part was easy. Now it would be cool to add some code to check if there are conflicts between the selected ips, but I'll keep that for tomorrow... !

Ok it's pushed to git, I used the collection you posted as a test, good thing because there was 1 of the dat file containing garbage utf8 characters at the start which needed to be filtered out... Apparently it works now. The file selector which appears when choosing "preload ips dat files" now allows to select multiple files in a game directory (and it can't leave the ips directory), when you leave the game directory or close the file selector the corresponding config is saved in the ini file in the ips directory. This ini file is read when a game is loaded with a corresponding name. That's all there is to it, quite simple to sum up, but full of small annoyances when coding it. There is a hard limit of 20 ips files at max, the prog will complain if you try to go over that, but you would really want to push the limit to do it, your collection uses 11 ips files, and that's already quite something, and there is still some margin here ! Congratulations for finding this combination by the way, it's right that kof97 is much better with this ! I should improve the way it looks by displaying some description and maybe the picture while browsing the dat files, but I keep that for later... !

It will take longer than anticipated because I must start by adding a gui widget and it's been a long time since I did it for the last time, a little rusted here. By the way I even found a french dat file : 2-plus06.dat, it should be relatively understandable in english even without google ? They say this modification is major, contrary to most of the others which are very targeted, it probably explains why you can use many at the same time without problem, still lucky though, it means they don't use the trick of adding a jump and moving the code at the end of the rom, otherwise all the code of all the patches would happily overwrite each other at the end of the rom... ! Still crazy, but indeed this time there are more valuable approaches there.

Well you are lucky to be able to use these patches simultaneously, these are not simple plugins, these are patches, I mean if 2 patches you use happen to patch the same area, it's boum ! For now I didn't add any support to have more than 1 dat file at a time, but it shouldn't be too hard to do. Yeah the git repo is definitely low quality, it's not a super idea to put this in git to begin with because ips are binary files and even if git allows to put binary files, it shines for ascii files, here it looks like a waste of space. For your broken roulette patch, if I have to guess I'd say it was 8r-hcsjh2n.dat, replaced by 3-hchr2ps.dat... (names similar !). I'll try to add the possibility to make combinations of dat files later then.

The most broken dat file found so far is for double dragon, doubledrsp_20220717.dat its 1st ips references the code rom beyond its size, thanks to the new size limit for avoiding the crash and then the 2 following ips files in the dat file don't even have the same name as on disk, so they can't be found ! It's almost a shame to add some support for something which can be so broken... ! So don't worry if you have problems with all that, it was worth an experiment, but probably not worth loosing too much time on it. At least the code to add support for that is short, there won't be any problem with that !

Ok after a good break I finally decided to add some support for these dat out of curiosity (curiosity works well on me usually !). So it's some basic support, it works by preloading the dat file, a new command appears in the main menu when no game is loaded : preload ips dat file, it gives a file selector where you must choose the .dat file you want. Normally you should return to the main menu without message after that, you can load the real rom now. If the patches apply without error, you won't get any message, and then you can play normally. In my tests I found some dat files reference a rom file that I don't have, specifically for kof97 in the github repository kof97ae_20180212.dat and kof97ae_20200810.dat both reference a very big 232-v3.v3 rom. We have this rom, but not so big, our size is $400000 when they try to access it as far as $f00000, which created a very nice rom crash here. So I added some tests for the maximum size allowed, for now it just displays a message on the console and tries to patch what it can as long as it's not over limit. I have tested pacman (in Misc), it changes everything, but is not very interesting, I prefer the original version ! and puzzle bubble 3, there are changes alright, but it seems to force you in a duel against the computer (there is some kind of cheat in the menu of the game which selects the right choice before you can move !). Anyway at least it shows it works. The previous command to load an ips file is still here for the cases where you have just an ips file, it still has the same rules, applies only to the rom code on the fly. These dat files apply the ips files referenced at a super low level, just after the rom has been loaded but before any decoding could take place. I didn't try to put a super interface for that, because I didn't find a really interesting dat file yet. Maybe later, I am far from having tested everything, but I am at saturation now... ! So it doesn't try to extract any description from the dat file, you'll have to select your dat file yourself !

Yeah I had the same kind of idea, that's the 1st thing I did after releasing 0.94.11, I added an option to have the profiler ignore the rdtsc whose reading is dependant on the cpu frequency, so if something changes your cpu frequency during gameplay it can ruin this kind of measurement. I keep the option, it can be useful in windows where there are tools which change the frequency all the time, but in linux my frequency is quite stable and I get almost the same readings when using sdl2 instead of the rdtsc. The setting is in gui options : profiler mode, you should set that to sdl2 performance counter if you want it to be independent of your cpu frequency.

Yes it's because it now keeps its parsing results, impoving a lot the speed to jump over code which is not executed. I had planned to add some jump points to make it skip this code even faster, but after testing I found it's now useless, you don't even see any difference with that, and the code gets more complex, so I just didn't do it.

After a longer look, it's lacking more descriptions for sure ! It's in the spirit of bootlegs where sometimes you really wonder what the difference is... ! Found a few oddities like the sailormn ips which make the game crazily harder, oh well.... the kf2k5uni which does an update without telling what is in the update and it's not obvious... ! Except that a ton where I couldn't tell what the difference is actually ! I'd say for now it's not motivating at all to add more support for that, I'll try to have a look at the video though...

Yeah even if it's convenient sometimes while testing one of your special scripts to have it survive a reset, logic tells all scripts should be stopped when there is a reset, it's easy to do, I'll push the commit soon.

Just tried it in xmcotar1d, started the Console script in the gui, opened the console, typed stop "Console Mode" it worked, the script is stopped. I didn't try with a hidden thing, because I never even made a hiiden script which uses a run: section so far... And to be even more sure I tested from a script by adding a stop "Console Mode" at the beginning of the if !printed section so it stops actually itself when it reaches the menu, it worked too. Funny thing is that you see ARCADE, because the script isn't stopped immediately, it's stopped in the next frame, so it has time to write ARCADE before stopping for real. Everything works as far as I know !

Yeah well for now I am not sure I'll add the patching for sprites. The big difference with the patches is that they can't be patched on the fly, you have to patch the rom before it's decoded, which is a lot trickier. There are already a few interesting patches in the github repo, I liked the patch to update the kf2k5uni clone, too bad it doesn't detail what the changes are exactly (I added kf2k5uni because of that, it has a bug with sound when using the 32 bits version and there is a memory leak somewhere, but it works). I'll check the bugs later eventually, but this patch patches only the rom, and it's quite good. Yeah most of the arcade bootlegs come from Korea and China apparently, these people are crazy hackers for roms, that's why the ips files come from there. Most of the stuff doesn't look very interesting though, sadly all the bootleg are not interesting too, far from that. The idea was to have a simple way to try an ips file without having to deal with the bad crc warning if you patch the rom directly. That's done for the code part at least, I'll see if I push this further or not, for now I take a break !

Interesting, they added some dat files for info, but also to tell which ips file to apply to which rom, which can be done automatically by following what's there. Now the problem is that once the game is loaded the sprites are already decoded, so to be able to patch this they would need to be reloaded, then patched, then redecoded. All the games wouldn't support that because some have their custom decoding mechanism ! So it becomes quite a headache... ! So this part is much harder, but I guess we can keep at least the basic ips patching for code roms. I'll think about the other options there... ! There was an example of this rle thing, now that I could confirm how it works I added it in the code, this part is still very easy, it's not pushed to git, no reason for now.

Yep found it here on github : https://github.com/taoenwen/FBNeo_IPS.git but it's made by Japanese people, but there are some dat files with some english description inside... Apparently they don't always patch just the code rom. I'll look into it in more detail...

You have enough ip files to fill a directory ? Good news, it's probably from some very foreign sites because I had a quick look on the net yesterday and couldn't find any. But yes good idea I'll make at least the ips directory and set this as default directory when opening the file selector. Notice I didn't test these ips ingame, but I checked the code after patching looking at the changed offsets and it looked good, it pushed me to make another commit for the l command because I couldn't get the right assembler listing from the patched address (overlapped by the garbage which was there before the patching). Anyway it's done, ips directory created when you launch raine if it doesn't exit, and it becomes the default for ips files, pushed to git.

Well just added some support in git, based on these 2 ips files. The command appears below "Game cheats" (I thought 1st to include it in the cheats dialog, but this one is very specific and it's better not to touch it). It's an ultra basic support, it doesn't support the rle chunks the doc talked about because I had nothing to test that, and it assumes there are no word inversions which was the case for these 2 ips files. AFAIK, it works well, I can't be super sure since you have to finish totally the game to see if it works, and I didn't feel like doing that ! It was really super easy to add, look at the length of the do_ips function in git, simply ridiculous ! It doesn't ask for the name of the file to apply the ips, it assumes it's applied on the currently loaded rom with the given offsets in the ips file.

Plus they are extremely hard to find for arcade roms, it's mostly used for translations for console games. But anyway if you have a simple ips one day it's worth spending a few minutes on it !

Yeah it's the very last case where it's useful to use an unzipped rom ! Well if you want to make a converter which works in all the cases it's not that easy, because it must : 1) get the name of the file it will apply the ips to 2) get the way this file is loaded into the rom, and change its behavior based on that. Then the 68000 swaps the bytes words, but it's the only cpu doing that. Plus there is the problem of how to handle the result : generate a new script for that, and just apply the ips on the fly after loading the rom ? Anyway if you have an ips which makes a more obvious change, like changing something on the title screen so that you can check if it's been applied or not very quick, I am ok to play a little with that ! Just committed the stop function to git.

Notice that an ips file is actually super easy to read, you can find its super basic format here : http://fileformats.archiveteam.org/wiki/IPS_(binary_patch_format) it's just a series of offsets + sequence of bytes to write, that's all. They should have included at least the base file name just in case, with an option to overwrite it, but anyway. So it could be converted to a series of pokes, here the p1 file is loaded with words inverted so if you want to translate this to poke on the loaded rom I'd have to experiment to make sure the byte order is right, but it's not complicated to do. But it's probably better to leave it as it is, I wouldn't know where to fit an ips reader in the overloaded raine interface, and ips files are quite easy to apply so it's good as it is now.

Yeah optimization was my 1st idea here. Ok, I'll add a stop command, without argument stops the current script, can be useful in an if, with a name argument stops this script.

Yeah you can start any script hidden or not, but it doesn't require a stop_script command at least I didn't think so yet : if you want to start it just once, just put your code in an on: section, it will be executed once by the start_script command. Otherwise put it in run:, it will start to be executed like a normally activated script in the next frame. If you find a case where a stop_script could be useful to stop a running script, explain it, it's not hard to add. If it needs to be executed in every frame while you are in the menu then yeah I'll need to add this stop_script function, otherwise a on: section will do...

I hadn't planned to make a 0.94.11, but things didn't go as planned, and ffman1985 found new ideas to make crazy scripts, so... - daioh displays correctly its controls in the gui, and not as a 6 buttons fighting game anymore - update for the turbo key (DEL by default) : it was still displaying the fps as an int when it has been a float for years now, so its display was totally wrong, it now displays the fps reached while the speed was unlimited, and opengl double buffer is temporary disabled when using this so that the speed is not limited by the video hardware. - fix bad color for the status bar in the cheats dialog when there is a message... - fix for a crash in 32 bits, it happened in linux, but it could happen in windows too, it was a stack misalignment because starscream uses 4 bytes boundaries and the SSE functions in sdl2 require 16 bytes boundaries (which is huge !). There is a function attribute to fix that, so it's fixed simply but it was hard to find. Except that on scripts : - you can now make hidden scripts which don't show in the gui dialog. It's useful only if you want to start it like you would call a procedure in a high level language by using the start_script command. It allows to move a block from a script there. It's more an experiment, I find the thing hard to use, but it was easy to make, so I keep it in case it's useful one day. Just replace the "script" command by "hidden", same arguments, same syntax, it just doesn't appear in the gui. - Better error messages : I added the error messages at lightning speed, but there were case where they were really not very helpful. Now you can see which script triggered the error, in which section and what line. And if it's in a run: section, the script is stopped to avoid an endless loop of errors ! - poke extension, can use a string of any length as the value to poke, the string must be enclosed between ' ' or " ", there is a foum post with an example, and it's in use in the xmcotar1d script (Console script). - The big optimization of the scripts : they now preserve their parsed result to avoid to redo the stuff in each frame. Now I got some very strange behavior from windows and I still didn't understand everything here, but windows execution appears slower than linux for some reason (see the script cpu load in the Misc section of the profile display, f11 key). The 64 bits binary seems ok, I am not totally sure about the 32 bits binary, I saw it working well, but not always ! I don't know what triggers this slowdown, maybe with time I'll have more ideas. What I can say is that even when it works at its best, it's still slower than the linux version, I get 2% only in Misc while the console script is in startup (when you just start it), even with a non optimized debug build ! So see by yourself, your results might vary. That's all for this time ! http://raine.1emulation.com/download/latest.html

Well after testing this thing deeply, I can say what it's not, but I can't say what it is ! It's not a muparser problem, the author has made it easy to integrate it with a program, I tried that, got the same result, it's convenient to debug the lib to check if it doesn't make initializations in loop which could explain this behavior, but no it doesn't. The same exe launched from mingw32 terminal windows seems faster than when launched from the explorer ! Crazier and crazier... ! I don't give up yet, but it sure is crazy. Too bad there is no windows lover who would want to look into this around here, I'd be glad to just forget about all that !

Oh, a windows annoyance ! Well in linux at the beginning of the console script in xmcotar1d I am at around 2% misc. In windows it's more like 20% ! When reaching the menu, it's around 8-9% in linux. In windows it's like 50% !!! Well, it's the same binary, how can it do such a difference ? It's even the same muparser version ! So I'll keep it a little longer then, time to investigate this, even though I hate investigating windows stuff... !

I reach the limit of what can be done in a "reasonable" way, that is I tried some pseudo byte code : almost no acceleration, I tried to keep marks to jump directly to the end of an if block when a condition is false, same thing, no effect or almost. So now it appears the biggest slowdown seems to be about managing lines like : if ((peek($FF4BAB)==$00)and(peek($FF4BAD)==$00))and(peek($FF2001)==$FF) doesn't seem very impressive to me though, maybe it's because muparser works with doubles internally and so there are some crazy conversions behind the scene here, quite surprising because usually muparser is very fast and our modern cpus can handle double numbers almost like ints, I checked peek and dpeek and they are as fast as they can be, so I don't know. Maybe I missed something, for now I have no more ideas. Oh well it was an interesting try at least ! The unreasonable way would be to redo a parser from scratch using ints this time and which keeps some pseudo byte code along the way, really too crazy here. Maybe some other ways like having an lua interface, but it would really be unreasonable just for that. I'll just stop here for now, I'll release the binary later. The core code is more complex of course, but it still seems solid and error messages are much better now.