Tux

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 !

You are really very bad at reporting problems, was it with sf2 ? probably not since its settings are by dipswitches, so I don't even know which game you are talking about !!! If it's around the save screen, a savegame could be handy so that it can be reproduced quickly... ! sfad because of your other post ? No japanese language there, I checked the scores anyway, no problem to see. So I just don't know !

More details about this crash ? Related to your poke or not ?

You should know that cps2 roms are encrypted, it forces to separate data from code, I can't even say where your poke goes without checking the code, it must use at the same time a part which is encrypted and one which is decrypted, don't remember which is which. You can use the pheonix edition versions which are decrypted as a workaround.

For sf2 it's simply dipswitches, nothing to see in the test mode for that.

it's pretty self explanatory, see at the bottom of the page, up or down to navigate the menu, button 1 to select entries, what you want is system configuration, then make your changes, then exit (it tells to use 1p start to return to previous menu) then exit, it will save the settings to the eeprom automatically. You just need to read. Some games use a test mod like this instead of dipswitches. Of course here it's for a qsound cps1 game and these games don't have dipswitches, just a test mode. For the non qsound games, they have dipswitches !

Test mode (u key by default), which I tend to call "service mode" but apparently "service mode" is for when you start a game without inserting a coin, anyway, u key !

Of course not, it just changes the loaded rom image, you would need to save explicitely the file for that... ! Also notice that if you do the same patch for neocd, then it's not rom anymore, the code is loaded from cd to ram, but since the ram has the same address as the neogeo rom some patches are compatible.