Just a tip: completely removing the frame rate check isn't good. The frame rate will wreak havoc if the game is used on an OCM/Clones with both the CPU and blitter turbo modes enabled, i.e.
You can test this on openMSX by typing the following command on the console on a TR on R800 mode:
set cmdtiming broken
(plz ignore the derogatory tone of the "broken" keyword. Nothing is broken.)
Alternatively, it can also be tested on webMSX by setting the CPU to "turbo2x" and the blitter to "turbo 3x". This is closer to the OCM speed in turbo mode.
Ideally, it would be better to provide some way to set the frame limiter. If possible, separate values for the NPC animations and the game frame rate.
I do appreciate the creation of this patch. It does make movement more tolerable, however, without a frame cap, the game fluctuates in frame rate a lot, depending on how many sprites are on screen. Also, the asm patch is for generating a Lunar IPS patch which is kind of weird. In any case, the patch is great and I've converted it the format I use for my project.
@Manual
My patch doesn't include the turbo patch, but it can probably used together with my patch, I'll verify that.
@sd_snatcher
Ok yeah it's better to limit the speed. The game originally waited for a minimum of 10 vblanks, maybe 5 or 6 is better.
Making the NPC animation speed completely independent from the scrolling speed is hard; in the original version the NPC animation speed is only constant 6FPS when player is idle, when moving it's tied to the scrolling speed (which can be ~4FPS worst case)
@manimani
Indeed, the scrolling speed is fluctuating more now. In the original version the game can render the a new frame in 7 vblanks best case and 17 vblanks worst case. With my patch it becomes 5 vblanks best case / 14 vblanks worst case.
I don't know what patching tools are used outside the MSX scene, but in the MSX scene IPS is used a lot. openMSX can apply IPS patches and there are also utilities for MSX to apply IPS patches.
I don't know what patching tools are used outside the MSX scene, but in the MSX scene IPS is used a lot. openMSX can apply IPS patches and there are also utilities for MSX to apply IPS patches.
Lunar IPS is frequently used outside of the MSX scene as well, although it's a bit less common now because there's superior predecessors like BPS. In any case, it's a bit non-standard to have an asm file generate the Lunar IPS binary; usually that's generated within the tool itself. Since you're generating it in the asm file, you have a lot of Lunar IPS keywords that don't pertain the logic of the patch.
I personally use an armips forks to allow for z80 patches, though it's not a common method. I also use xkas+ for 6502 hacks. With these tools, changes are applied directly to the disk image and rom binary. The Lunar IPS patch is generated later.
The IPS patch format is a well known (and simple) enough patch format that a lot tools support it outside of the program it originated from. There's also this online patcher program from romhacking.net that supports it as well as other formats:
FuSoYa's Lunar IPS (LIPS) is just a (very good) IPS-patching and patch-creation tool, it's not where the IPS patch format originates. LIPS is only from 2003 and the IPS patch format is much older than that (1993 according to some sources I found and that sounds about right to me). Before LIPS came out there were no good GUI patching tool like that, and mostly command-line-based ones.
Now there is also Alcaro's Floating IPS (FLIPS) which is even better than LIPS, and supports byuu/Near's BPS format.
The IPS patch format is a well known (and simple) enough patch format that a lot tools support it outside of the program it originated from. There's also this online patcher program from romhacking.net that supports it as well as other formats:
