IRF

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. MM Unfixed Opening Wall Test File JSW64X v.0.01 HL 12.tap MM Fixed Opening Wall Test File JSW64X v.0.01 HL 12.tap

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?

See the comment by pgyuri in the WoS thread, and my reply: https://www.worldofspectrum.org/forums/discussion/comment/947238/#Comment_947238

Putting this here for reference: https://www.worldofspectrum.org/forums/discussion/56546/manic-mixup

The Special Edition of 'Jet Set Mini' is now available for download!

View File Manic Mixup "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'! ********** UPDATE: A minor visual bug during the title screen sequence has just come to light, which crept in because of a tweak to the routine which plays the title tune ('The Blue Danube' by Johann Strauss II). When a single note is played, only one piano key is supposed to be lit up (whereas two keys are highlighted simultaneously whenever a chord of two notes is played). The rewritten routine caused two adjacent piano keys to light up when a single note was played. This bug during the title screen sequence has now been fixed, and the corrected game file re-uploaded. This change does not alter the gameplay of 'Manic Mixup' in any way. Submitter IRF Submitted 10/26/2018 Category JSWMM Releases  

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... http://jswmm.co.uk/topic/356-file-jet-set-mini/?do=findComment&comment=6775

Skoolkid is correct that the the graphic that you see as the end product gets drawn twice (no 2 and no 3 in your list). But he omits to mention the first occasion that 'something' is drawn to the top half of the screen, although that 'something' (which never gets seen) is quite different. **** More related trivia: The attached screenshot was created by using POKE #8AAE, #C9 in order to disable the special graphic for the top half of the Final Barrier. Any attribute values in the layout of the upper half that aren't recognised as being the attribute of a defined cell type (or, thanks to the Cell Graphics Bug, a graphic data byte), cause the cavern-drawing routine to draw an apparently random pixel pattern into the corresponding screen cells. (See the 'tree trunk' in the attached screenshot, for example.) However, that pixel pattern is not random. In the event that the CPIR loop in the original routine exits without having found a matching value for the attribute value that it is seeking for, (from the list of cell definitions stored in the region #8020-#8067), then HL will be left pointing at the next byte along, namely #8068. The routine then picks up the next eight bytes #8068-#806F and interprets them as a pixel-pattern in order to draw a graphic in the appropriate cell. But the first seven of those addresses are actually the bytes which define Willy's location and movement status upon his entrance to the cavern (#8068-#806E), whilst the eighth byte (corresponding to the bottom pixel-row of the odd graphic) is the conveyor direction byte (#806F). **** P.S. In the attached screenshot, the crown of the tree and the windows of the house are examples of the Cell Graphics Bug in action. The colour-attribute written to those parts of the screen don't match with an attribute from the list of the cavern's cell types, but they do match with a graphic data byte from some of the defined cell graphics for the cavern - the wall tile definition in the case of the crown of the tree, and the 'dangling spider' Fire cell in the case of the windows. You can see part of the wall tile graphic drawn across the tree's crown, whilst the windows of the house are drawn using part of the 'spider' Type 1 Fire cell, and part of the (defined for the cavern but unused) 'stalactite' Type 2 Fire cell. P.P.S. The green and yellow grassy areas provide a perfect attribute match with the wall tiles, so the full wall graphic is drawn across the 'lawn' areas of the upper half of the screen in the attached screenshot.

That fixes the Cell Graphics Bug as well, doesn't it? (The Cell Graphics Bug doesn't actually affect any of the graphics in the original Manic Miner, but that's more by luck than judgement.) The Trivia section of SkoolKid's disassembly has recently been updated with a mention of the dubious room-drawing logic in 'The Final Barrier': http://skoolkid.github.io/manicminer/reference/facts.html#topHalfTwice

That would benefit from a rewrite to take a 'Patch Vector' approach, like Geoff Eddy's JSW games, using a spare pair of offset bytes in the cavern data to determine which special effect routine (if any) to implement.

Sorry, is that a response to my suggestion, or Norman's? Because you wouldn't have to move ANY routines to use caverns #39 and #3A. The addresses that they occupy is unused source code, you can just NOP it out and it makes no difference to the running of the program. So it would just be a case of populating it with 2048 bytes (two caverns worth) of cavern data!

Items should be okay in MM as they are specified in each cavern's data, unlike in JSW where there is a global item table.

Obviously compression of the cavern data would allow a lot more caverns, but as Norman says it would require a lot of work on the code to implement. Just to add to my two penn'orth from earlier, the two new caverns that you could create without compression, by using the spare addresses #9400-#9BFF, would have technical cavern numbers #39 (57 in decimal) and #3A (58 in decimal). You could test this out by copying data from existing 'new' caverns* into those addresses, load up the file and POKE the current cavern number (POKE #8407, #39) whilst the Title Screen tune is playing, and then press ENTER to start up the game. Things will break down once you enter the portal in the second of the two caverns! (*I would suggest something sufficiently distinctive from the 20 original caverns, so that it's clear that the 'invalid caverns' are working properly. e.g. why not choose a couple of caverns from Andrew Broad's laterally inverted version of MM? Make sure you choose two of the later caverns without 'special' features. i.e. two caverns with vertical guardians but no Skylabs, Kong, Eugene, Solar Beam or Final Barrier. Obviously you could just copy two of the original MM caverns from the higher addresses of the same game file, but then it wouldn't be immediately evident that Willy wasn't just occupying one of the regular caverns! I think that '...Mutant Telephones' and 'The Bank' would be best, because the difference in the mirrored version is obvious by the fact that the '10p' coins and the '

It should be possible to calculate a couple of 'invalid cavern numbers' which would map to the following unused areas of code: #9400-#97FF and #9800-#9BFF. That would allow you to have two extra caverns without compressing the existing ones. But you would need to edit the start of the 'Move to the next cavern' routine to get the game to access the two new caverns (and so that Willy proceeds after completing them back to the Central Cavern). As things stand, they would both be 'horizontal and vertical guardians present' caverns by default. And as you say, you would have to manually create the caverns in the hex editor, because the GUI in JSWED wouldn't display them. But you could open a new file, create the new 'invalid caverns' from scratch in the place of two existing caverns, and them copy their definitions wholesale (1024 bytes per cavern) across to the above addresses in the original game file.

POKE #8E7C, #01 has some odd effects on Willy's falling mechanism.

The check for a standonable platform underneath Willy is extending down past the secondary attribute buffer (#5C00-#5DFF) to the primary attribute buffer (#5E00-#5FFF), in the same way that the Fire cells at the top of the screen can kill Willy when he is immediately beneath them at the bottom of the screen. In the previous files, the newly-created permanent water cells are printed at the top of the primary attribute buffer, and Willy can stand on them in the same way. The change to Water comes about because Willy alters the value of the attributes for those cells by imprinting his white INK onto them. The reason that doesn't happen in the last file I uploaded is because those cells - and all the Air cells - already have white INK. (Which also explains why there aren't any items in the cavern - they were there, but get automatically collected [like the one in JSW's Swimming Pool] in the first time-frame. And because there aren't any Water cells created to curtail Willy's fall, he plummets forever!* *Except that he doesn't keep falling forever! Leave it running for a while, and eventually (after approximately sixteen descents of the whole cavern), Willy's airborne status indicator will be incremented to a value of #FF - signifying death!!

Isn't that just because there's a wall in the top row, at either side of the screen?

Please find attached another variant which I quickly knocked up - open up the file, walk left off the end of the platform, and see what happens!! MM Fall Test Four.Tap

The simple explanation for the phenomenon is that when Willy is trascending the boundary between the bottom/top of the cavern, his white INK is permanently written over two pairs of cells at the top of the cavern. That changes the nature of those cells from background to floor cells (Air defaulting to Water cells). So he can stand/land on them! A further recording which I have just created (attached here) proves the point that the second cell-row down from the top of the cavern is also turned to Water, not just the top row. Under the Portal 3.rzx

I think I see what you're getting at. I've just created another recording (attached to this post), which I think illustrates the point well: Willy falls through the bottom of the screen on the first descent, but lands fatally on the second descent when he reaches the bottom of the screen. I'll explain when I have a bit more time, but it's nothing to do with the position of either the portal or of the Water platforms! (At least, not any of the red Water platforms that are present when the cavern is initialised!) Under the Portal 2.rzx

I think it will be a case here where your posts will make more sense once I've watched the recording!

Er, there isn't a floor underneath the portal??

I think I've figured out the reason behind the "sort of" comment highlighted in bold in the above quote from Norman Sword. My first attempt at the Funeral March caused a fixed number of oscillations of the speaker diaphragm. That meant that the higher the pitch, the shorter the delay between each oscillation and therefore the shorter the overall duration of the note. As Norman said, the tune routines play each note for a fixed period, in an attempt to make each note of equal duration. However, there is a slight over-compensation involved, because in reality each execution of the Z80 operation which causes the speaker to oscillate (i.e. each XOR #18) takes a short but finite amount of time (i.e. a certain number of T-States). This is usually insignificant in terms of the overall length of the notes, but when you have an extremely high pitch note, it can start to cause a perceptible increase in the duration of the note. In the previous test file which I uploaded a while ago - 'Game Over Test 3' - I used data bytes with value #01 in the table of Funeral March notes, in order to punctuate the tune. This means that the tune routine attempts to oscillate the diaphragm during each and every pass through the inner loop controlled by the B register via a DJNZ command (that's 256 times per pass through the outer loop, controlled via the C register). The cumulative effect is that those notes are sustained for slightly longer, and the descending foot perceptively slows down at those moments in the tune when the 'silent notes' are being played. I have now created a further test file - 'Game Over Test 4' - in which data bytes holding the value #00 are used to punctuate the Funeral March, instead of #01. The oscillation of the diaphragm now only occurs once for every 256 passes through the inner loop, which is only once during each pass through the outer loop (i.e. 256 times less often than before), so the cumulative impact of the T-States of time spent executing XOR #18 commands becomes insignificant. As a result, the 'silent notes' are of roughly the same duration as the notes of intermediate pitch, and therefore the foot descends much more smoothly (at an even pace) down the Game Over screen. I have attached to this post both of the files referred to above, for convenient comparing and contrasting of the Game Over sequence. Game Over Test 3.z80 Game Over Test 4.z80