Tux

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.

Some news : I finally committed the script for xmcotar1d, I don't think I'll change it a lot more now. One of the latest changes inside is that you can now poke directly the characters if they happen to use the ascii code, as is the case in this game obviously. Except that there are the few variables added, the printed tests, and the whole thing is indented using a perl script. See it there : https://github.com/zelurker/raine/commit/3482f5b51a7bd8c9ba19896c5329d9fda546bc4a#diff-09023d1e9c13785c9473fd6277a4469afdae3fd95ddf7bf02d8a9a3b9dcbe2b1 You can use "view file" in the "..." menu, and then raw if you want to download it. But of course this script will work only with the git version of raine for now, you'll need to compile your version, or at least change back the poke which use character strings back to poke which use normal values ! Also I finally added something to preserve the parsed state of the script (for the run: section), it's not really compilation, but it speeds up things considerably. I am not finished with my ideas about this yet, but it's already a big improvement compared to what we had before (hoping I didn't add too many bugs !). An example of this poke with characters : poke $6B6F0 'PRESS START@' or for arcade : if (peek(choice)==$00) #Arcade# poke $908E71 ' ' poke $908EF1 'A' poke $908F71 'R' poke $908FF1 'C' poke $909071 'A' poke $9090F1 'D' poke $909171 'E' poke $9091F1 ' ' And by the way it was a pretty neat trick to update the layer this way to display your text, especially with their weird layout. By the way the text you put in rom, replacing "insert coin" by "press start", it's actually wrong, it's right only if you configure the game in free play mode (I didn't even verify if there is a free play mode in the service mode), but in the default normal mode you still need to insert a coin to arrive to the main menu and make your selection.

yep as many variables as you like, no restriction, just once a variable is defined it stays there, any script can access it, even if you load another game it's still there, so just be careful that 2 scripts executed at the same time don't use 2 different variables with the same name, it wouldn't work.

Yes but careful if you use that on 2 scripts which can be activated at the same time : variables are global only for now so if they have the same name, they will collide. You have some useful instruction to check that : print_ingame. It works like this : print_ingame number_of_frames text so if you want to check if a part of a script remains active at a certain time, add something like print_ingame 1 "message" at the start of the section you want to check. If you see the message all the time, it means it's always active. I am not sure I understood completely your question here, but this instruction should be useful anyway ! For now yes they do sadly. As I said the scripts are really not intended to be run this way and there is no optimization to jump a big section of an if whose condition is false, which means that it will still parse all the lines inside, but not execute them, so it will not take too much time, but it will still take some execution time. I am thinking of a way to improve that, but for now that's how it works yeah. By the way you can also use print_ingame to display variables, but it works like the printf command in C, so it's a little special : %d is replaced by the variable in integer form, while %c is replaced by the character whose ascii code is the value of the variable, %x is the value of the variable in hex, and so on. And contrary to what the internal help of the console says you can use this from the console, but in this case use a high number of frames to have the time to see the message, so you must do that with a loaded game, like this for example a=3 print_ingame 120 "test a=%d" a and you should see "test a=3" for 2 seconds (1 second is 60 frames) in the lower left corner of the screen when you close the console. I hope it helps !

After looking a little more at your scripts, some notes about optimizations : when I added support for these scripts, I thought they would run only for 1 frame, and that's all. But then mame introduced the "run:" part, where the scripts run as long as they are active, every frame. Yeah I had thought about that too for values which need to be poked every frame, like invulnerability, but simple stuff that's all, but sometimes it really became quite big. And you beat them to the record of the big stuff which runs every frame ! But since you change the way the game works, you are forced to do it this way of course, it was just unexpected. I chose this script system because it was easy to add, but in this kind of circumstances it's awfully inefficient, there is no compilation so all the lines in the script which are executed are interpreted all the time, and this every frame, so it means 60 times / second. At least we have crazily fast cpus now, so they can sustain the load, but here it's a lot of wasted cycles anyway... So if you want to see the load of your script on the cpu, just switch to the profiler display (press f11 until you get some % displays on the upper right corner of the screen), the cheats appear in the misc section, it's always at 0% in normal operation... Now some simple tricks you can use to lower the load : when changing the menu displayed on the screen, what is displayed stays, it doesn't have to be sent in every frame. So you can use a variable here like printed. Set it to 0 by default, then when you have displayed one entry set it to 1, so this entry won't be displayed again in the next frame. For xmcotar1d it produces something like this : if (dpeek(choice)==$0000)and((peek($FF4BAB)==$04)or(peek($FF$4BAD)==$04)) dpoke choice $01FF printed=0 endif if (dpeek(choice)==$0100)and((peek($FF4BAB)==$04)or(peek($FF$4BAD)==$04)) dpoke choice $02FF printed=0 endif Oh yeah I also added credits=$ff4bdd choice=$ff2000 at the beginning of the script to be able to use variables here. So this is the part where you navigate the menu and update the choice address with what you receive, for each update you set printed to 0. Then the display itself : #Menu Text# if !printed poke $908E73 $14 #Text Color# poke $908EF3 $14 ... if (peek(choice)==$00) #Arcade# poke $908E71 $20 poke $908EF1 $41 poke $908F71 $52 poke $908FF1 $43 poke $909071 $41 poke $9090F1 $44 poke $909171 $45 poke $9091F1 $20 printed=1 endif This way you set printed to 1 once Arcade has been displayed, so in the next frame it won't have to do it again. The small drawback of this method is that if you exit this menu by an unexpected way like the f1 key to reset the game, next time you arrive to it, the computer will believe it's already displayed since printed will still be at 1. Well just press up or down key and the menu text appears again. It's a choice... The if !printed finishes after the last entry has been displayed, so after Option here. Anyway these are just some ideas, you can keep your script as it is if you prefer, I'll just have to find more complex ideas to work with this ! And if !printed means "if not printed", it's the way to write it in most languages like C, but you can do this in basic too... (except in basic it's "not " instead of ! alone).

No rush... and I found a very particular crash here while testing something else, linux only, 32 bits only, and recent system updates only, it reminds me of the recent problems in windows with the cps2 driver. I committed a workaround in git, there doesn't seem to be a better fix for now. edit : finally found the problem, it was rather tricky, sdl2 was using a SSE memcpy in this case, but starscream, the asm 68k emulator we use in 32 bits aligns the stack on 4 bytes boundaries, which seems reasonable, except that SSE requires 16 bytes boundaries for the stack ! Luckily there is a function attribute to ask for a stack realignment in this case, it saved the day. Still no rush though, I have other ideas but it will take some time.

I simply moved your cheats to the end of the file, because the main ones are generic, those you added are very specific, and inserted the lines script " " script "Forum cheats, see topic 'sharing of cheat used in Raine'" script " " just before so that it makes a title section when displaying the cheats in the dialog. I'll do that for the other games you handled later and put that in git.

Congratulations for your motivation, it's rather impressive !

Well for now the optimization makes a difference only for the debug build, going from 20+% to about 13%, not bad, in the optimized build no real difference. A lot of things would need to be rewritten to make a real difference, and for now it would be overkill, this thing works quite well. For a very limited coding experience your latest script is state of the art, comments inside and identations ! Even Antiriad almost never idented his code in the old sources for raine 0.28 and before ! So great work, and it probably took you quite a lot of time !

The link sends a request for authorization, oh well... ! But from the description it seems again impressive. I don't know where you find all this knowledge about these games but wow ! edit : ok now, I guess I'll have to merge all these cheats in the next version then, since you added them at the beginning of what there was, it shouldn't be a problem. Congrats again, I should spend more time on this game too one day ! edit again : the run part of the script is quite huge, using a debug build the profile % (f11 key) show misc jumping to about 23% cpu time when activating the console cheat ! It's 5-6% only when using an optimized build like what you have for the releases, but there might be some ways to optimize this...

Yeah for the zelda there are a lot of options already inside, maybe they'll add a few more. For homm3, it's a huge time black hole. It started to be released in 1999 for its 1st version, but I got very busy around 2000 and totally missed its last chapter "heroes chronicles", which for some reason, was not even included in the so called "heroes of might and magic 3 complete" ! So it's complete, but without chronicles, go figure. And so I just discovered it now. But since it's been very long I didn't play this, I decided to start by replaying the biggest part of the game, which is the campaign "restoration of Erathia", and while playing I realized that I never actually finished it in the original game. It starts very easy to make you used to the game, and then gradually becomes harder. Maybe they changed a few maps in the complete edition, or maybe it's something else but it's probably the complete edition which does that, but some maps are really harder than in the original version, I verified that on internet, some walkthroughs are simply impossible to follow with these versions ! And the wog version (the heroes 3.5 portal linked in the post above) is full of extensions built by the community which offer an amazing number of options and things to play with. Just testing these take a lot of time. But yeah it's great. I had been playing a little with heroes 5 lately, and there is really a huge difference in the realization of the game, the way the story is told. In h5 the story is only a pretense (I stopped at a mission called the trap, so you know from the beginning it's going to be a trap, but since there is no limit to anything here, you arrive at the end with an army which can beat anything, and despite that, scripted event, your commander is made prisoner, which doesn't make any sense, but it's their stupid way to tell the story). In h3, you don't have anything like that, you are deeply immersed in the story and it's hard to get away. I think the biggest difference is that obviously the creators of h3 played their game and enjoyed it, when the people who created h5 obviously didn't play it, or at least not enough, clearly ! So I'll be busy for still quite some time... ! For your idea to play it on a phone : there is a remake from scratch called vcmi which probably allows to run it on android. I find vcmi disappointing on pc, the latest version is called 1.1.0, but it really doesn't feel like a 1.0 versions, heroes3 was very close to perfection, and here there are some tiny annoyances everywhere. But the biggest problem would probably be that when there is a fight you often hover the mouse around the point you want to click to check the pointer you get, and you click only when you get what you want. I don't know how it would turn out on a phone or tablet, but it would probably be less convenient and awkward, you'd better at least check that on pc first before trying a portable version.

Not related at all to raine, but for those who missed the news, zelda (a link to the past, the snes version) was recently reverse engineered, that is the rom was converted back to some C source, which is quite a feat, clearly the people who did that really loved that game to spend so much time on it. It produces some impressive result, take a look there : https://games.slashdot.org/story/23/02/05/0225219/legend-of-zelda-a-link-to-the-past-reverse-engineered-for-linux-switch-mac-and-windows (and follow the links to the github site, for linux I compiled the thing in a matter of minutes, it's very small in today standards). And sorry but lately I have been spending a lot of time on heroes3 (https://heroes3wog.net/heroes-3-launcher-download/) I discovered that I missed a whole part of this game some 20 years ago, and I am doing some catching up ! It's amazing how this game remains so good after all this time !

1 point for a way to display this with hands on a game controller, now not sure a scrolling line would be great, it comes from mame and sometimes it's a message on many lines, so watching the whole thing scroll would not be super nice anyway... !

F2 save, F3 switch save state number, F4 load or you can look at raine controls in inputs, assuming you use the english version.

Just click on the line one day... ! why do you think it's flashing ? To be clicked !!! But there was an error here that I didn't notice from the conversion from sdl1, the bg color of the text has become green instead of blue, it's a common bug in the color conversions, it's fixed in git.

Quite impressive job, congrats !

Well raine is full of tricks to try to preserve it as much as possible, normally it survives a game reset, even a game load (loading a save state), and sometimes the test mode (but not always, depending on the way the ram is initialized or not). It's saved only when you quit raine or load another game, so if you go to test mode, and it's not detected because of a fancy ram initialization and then quit or load another game, you destroy the hiscore file. Sorry I can't do much about that... ! edit : all this pushed me to update the very old code for this turbo key, it was still trying to display the fps as an int when returning to limited speed when it's been a double for quite a few years already, so the display was very wrong. Now it's correct, and it also displays the average fps reached while the turbo key was pressed (I reach more than 4000 fps during the sfad demo and with a debug build, but it's the assembler version, but it's really too fast at this level !). And finally it automatically disables the opengl double buffer while the turbo key is pressed, so now you can finally use this key without changing anything in the video settings !

You are still very bad, I played a while with the turbo key (del), requires to disable double buffer in opengl rendering otherwise it's blocked by the vbl, but once it works it really goes too fast, half a second press and the demo has already done 1 loop ! Anyway finally reached 2 hiscore tables, they look fine to me except the weird C head for the guy on the right for the 1st picture. I think I am going to ignore your posts for a while... ! I attach 2 screenshots of the 2 hiscore tables... edit : after some short thinking, if it's the contents of your hiscore table which looks weird, you might have corrupted unwillingly your hiscore file for this game while experimenting with your scripts. Try to delete the sfad.hi file in the savedata directory (then restart raine of course). But if that's indeed your problem, next time at least post a screenshot it will save me a lot of time !