IRF

I read an interview with Matthew Smith (interview conducted by Dr Andrew Broad!) in which, if memory serves [tennis pun intended] correctly, Matthew said the Cold Room items were supposed to be snowshoes, but he left out a pixel [either that or the opposite - he inserted a pixel erroneously - I can't recall which], which made the items look like tennis rackets. Andrew Broad released a 2008 Remix of Manic Miner, in which the item shape for the Cold Room was tweaked, to add/delete the said pixel. I also carried that forward into the cavern 'The Big Freeze' in the jswmm.co.uk release 'Manic Mixup'.

MtM, the penny has just dropped about what you meant by this comment!: You're referring to the need to drop down onto the items from above (after you've stood on and crumbled away the crumbly cell in which each of them is embedded). I took your comment "which way you need to approach collecting" to mean that you have to take care to collect the items in a particular order (as you do in Eugene's Lair, for example, in order to be able to reach the portal in time once Angry Eugene starts descending).

Ah, I see! The 'tennis racket' item shape comes from the Cold Room, where I interpreted them as snowshoes! But magenta snow (the crumbly cells) would be a most unusual phenomenon! Yes, I believe Andrew Broad is a tennis afficionado.

Very weird effect when I tried to pause the game - all the pixels drifted rightwards off the edge of the screen!! :wacko:

Is it the Menagerie, or is it the Cold Room? (This screen in 'Manic Panic' combines those two original caverns into one!)

Weirdly, I just completed the Normal mode of 'Manic Panic', and the screen I was referring to before - the one with load of purple crumbly cells, some of which have collectable items embedded in them, and the multiple 'blinking eye' guardians - was completely bypassed! The game proceeded from the screen with the 'spiral' layout [which, incidentally, I forgot to mention last night but which has a very nice design :) ] straight to the final screen (the one with the 'flying Eugene saucers'). I wonder if the 'purple cavern'* will come back when I playtest the Expert mode?... EDIT: Aha! I see what happened now. I had been playing in Build 4 (the one with the title tunes) when I completed Trainer mode. Then it wasn't immediately obvious how to change modes [i've since discovered you can do so on the title screen by pressing 'T', although there is no prompt on the title screen to do so], so I reloaded up the game before playing in Normal mode. But in reloading, I inadvertently went back to Build 3 (the one before the title tunes were added). It seems that Norman added an extra screen (the purple one) in between Builds 3 and 4. :thumbsup: Is Build 4 the most recent one?? It's been removed now, so no downloads of Manic Panic are available currently. (Was there supposed to be one attached to post 50, with the ability to jump off/stand on nasties removed?) *One more bit of feedback - whilst the expanded playing area across the full screen height is great for the enhanced gameplay it provides, it's slightly confusing when discussing the caverns that they don't have names with which to identify them, so that we know which is which. For example, I'm not sure which one MtM was referring to now when talking about the 'penultimate cavern' [the 'tennis' reference didn't help], since the 'penultimate cavern' seems to have changed between Trainer and Normal modes! EDIT: between Builds 3 and 4 of the game. (It's a shame that the hardware doesn't allow a cavern name to be printed in the border!)

I've had a chance to playtest the Trainer* mode of Manic Panic (*so the end sequence remains a mystery to me for now). There are some nice challenges in the game - I anticipate they will be much harder when I attempt Normal mode with its more limited air supply, and even harder still in Expert mode where a single collision with any guardian/nasty is fatal! For now, I have a question and a suggestion. My question is in regard to the final screen (the one with flying saucers moving up and down, which seem to behave like Eugene as you collect the items, only some of the guardians respond to different items being collected than others). I noticed that there are two switches in this screen, but one appears to be completely inaccessible (blocked by wall cells), whilst the other switch doesn't seem to perform any function at all? Is there some way in which either of these switches activates anything? My suggestion is as follows: The penultimate screen (the one with loads of purple crumbly cells) looks great the way that the guardians (the blinking eyes) pass through the background cells (without pixel-colliding with them, of course). I wonder whether that screen would benefit from a similar approach for the items? From their appearance on the screen, the items seem to be placed in air cells (like most items are), but if you walk through them they don't get collected - it's not immediately apparent why, but if you stand on top of one and wait, it soon transpires that the items are embedded within crumbly cells (after eight 'ticks' of the game, Willy falls through and collects the item, because 'behind the scences' the crumbly cell's pixel-rows have disappeared and then the crumbly turns to air). Something similar here to what I did in 'Manic Mixup' might look cool? i.e. In 'Manic Mixup', I rewrote the item-drawing routine so that an item's bitmap doesn't overwrite whatever lies underneath it, but instead is merged with the bitmap of its host cell. This difference in logic is only visible in cases where the items are stored in something other than air cells. e.g. there are some items located within crumbly cells in 'The Vat/The Lab', and there is one item embedded in a solid wall in the first cavern of the game [back in the Central Cavern], which is situated immediately above Willy's head as soon as you start up the game, and which can be accessed by headbutting it away from below (but if you do that straight away, then good luck with trying to complete the cavern...!) The net result is that you can identify the location of the items by their flashing attributes, but their pixel pattern is only fully revealed one pixel-row at a time, as the host cell crumbles or is chipped away. Just a thought. :unsure: EDIT: For what it's worth - though I'm probably teaching my granny to suck eggs - here is the short new subroutine which I created to draw the items in 'Manic Mixup' by merging them with their host cell's graphic: LD B, #08 loop: LD A, (DE) OR (HL) LD (DE), A INC HL INC D DJNZ loop RET Which replaces the previous CALL from #8FAB to #92D5 [those are equivalent addresses taken from SkoolKid's disassembly]. Before the subroutine is called, HL is pointed at the item bitmap for the cavern (#80B4), whilst the item's location in the pixel-buffer is assigned to DE. (The original routine, which overwrites a character space with an 8x8-bitmap, is retained as it is used for other purposes by the game, as well as being used in a subroutine as part of Matthew's 'Print a message' routine.)

I have taken the liberty of editing the title of this topic from 'The AND instruction' [as it was when started by jetsetdanny] to 'The AND, OR and XOR instructions', to reflect more inclusively the discussions of the use of those instructions in the thread as a whole. This is a good place to mention a cunning use of the OR command - namely something which Norman Sword came up with, to fix the bug in the original Manic Miner game engine whereby crumbling cells can sometimes leave ghosts. The original MM engine clears the bottom pixel-row of a crumbly cell when Willy stands on it, then shifts all the pixel-rows above down by one pixel-row, and then checks the bottom pixel-row - and if it is empty, the program considers that cell to be cleared and replaces the crumbly colour-attribute with the air cell attribute for the current cavern. The problem with that approach is if you have a crumbly cell pixel pattern with a clear (inkless) pixel-row halfway down the cell, with some infilled pixels in the pixel-rows above that blank row - then the program is fooled into turning the crumbly cell to air prematurely, leaving a 'ghost' of the uncleared pixels in the top part of the (now air) cell. Norman Sword rewrote the crumbling cell routine (as discussed elsewhere), so that all eight pixel-rows of a crumbly cell are OR'd together whenever Willy stands on the cell. After clearing the Accumulator (A register), a loop is set up to apply the OR command to all eight bytes representing the bitmaps for each pixel-row of the crumbly cell. (i.e. pixel-row 1 OR pixel-row 2 OR row 3 OR row 4 OR row 5 OR row 6 OR row 7 OR row 8). If a single pixel is infilled in any one of those pixel-rows, then the Zero flag will not be set at the end of the loop. Only if all eight crumbly rows are clear (all eight bytes which are OR'd together hold the value 00) will the Z flag be set - with the outcome that the crumbly cell gets changed to air [by changing the cell's attribute]. In Manic Mixup, I adapted Norman's code, based on the OR command, to be used both in underfoot crumbly cells, and also whenever Willy uses his hard hat to headbutt away an overhead earth block (which causes the pixel-rows to be cleared in the opposite direction i.e. the rows are shifted from the bottom upwards).

The typo MtM referred to appeared in the scrolling message on the title screen. (Now corrected though.)

It was possible (in the most recent build you uploaded, in Trainer mode) to 'disappear' off the top of the Central Cavern by jumping up off the top of one of the spiky bush nasties on the top platform. When you go past the top of a cavern in the original Manic Miner game engine [in a modified game because none of the original cavern layouts allow it], Willy's head temporarily appears at the bottom of the screen, and furthermore the attempt to draw Willy 'out of bounds' also causes corruption of the game file itself. I presume that your rewrite of the game engine has eliminated such issues though?

You mean hitting his head on the red and yellow (stripy) block? As MtM has pointed out, you just need to walk on a bit further leftwards before jumping. From your comments, I believe you must have assumed that the white square-shaped blocks act like JSW64-style Trap cells (i.e. if you step on one you fall through, even if you are also standing on a solid block with the other half of Willy's sprite). Whereas in fact, they just seem to behave like Air cells with a pixel pattern (so you only actually fall through if Willy's sprite is spanning two of the white square-shaped blocks). ** Something else which I've just noticed in 'Manic Panic' is that the Fire cells (e.g. the spiky 'poisonous pansy' bushes) are solid, such that Willy can stand/walk/jump on them without falling through - although it saps the air supply if you attempt to do that. In contrast, in the standard MM/JSW game engine, if you hack the engine to turn off the fatal outcome whenever Willy comes into contact with a Fire cell, then he will fall through Fire cells as if they are Air - with the added quirky behaviour that, even if the other half of his sprite is atop a solid block, he will still fall through both the Fire cell and the adjacent solid block. (In fact, that is how John Elliott created Trap cells in JSW64 - they are just non-lethal Fire cells.)

Nice music*, and the long scrolly message is intriguing. (*There are a few bum notes in 'Fur Elise' though.) P.S. This latest file works in Torinak, unlike the previous builds. :)

This is the bug that you're talking about; it only affects the Solar beam cavern: https://skoolkid.github.io/manicminer/reference/bugs.html#nineLivesInTheLight

These files don't seem to work on the online emulator 'QAOP' which I tend to use. I managed to get them working okay on SPIN though.

I did download the file last week and played all the introductory screens and up until the end of the Central Cavern, but didn't get chance to post yet due to 'real life' work pressures. Anyway, what I saw was excellent, and I'm intrigued by the one cavern in the first post's screenshots which I didn't manage to reach yet - the kind of Spiral Staircase affair. Thanks for posting this project, NS, and for the detailed description of the collision logic as well. I have a question: I notice that not all of the master pixel buffer is copied to the working pixel buffer during each pass through the main loop - instead, only those elements of the screen that have had their pixels changed since the previous pass are updated. I presume this is primarily to speed up the game. My question is: could the same logic not be applied to the attributes (admittedly for a more marginal improvement in speed)? i.e. Instead of copying all of the master attribute buffer to the working attribute buffer during each loop-pass, just update those parts of the screen where Willy or a guardian's attributes have changed things since the previous pass?

I'd forgotten about The Final Barrier, it's actually a good example of what I was talking about. Some of the cells in the upper half of the cavern are drawn using data that is supposed to represent Willy's start position, movement flags, fall counter, etc for the top seven pixel-rows, and the conveyor direction byte for the bottom pixel-row of the cell. In other cases, the Cell Graphics Bug causes 'classic' corruption of cells in the upper half of The Final Barrier - like you see in several rooms in JSW - where the defined attribute value inadvertently matches with a graphical byte value (one of the defined cell bitmaps). But of course, none of this is ever seen in The Final Barrier - it happens 'behind the scenes' in the pixel-buffer, but is then overwritten by the graphic from the title screen before gameplay commences. I don't think the search will ever go beyond the address #8068 that immediately follows on after the end of the cell graphics table, where HL is left pointing if the CPIR loop comes to an end without a match. So there's no danger of a scan through the whole of memory (unless a patch has been applied that is based on an unbounded search, as per Skoolkid's or J.G.Harston's methods). But I agree that it would be good to reduce the length of the CPIR loop by 9 (i.e. reduce the value assigned to BC by 09, prior to the CPIR being executed), so that the 'default' graphic for a 'none of the above' cell type can be defined and controlled, rather than the program picking up unassociated data for the purpose. That would also have the benefit that you would be able to have different coloured switches within a single Kong cavern. (The switch graphic definition uses the last slot in the table of cell graphics, and collision-detection between Willy and a switch isn't attribute-based.)

Incidentally, you can see the effect of a bounded search in action in Manic Miner (albeit that the data picked up falls beyond the intended range of the bounded search, if you insert* an attribute value into a cavern layout which doesn't match with any of the attribute or graphical bytes in the cavern's cell definitions. (*e.g. Manually via the Hex Editor, not in JSWED's GUI.) What happens is that when the CPIR loop comes to an end having failed to find a match after searching through the range of addresses #8020-#8067, HL is left pointing at the next address in the cavern buffer: #8068. The next eight bytes - #8068-#806E (various parameters which define Willy's state upon entry to the cavern) and #806F (which defines the conveyor direction for the cavern) are then interpreted as graphical bytes to draw the pixel pattern of the errant cell.

Sorry yes, not a search in the sense of looking for a matching value. I was picking up the terminology introduced by Zub about unbounded vs bounded searches, and trying to make the point that your method (like his) will only use data from within a fixed, intended range.

For reference, Norman Sword's fix for the CGB (as part of a more fundamental rewrite/optimisation of the Room Expansion routine) is listed here: http://jswmm.co.uk/topic/496-source-code-for-jsw/?p=11166 It involves a bounded search. (P.S. My tablet attempted to autocorrect that to "a bouncer search", which sounds like a plotline from Neighbours during the 1980's.)

Also J.G.Harston's 'JSW Extensions' page was updated in 2017, which seems to be when he added the CGB fix. So Stuart (Zub)'s fix on this forum seems to have been the first to be 'published' (unless you count Skoolkid's Github entry, prior to it being transposed to a disassembly update).

Can't do that in Manic Miner. If you try to jump over the portal when traversing at the lower level, then Willy doesn't land on the far side, but drops into the portal, and you have to jump back out again. (But with your modification, he would die before he got the chance to jump back out!) You could perform such a jump in JSW, but only when jumping from right to left, not vice versa.

I think the check for whether Willy has entered a portal comes before the test for a standonable (or jumpoffable) platform underneath Willy. Otherwise, Willy wouldn't be able to survive falling into the portal in Return of Kong...

For 'compare and contrast' purposes, Dr Broad's original versions of the JSW->MM and MM->JSW conversions are available within this Zip folder: https://jswcentral.org/download/02-jsw48/a/oth/party_willy.zip