Tux

The glorious 1st luascript : luascript "test 2 alt [lua]" run: poke(0xFF4BE1,0xF3) poke(0xFF26AD,0x71) for i=0,0x2ac,4 do dpoke(0x90c090+i,0x6000) end it's still for mshud, so it's the same syntax as a usual script, except the contents of the sections is directly some lua code. peek, dpeek, lpeek, poke, dpoke, lpoke are supported, but these are the only functions supported for now in lua, but with this we should be able to convert most of your scripts already ! (notice the ; is actually only useful if you have everything in 1 line, otherwise you can forget it) This is of course work in progress, if you try to pass a parameter to such a script it will be ignored. But it's progressing fast anyway ! edit : and fixed for windows... !

This one is exactly like the previous one, except poke instead of dpoke. I needed something where you see a heavy misc usage, but it's not an emergency, it can wait. For the pm you cut the message too much, the important part is gone there ! and without looking at the message, if you install lua it should compile without any warning, for the 32 bits mingw32 shell it's pacman -S mingw-w64-i686-lua translate to the equivalent package name for mingw64.

Returning to your original script, xmcotar1d, it was slow in its time so it's a good candidate to test with lua, I can't navigate the menu in the start screen... 1st it displays press start, you must still insert a coin, contrary to some more recent scripts, then you reach the start screen with your "ARCADE" text printed below, there direction keys should navigate the menu, right ? Because they don't for me... Did I miss something or did we break it at some moment ?

Rename the function : sorry it's always been like this, it's documented in the very old 0.28 documentation, so maybe one day, but not for now. Guide as default : never done that, so I tried it to see how to map a button for a controller. It will work only if a controller is recognized, otherwise it will be button 6, and of course only for those like you... and probably you only + some eventual new users start without any config file. It's one anyway. for the swap : the gui doesn't even use x & y buttons for now, so really there is no point for the gui, and maybe some users like the default nintendo placement, it's their choice after all, so they change the mapping if they want. For some reason mine was overwritten and I had to recreate it. No idea why it was overwritten, I'll have to be more careful... !

Actually I have just experimented with some lua binding to do this kind of thing, I can get this run script to run at 0% misc on a debug build with a lua binding ! The script becomes this : script "test 2 alt" run: poke $FF4BE1 $F3 poke $FF26AD $71 #for counter=0 counter<=$2ac counter=counter+4 dpoke $90c090+counter $6000 lua for i=0,0x2ac,4 do dpoke(0x90c090+i,0x6000); end The lua for is like the C one in even shorter, you don't even write the test in full, nor the increment. The trick which makes it so much faster than our classic script functions is that here it's allowed to pass numbers directly to functions, so the dpoke here doesn't have to do any string conversion, it's a super short function which writes almost directly to ram ! That's also why you are obliged to use the 0x notation for hex numbers, which I don't like personally, but it's the one officially used by C and lua for numbers and you don't want to convert strings to numbers here, so you have to use their notation. I tried first to interface lua to our usual do_poke function and I got something around 38% in misc with the debug build, so I tried this direct version with numbers instead -> down to 0% ! Now it's something ultra experimental, on arch I was obliged to use some tricks for the 32 bits package because these morons (I like them usually but here they are morons !) don't provide a 32 bits package for lua53, so you need to build it yourself, which won't be easy for the official package for sure. Plus it uses liblua.so for the 32 bits package, and liblua5.3.so for the 64 bits package, not sure how it will work in mingw... ! But it's interesting nonetheless... It's not pushed to git yet, I'll have to test this in windows first... ! Ah and also : lua knows only about dpoke, this is the only function I added for it ! edit : I had a quick look at mingw32 and actually they don't have any lua-5.3 package, then I found out that finally the same interface can be used with lua-5.4, so I pushed everything to git, just install the latest lua package from mingw32, it should work. Notice that you can experiment with lua code in the console, you get some nicely displayed error messages from the lua interpreter in the console. I didn't test the compilation in mingw32 yet... ! edit 2 : windows build fixed, mainly memwatch stupid types in windows, and put lua lib in all the builds except dos (no idea if there is a lua for dos, but there is no console in dos !). Oh yeah by the way lua uses ; sometimes to finish an instruction like here for dpoke, if you remove the ; you get an error, so ; are not recognized as comments anymore !

Ah yes good lesson... ! Well I have a good news and a bad news ! The good news is that it's fixed... The bad news is that it was very fast because it executed only the 1st time, it was not exactly a bug in the for code, it was because of the recent optimization of the script, now lines are parsed the 1st time they are executed, and then it's some semi compiled code which is executed, and with the inserted instruction starting at argument 4, the instruction itself, it was really not supported ! So after fixing this, it becomes slow as it should have been, I was surprised it was so fast, but didn't care enough to investigate, it was because it was executed only once ! It means that for this loop with quite a fast cpu I get about 55% cpu time in the misc for you run: script and it's up to 95% if using a debug build (which means 0% in free, and 60 fps can't be maintained anymore). As I said originally : avoid to have this kind of beast in a run: script, if you do that, either put it inside a if so that it's not executed all the time, or make sure it's short !

Ah mer-curious is tired... ! All the raine functions which can be controlled by the keyboard can also be mapped to any joystick input, here you are talking about "stop emulation" in "inputs / raine controls". It's not a problem when mapping a joystick input to this one, but careful if you map another key here ! The difference with "return to the gui" : return to the gui is for the case when you run the emulator with the -nogui command line option and with a game name in the command line (which probably never happens in windows these days, except for those who still use a frontend to launch raine). Then if you press ESC it will simply quit, so if you change your mind and only want to return to the gui that's what this function is done for. If it's mapped as a normal button then no problem ! Yeah noticed it a while back already, it's super minor, and didn't take the time to look into it yet. Sorry I thought it was clear, in linux I use a custom mapping as explained, it swaps the 2 buttons for the gui and for the games, and it's perfect for me. I don't think I'll add some way to remap the joystick buttons in the gui alone, I find it overkill.

Ok pushed to git after a quick test, you forgot to mention there is no for in them so it's compatible with current raine version.

Why ? I love the precision of your messages by the way, I had to fetch the short name of the game in the game list... xmcotar1d, copy your script, and test it : everything is fine, so why bother ?

Well I didn't understand everything here, with this script you start it on the title screen, it works like the on script, normal, then f1 to reset, which stops all the scripts including this one, when you return to the title script it's normal which confirms this script is indeed stopped. But apparently it's not a problem for you anyway so everything is good. And that's right, this loop is quite fast, it's probably because the 3 1st instructions of the for are specially evaluated, no function parsing for these 3, the function parsing is used only from the 4th argument. Anyway it works well, so it's good.

When you reset all the scripts are stopped, if you start it again then it should work. Once again : the initialization part of the loop is always executed, so whatever value there is in the loop variable when the loop starts is not relevant.

Nope at the exit of the loop the variable has the last value which made it to exit and keeps it even if there is a reset, but if you execute a loop again, the 1st instruction of the loop is always executed so the old value doesn't matter.

Ok, finally understood so there is indeed a bug, actually 2 bugs in the for loop, here is what happens when you do many things at the same time... ! Anyway it's fixed, your test2 now clears the whole screen keeping only the stars.

Tsss, your original script did that exact same thing with the gauntlet alone in the middle of the screen ! Ok then I leave you to that then !

Just to be perfectly sure I did that in windows, in msys 32 bits git pull then make on a makefile for the debug version then copied the mshud.txt file from the attachment above. Then ran the game inserted a coin, ran the script took this picture. If you get something else then we really don't live in the same world !

It's probably something stupid but since I can't guess what it is, here is my mshud.txt file. To be started on the title screen of course. mshud.txt

Well it works here so you probably made a mistake somewhere. Of course not you can do whatever you want with it, but be careful if the loop never ends then raine will freeze and the only way to stop it will be to kill it (from the task manager). You can open the console and do a help for to check if for is really inside. And of course if you run a loop such as the one in your example in every frame in a run: script, it will probably be very very slow !

Just pushed this simple for loop to git, your script becomes : script "test 2" on: poke $FF4BE1 $F3 poke $FF26AD $71 for counter=0 counter<=$2ac counter=counter+4 dpoke $90c090+counter $6000 it's now a on: script, not a run: because everything executes in just 1 frame.

There are 2 parts here : 1) it's not a crash, it's the effect of the recent optimization to make the ifs faster, if you run raine from a console (which is always the case for me in linux, curse windows to make running programs from a console so difficult !), you'll see it prints an error message before exiting without crashing, the message says : no command for counter=dpeek($FF1020) It's not an error from you, it's because the optimization expects to have real commands inside an if, that is a function name and then some parameters, which is not the case here, something I forgot but I thought we would have found this kind of case earlier. Anyway its really easy to fix, I just pushed the fix in git. The script doesn't remove the gauntlet, it keeps the gauntlet alone on the title screen 2) what you really need here is a loop, simply. Well the fact is that these scripts were never meant to be that complex so the notion of block is not really defined for them for now except for the if..elsif|else...endif case. What I could do is a simplified loop without block, like the c for loop, but without block which would look like : for init test increment instruction where init would be the initalization of the loop variable, like i=0 test would be the test to run for each turn like i<=12 increment would be what is executed at the end of the loop, like i=i+4 (the i+=4 from C is not supported by the console !) and finally instruction the optional instruction to run inside the loop, which would replace a whole block, like dpoke adr+i value This would be a good compromise, not too hard to do, and it would simplify quite a lot this kind of problem, plus the loop would execute in 1 frame, here your script runs a lot of frames for its loop. What do you think ?

For the crash it was a stupid mistake, it happened only if the empty dir was not the 1st of the list ! And in my test it was, of course... ! Anyway fixed in git and for next time ! (it's a 1 line fix... !). And by the way, I didn't know some people still had some windows8 around, one of the most hated windows version ever, with windows me (millenium but it's rather old now). The part about spying the user to get ad money was added in win8, but is more and more present now, luckily there are tools to block all of this... !

Yeah I was not totally sure it would be worth it for the speed, at least it's good news for my peek function, it's not so slow after all ! And yes it's clearer with the mode variable. Thanks for the fixes, updated in git.

It's actually rather long... ! I don't have the crash here, maybe some craziness from windows which escaped me ? I'll test this again to be sure. edit : don't have the crash at all, even in wine : empty ips directory -> messagebox to tell the dir is empty, empty dir inside ips directory -> just displays the .. dir to return 1 level higher, tested in wine, same thing. Very good diagnosis indeed, it's related to the recent optimization of the scanline counter for aodk and some other games, apparently there can't be any optimization here because this unibios just uses it to count the frames !!! (it's a very unefficient way to count frames, the best way is just to add a counter in the vbl irq, if they had done that there would be no bug). Anyway, I'll revert to some more classical code here then, there was a game which produced a black screen because of this recently, do you remember which one it was, I didn't write which one it was and since I change this again, it would be better to double check. (aodk already checked and ok) Yeah you can't use game options here since it's not available until a game is loaded, but I don't like the idea to add lines in the header of the game selection dialog, there are already quite a few and I don't want a crowd here. Maybe simply as a line on top of the "preload ips dat file", a kind of "ips patches enabled globally" with a checkbox. I'll think about it. edit : done, not with a checkbox finally because they are not really convenient in the gui right now, so a classical menu with enabled/disabled displayed in text, it's easier. Setting saved in config file so it stays if you quit the emu, and is taken into account if you load a game from the command line. You're in luck because I have a similar problem here, I have a pad which tries to be clever and to autodetect what it's plugged to and then change its layout based on what it detects. It worked well until recently and was detected as an xbox pad on pc, but with linux kernel 6 it started to detect it as a nintendo console ! There are ways around that : stick to a 5.x kernel, that's what I did 1st for about 1 year, but now the old kernel is not available anymore in arch and so I can't do that anymore. So I can experiment this button swap 1st hand ! I'd suggest using the controller mapping function instead, there is only a catch there : it doesn't change anything for the gui, you still have A & B inverted there, I'll change the gui to use the normal mapping then... ! edit : actually I had a weird problem here, normally raine creates a userdb2.txt file in the config directory and then renames it in the end to userdb.txt but mine was not renamed for some reason, so actually the new mapping didn't work at all. I added an error message in case the renaming fails, but when I redid the mapping, it worked flawlessly, no error message, and the new mapping works everywhere, gui and games, so the buttons are once again in the "right" order. Oh well... at least it works, once the right userdb.txt file is created you don't need to touch this ever again anyway.

Test 1st, maybe the improvement will be almost nothing, in this case don't bother.

Ok, some little optimizations again, get them from git this time, I didn't review the whole script, stopped at the beginning of the menu (Menu Screen), but there is a big one here ! You might eventually want to try : ff0=peek($FF0000) if ff0==0 ... elsif ff0==1 ... instead of having the if peek($FF0000)==0 elsif peek($FF0000)==?? etc, the reason is that the variable version gets the peek result only once, the peek version might get it a lot of times, and functions are a lot slower to evaluate than simple variables. But you need to check if it really makes a difference by checking the misc counter when changing this, and I was too lazy to do it tonight, so it's just an idea !

The reason why your values are changed is because it's a shared ram which is mapped directly to the z80, it serves as a way of communication between the 68k & the z80. They were pretty in advance for multi cpus architecture considering it was in the 90s, but this way to communicate was probably already used in the 80s in the arcades too. For the z80 it's some normal ram. You can access it by using the z80 instead, but it obliges to do cpu z80a (to switch to the z80) poke $c000-$cfff for this shared ram, this time it's some normal ram for the z80, which means the sound command is in the word $c000-$c001. But I advise to keep the way it works now since almost all your work is for the 68k, it's just an explanation of why this ram is so weird ! So as soon as the z80 executes during a frame it reads what is there, and eventually changes the values. For the other games, well maybe, you'll see, maybe I was to careful with the whole area, but it's not a big problem anyway, if something fails you'll know where it comes from !