I would just add that the T-state overheads are higher for setting up a greater number of parameters prior to the loop, in the case of LDIR. But of course that is outweighed by the faster loop (Unless the loop is very short e.g. The LDIR method at #8684-90 in Manic Miner wouldn't be much faster overall).
At #8828-34 and #88B8-C4, the LDIR method of editing the attributes of a character row can be replaced with a simple loop which uses the LD (HL), xx command. The latter approach comsumes fewer bytes, employs fewer registers and is probably marginally faster. EDIT: I removed that latter point, in light of Norman Sword's comments below.
e.g. the original code at #8828-34 requires 13 bytes:
LD HL, #5A60
LD DE, #5A61
LD BC, #001F
LD (HL), #46
But the same thing could be achieved in 10 bytes:
LD HL, #5A60
LD B, #20
LD (HL), #46
The LDIR method for copying the same value across multiple addresses is only necessary when updating #100 bytes or more, which is beyond what a single register can keep track of (e.g. see #8813-27).
When updating fewer than #100 (256) bytes, LDIR is only necessary if different values are being copied across to the individual addresses (e.g. #88FC-#8906).
many thx, not quite sure what you mean per cell?, so it can be more then four?
Air supply is normally decremented once per time-frame (i.e. once per pass through the Main Loop). If the solar beams passes through Willy, it is usually decremented nine times per time-frame (the usual once, plus 4x2= eight extra), because Willy usually straddles two cell-rows.
But if Willy happens to be jumping at the time that he passes through the solar beam*, then at certain points during the jump when he isn't cell aligned, he is straddling three cell-rows (i.e. character rows) on the screen. In those instances the air supply is decremented 13 times per time-frame (1+4x3).
(*Unless the part of the solar beam through which he is passing is horizontal at the time - Willy never occupies more than two cell-columns.)
I was looking at the code which implements opening walls in the JSW64 game engine.
The way the existing code works, the pixel-rows disappear from top to bottom, and then the attributes of the blocks are turned from Earth to Air. However, if you have a opening wall which is several blocks high, none of the blocks get turned to Air until the whole wall has had its pixels cleared. So you can temporarily have an INKless wall, several blocks high, before the whole lot turns to air.
Having scrutinised the pertinent code, and thinking out loud, I wonder if the original intention was for each block in turn (from the top one down) to turn to Air as the eight pixel-rows of each are cleared. A simple single POKE can be used to achieve this - and it involves reversing the conditionality of a relative jump (so a simple mistake by John Elliott when writing the code might explain the way the feature ended up, if my hunch is right that they were intended to disappear one-by-one).
Have a look at the two test files attached. They illustrate the difference between the two variants of opening wall mechanics. The opening wall in the 'unfixed' file behaves exactly the same as in the unpatched JSW64 game engine. In the 'fixed' file, I've changed the value of address #FFD9 from #20 (JR NZ) to #28 (JR Z).
Willy starts off in the Off Licence. Collecting the single item in the room causes the wall to start opening. I've come up with a little challenge based on the different behaviour of the opening wall - only in one of this pair of files is it possible for Willy to leave the room and access The Bridge.
EDIT: Both files have been updated, with the addition of an extra Fire cell to prevent an (unintended) loophole.
I like the portal feature; it's a bit like saving snapshots in SPIN, except that the author (yourself) has some control over where the player is 'allowed' to save their progress. (There's nothing to stop the player saving their own snapshots, of course, but this allows the player to complete the game without 'cheating' in that way, yet without having to go back to the start of the game repeatedly.)
It would also be a very handy feature for anyone playing the game on a real Speccy, where saving snapshots isn't an option.
What is the significance of the yellow sprite that appears on the status bar in, for example, the Banyan Tree in this project? It looks like an arrow hitting a target, or a dartboard?
System: Sinclair Original Author(s): Matthew Smith / Andrew Broad Third Party Author(s): Ian Rushforth & Andy Ford
"Times are tough for poor old Willy. Decades of excessive partying have taken their toll on his finances. Despite already having downsized his mansion in 'Jet Set Mini', he is finding it increasingly difficult to afford the cost of maintaining his home, and keeping his formidable housekeeper Maria in the style to which she has become accustomed!
And so, after dusting down his trusty hard hat, Miner Willy descends back into the subterranean realm where he first made his fortune 35 years ago. Emerging into the Central Cavern, he soon notices that things have changed somewhat since the last time he ventured down here..."
'Manic Mixup' is a remix of Matthew Smith's classic ZX Spectrum 48K game 'Manic Miner', and is released in 2018, 35 years after the original game. It can be played on a real Spectrum, on the Sinclair ZX Spectrum Vega/Vega+ or on a computer, games console or another device using a ZX Spectrum emulator.
The starting point for 'Manic Mixup' was an amalgamation of two projects by Dr Andrew Broad: his laterally-inverted version of 'Manic Miner' ('reniM cinaM') and Andrew's 2008 remix of 'Manic Miner'. Into this melting pot was poured a cluster of newly-designed special features, making 'Manic Mixup' quite unique amongst games based on the MM game engine.
Thematically, 'Manic Mixup' is a sequel to the authors' previous game 'Jet Set Mini', which was a modified version of 'Jet Set Willy' - that in itself being Matthew Smith's sequel to 'Manic Miner'. What a mixup!
All of the original caverns (and their perilous occupants) have had an overhaul in 'Manic Mixup', and the in-game music has been significantly enhanced. Furthermore, nearly all of the routines in the 'Manic Miner' game engine have been rewritten or redesigned for this project, for various reasons: to provide additional functionality (such as new sound and visual effects, and additional gameplay elements - including putting Willy's hard hat to good use!); to increase the efficiency of the code; and to fix various bugs in the original game engine.
However, the essence of this 8-bit, 48K game will be very familiar to devotees of 'Manic Miner'. We hope it gives you 'unalloyed pleasure'!
I've added the introductory 'back-story' to the first post of this release topic (and to the download page). New game file (the Special Edition of the game, with enhanced Title Screen music) to be uploaded this Friday...