jetsetdanny Posted March 15, 2018 Report Share Posted March 15, 2018 Congratulations, Ian! :) ... but there's no attachment :o . IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 15, 2018 Author Report Share Posted March 15, 2018 Congratulations, Ian! :) ... but there's no attachment :o . I've just attached it - try again. :) Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted March 15, 2018 Report Share Posted March 15, 2018 (edited) Thanks, I've downloaded it :). Edited March 15, 2018 by jetsetdanny Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
Spider Posted March 15, 2018 Report Share Posted March 15, 2018 Excellent. The layout is sufficiently different to be challenging (for me at least) without extending a difficulty level too far for a 'first cavern' IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 15, 2018 Author Report Share Posted March 15, 2018 (edited) A Manic Miner bug-fix: In the Main Loop, if the CALL to draw the items at #876C is shuffled down to after the CALL to draw the portal at #879F, then this fixes the 'persistent item' in the Sixteenth Cavern: http://skoolkid.github.io/manicminer/reference/facts.html#thePersistentItem (The destination of the JUMP from the Skylab routine at #8E7E, back to the Main Loop, also needs to be tweaked to point at #879C.) This change also means that you can have items located in the path of vertical guardians, without the guardians colliding with the items and killing Willy! However, it will have the following side-effects: - White vertical guardians can collect items (as well as white horizontal guardians, which can occur in the original MM game engine); - The solar beam can collect items; - You can't place a 'hidden' item within/behind a portal - it is drawn in front of (i.e. after) the portal, whereas Willy is drawn behind (i.e. before) the portal, making the item uncollectable* (and the cavern therefore impassable!) (*Unless the portal has white INK, I guess, but that would mean that the portal would 'auto-collect' the item upon entry to the cavern, and so that item would never get drawn anyway.) Edited March 15, 2018 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 16, 2018 Author Report Share Posted March 16, 2018 (edited) I've removed the previous 'Wraparound MM' test file from my earlier post, and re-uploaded it here, after making a couple of small tweaks to the Central Cavern: - Firstly, I had messed up with the positioning of the leftmost Fire block in the top cell-row of the cavern, which was intended to stop a shortcut (going straight from the bottom of the cavern by dropping through a hole to emerge at the top). Moving the Fire block one cell to the left has eradicated that shortcut. - Also, I have relocated one of the items, so that it now sits within the same cell as an Earth block. Now Willy has to 'mine away' the Earth block - by headbutting it eight times! - in order to collect the item This is very in keeping with the 'mining' theme of the game, is another novel aspect of gameplay, and is the sort of thing I had in mind when I first devised this feature (although calling it a "new cell type" in the topic header is probably a bit misleading, as Norman has pointed out - it's more of a new application of an existing cell type). Note also that I have changed the PAPER colour of the relocated item (something which is possible in the MM game engine, though not in JSW), in order to blend it into the wall better (whilst the other items, located in Air cells, retain their original PAPER setting). Please delete the previous version of the 'Wraparound MM' test file, if you've already downloaded it, and replace it with the one attached here. ****** A few more comments on the 'headbutt' feature: - Norman Sword gets joint credit for the implementation of the 'headbutt' idea. It works like the crumbly code in reverse, with pixel-rows disappearing from the bottom upwards. Using Norman's earlier notes as a basis, I have implemented it using shared code for both crumbling and headbutt effects, feeding in a variable beforehand using the C register (translated into either an INC H or a DEC H in order to progress through the pixel-rows). - For both the headbutt feature and the crumbly blocks, blank pixel-rows at the midway point through the blocks do not cause the block to 'disappear early' (i.e. attribute change to that of Air before all infilled pixels have been cleared), so there are no 'ghosts' left behind as can happen in the original MM game engine. (Thanks again to Norman for his rewrite of the crumbly code, which fixes the 'ghost crumbly' bug via a cunning use of a looped OR operation.) - Placing an item on top of an Earth block, as implemented in the updated version of the test file, is rather similar (in an opposite kind of way!) to a trick which is commonly used in Andrew Broad's games - namely, placing an item over a crumbly block, so that Willy can't collect the item by jumping up from beneath, but has to stand on top of the block in order to crumble it away to Air, before the item can be collected. Only this time, Willy has to jump up from below to bash away the block first. - I haven't tried this yet, but I suspect that if Willy jumps through an Earth block at head-height at the correct angle (i.e. an 'Innocent-Looking Block' as they're known in the trade), then one pixel-row could be removed each time he passed through the block in that way. So you could have a quirky situation where Willy has to jump through such a block up to eight times, in order to clear it completely! (e.g. to collect an item that is embedded in it?) - Other quirky possibilities could arise if the colour attribute of a cavern's Earth blocks is matched to that of another cavern element(s). ****** Note to self: try to implement a sound effect for both headbutting and crumbling blocks (a slightly different sound for each). Wraparound MM.TAP Edited March 16, 2018 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 16, 2018 Author Report Share Posted March 16, 2018 (edited) A Manic Miner bug-fix: In the Main Loop, if the CALL to draw the items at #876C is shuffled down to after the CALL to draw the portal at #879F, then this fixes the 'persistent item' in the Sixteenth Cavern: http://skoolkid.github.io/manicminer/reference/facts.html#thePersistentItem (The destination of the JUMP from the Skylab routine at #8E7E, back to the Main Loop, also needs to be tweaked to point at #879C.) This change also means that you can have items located in the path of vertical guardians, without the guardians colliding with the items and killing Willy! However, it will have the following side-effects: - White vertical guardians can collect items (as well as white horizontal guardians, which can occur in the original MM game engine); - The solar beam can collect items; - You can't place a 'hidden' item within/behind a portal - it is drawn in front of (i.e. after) the portal, whereas Willy is drawn behind (i.e. before) the portal, making the item uncollectable* (and the cavern therefore impassable!) (*Unless the portal has white INK, I guess, but that would mean that the portal would 'auto-collect' the item upon entry to the cavern, and so that item would never get drawn anyway.) Another side-effect of the above bug fix is that shuffling the code between #876F and #879F 'downwards' seems to confuse JSWED such that its GUI doesn't display the likes of vertical guardians or the solar beam (although they appear okay in the game itself). That might be resolvable by leaving those CALLS in with, NOPping out the CALL to draw the items from #876C and inserting it after the CALL to draw the portal at #879F by other means. Edited March 16, 2018 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted March 16, 2018 Report Share Posted March 16, 2018 Ian, the 'headbutt' idea is truly great stuff. I really like this effect! It feels refreshing and it certainly allows for some interesting design patterns and challenges :D . I wish the ability to apply this feature was added to JSWED's GUI at some point... Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 16, 2018 Author Report Share Posted March 16, 2018 (edited) It isn't perhaps something for the GUI to implement, as it isn't actually a separate cell type. With the changes that I made to the MM game engine in place, any Earth block can be butted away*. Rather, I envisage it would be something that might be implemented by ticking a box on the 'Game' Menu page in JSWED (like the 'Specials by room' patch), in order to implement the necessary changes to the game engine. (* However, Norman Sword's implementation of the feature, in the JSW game engine, is switched on on a room-by-room basis, using a flag in the border byte.) Edited March 16, 2018 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted March 17, 2018 Report Share Posted March 17, 2018 It isn't perhaps something for the GUI to implement, as it isn't actually a separate cell type. With the changes that I made to the MM game engine in place, any Earth block can be butted away*. Rather, I envisage it would be something that might be implemented by ticking a box on the 'Game' Menu page in JSWED (like the 'Specials by room' patch), in order to implement the necessary changes to the game engine. The 'Game' Menu page IS a part of JSWED's GUI, isn't it? :P * This is what I meant - being able to apply it without resorting to Hex editor and any particular knowledge about code modifications. * After my having said that, you'll probably tell me that the Hex editor is part of JSWED's GUI. too :lol: . IRF and Spider 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.