Yeah, it's not really built for being able to vary the speed - I guess Braben was aiming for "go as fast as possible", much like Elite (which is why the latter is all but unplayable on a Master co-pro). I'll see what I can spot as I document things.
Thanks
That's the plan, although there's no easy way to diff it without releasing the whole thing. Then there's the issue of the original using obfuscated code and everything else being a pirated copy. As the aim of JASPP is to legally release games, I really should gain approval from Superior Software.
Absolutely. Can't argue with that position!
Really "run in" - or launch from the iconbar? ... https://arcarc.nl/archive/Games/Z/Zarch/
Ooh that's a different one by Richard K. Lloyd and his comments within suggest that the desktop Zarch I'm trying to dig out was an 'official', but sluggish, one.IanJeffray wrote: ↑Wed Feb 21, 2024 4:39 pm Really "run in" - or launch from the iconbar? ... https://arcarc.nl/archive/Games/Z/Zarch/
This merely raises the possibility of an anaglyph mode for an immersive 3D experience!dpsharp wrote: ↑Mon Feb 26, 2024 11:22 pm The only other issue I had was not having 320x256 (Mode 13) modes defined in my monitor definition files on modern monitors so it would sometimes default to a 640x480 mode and incorrectly render spread across the display so looking like two squashed Lander displays next to each other but that's probably easily identified and solved.
Fantastic! I'll add your fix to the branch when I get a moment, if that's OK with you. I've since removed the need to manually update the entry address when editing the code (that was a pain!), and I'll wrap your changes in Mod headers so they'll be easier to find, but this looks really easy to drop in. Thank you!dpsharp wrote: ↑Mon Feb 26, 2024 11:22 pmI wanted to see if I could get the big landscape mode running on something faster than arculator. I couldn't get the ADFFS command to get it going (probably my issue rather than ADFFS) but it didn't take much editing to fix it up the code.
Yes, please do add it to the branch and tidy up as you see fit to match your coding standards. I've updated the patch in my previous post so it should all still work under pre-RISC OS 3 machines falling back to the hardcoded screen addresses if OS_ReadVduVariables isn't available (though I haven't tested it - oh I wish I could get my MacOS build of Arculator working).MarkMoxon wrote: ↑Tue Feb 27, 2024 9:53 am Fantastic! I'll add your fix to the branch when I get a moment, if that's OK with you. I've since removed the need to manually update the entry address when editing the code (that was a pain!), and I'll wrap your changes in Mod headers so they'll be easier to find, but this looks really easy to drop in. Thank you!
Thank you! I have rolled your changes, and a call to XOS_SynchroniseCodeAreas, into the branch. It seems to work fine for me on all the main CPUs (including StrongARM) and RISC OS up to 3.7. Haven't tried my Pi yet yet, but that's next on the list.dpsharp wrote: ↑Tue Feb 27, 2024 12:00 pmYes, please do add it to the branch and tidy up as you see fit to match your coding standards. I've updated the patch in my previous post so it should all still work under pre-RISC OS 3 machines falling back to the hardcoded screen addresses if OS_ReadVduVariables isn't available (though I haven't tested it - oh I wish I could get my MacOS build of Arculator working).MarkMoxon wrote: ↑Tue Feb 27, 2024 9:53 am Fantastic! I'll add your fix to the branch when I get a moment, if that's OK with you. I've since removed the need to manually update the entry address when editing the code (that was a pain!), and I'll wrap your changes in Mod headers so they'll be easier to find, but this looks really easy to drop in. Thank you!
I saw late last night you'd made some changes to make it easier to modify without updating the offset manually though I haven't played with it yet, I've just been running the GameCode binary directly for simplicity. The self-modifying code in !RunImage will break on a StrongARM so you'll need to call OS_SynchroniseCodeAreas i.e. SWI &6E + &20000 (for the X bit in case SWI not defined on earlier machines) after the modification has taken place so that it'll run.
I did try that, but just loading the module via PreDesk made no difference at all. I then found a thread saying I had to do something else in the Pi’s SD card configuration, which I didn’t really follow, and then I wondered it I should upgrade to the latest RISC OS 5… and then I ran out of time. One for a rainy day, I think!spanners wrote: ↑Tue Feb 27, 2024 6:01 pm You could give AnyMode a go <http://www.pi-star.co.uk/anymode/>.
Hmm, that isn’t good. I haven’t managed to crash it in RPCEmu yet, but I’ll see if I can replicate that. I’ve not tried debugging in RPCEmu before. Not even sure if there’s a debugger! It’ll be fun finding out.
I think I might add a fix to prevent death until after you have started the engines. It is practically impossible to play Lander at high speed otherwise - that's one Zarch feature that's worth backporting!
It uses fuel at the same rate, it's just that everything runs at a much higher rate. Like Elite, Lander always runs as fast as it can, so each main loop iteration is the same as on the slower machines, they just take less time to complete.
I'm 99% sure it's a MacOS RPCEmu bug - I see something similar (branch through zero actually when the ship immediately explodes for me) on RPCEmu on MacOS but haven't been able to reproduce on real hardware or VirtualRPC or even RPCEmu 0.93 on Windows so have put it down to something odd with the MacOS RPCEmu setup.
Phew. I'll stop trying to make it crash on the Windows version, then.
That's interesting! I thought 118 was the highest possible value of TILES_Z, but I'm clearly wrong. I got 118 from the calculation of the z-coordinate of the back of the landscape, which is defined like this:
Code: Select all
LANDSCAPE_Z = (TILES_Z + 9) * TILE_SIZE
Code: Select all
LANDSCAPE_Z = (118 + 9) * &01000000 = &7F000000
MUL exists on ARM2, but it'd be interesting to see if using it had any impact at all on performance - I expect not.
I changed it in Zarch to MUL / MLA for completeness, but as you say it won't make the slightest difference to the speed of the game. Off the top of my head MUL / MLA were worst-case 1/2 the cycles and best case ~1/8th - I vaguely remember the calculations were quite low accuracy, 8 bit in many cases.IanJeffray wrote: ↑Wed Feb 28, 2024 7:02 pm MUL exists on ARM2, but it'd be interesting to see if using it had any impact at all on performance - I expect not.
That +9 has triggered something...is that the tile backoff value? ie the number of tiles it steps back from the ship position to start plotting the landscape?
It runs correctly on a Pi with just a little configuration... just needs a text file in !Boot.Loader folder called CMDLINE/TXT containing the word disable_mode_changes (and then reboot) and have !ADFFS loaded, all as per Jon's video at https://www.youtube.com/watch?v=HpQk1l7Rvu0
Yes, that sounds like the same thing - I've called it the "landscape offset", but "backoff value" is a good name.
Code: Select all
LANDSCAPE_Z = (TILES_Z + 9) * TILE_SIZE
= (TILES_Z - 1 + 10) * TILE_SIZE
= LANDSCAPE_Z_DEPTH + (10 * TILE_SIZE)
Just to report it works fine on a Pi running RISC OS 5.29.