Jump to content
Jet Set Willy & Manic Miner Community

IRF

Contributor
  • Posts

    5,105
  • Joined

  • Last visited

Everything posted by IRF

  1. Good stuff! I feel that Pgyuri (or is it Pyguri?) from the World of Spectrum forum deserves a mention, for having come up with the original 'dark cavern' idea 💡 which inspired the 'Lantern' and 'Torch' game modes of this project - although of course Mr Sword has refined the idea greatly and made the dark caverns infinitely more playable! 👍
  2. If Manic Panic has reached the status of 'finished product', I wonder whether it would have a higher profile if you were to upload it to the Downloads section of the site (which should automatically generate a new discussion topic as well), rather than putting it at the end of the existing 'Playing Around' discussion? Just a thought..
  3. The start of the Move Willy(3) routine (#8FBC-#8FD0) could be simplified/shortened: Within that part of the routine, Willy's Direction and Movement Flags variable (#85D0) is loaded up to A twice. (First to check if he's moving left or right - Bit 1 - and RET to Main Loop if he isn't; then to check which way he's moving, left or right? - via Bit 0 - before deciding which path to proceed through the rest of the routine.) But in between those two checks, the Rope Status Indicator (#85D6) is loaded up to A and its value tested (with a RET to Main Loop if Willy's on a rope). If the test of the rope status is put first in that sequence, before the movement/direction flags are loaded up to A, then you could test Bits 1 and 0 of A in turn (reacting accordingly) via BIT instructions, thus removing the need to reload #85D0 into the Accumulator for a second time. That should provide a modest saving of three bytes.
  4. When Norman is back and picks this up, I wonder if he would be amenable to Daniel Gromann creating an entry for some future update of his website jswcentral.org for 'Manic Panic'? The many novelties in the project mean it's definitely worthy of an entry!
  5. In response to the suggestion in bold, I've taken a look at what it would take for Willy to be able to observe the portal guardians from a 'leap of faith' vantage point at the top of the relevant caverns (Cold Room and Return of Kong). For the Cold Room, the torch beam would have to extend downwards by at least 16 character-rows below Willy's feet; for Return of Kong, it would need to reach 14 rows down. By way of comparison, the beam currently reaches a depth of 9 rows below Willy's feet (and a height of 10 rows above his head when pointed upwards). So the torch beam would need to be much 'stronger' in order to resolve the 'leap of faith' issue. But that might disturb the current aesthetics a bit too much? **** Sounds like the cavern roof is leaking... That gives me an idea for an advanced modification - water slowly flooding a cavern from the bottom up, one character-row every minute or so (or maybe even a pixel-row at a time)... If Willy goes under the water (e.g. to reach the portal at the end), then the air supply depletes super quickly! Anyway, that's an idea perhaps for another day - happy summer to you too!
  6. I think his username is Pgyuri, not Pyguri. (A typo which I was guilty of myself last night!) He did do a variant where you can set off a 'flare' - only five of which are available per cavern - if you press a certain key it sets the Screen Flash Counter variable to 7, so that all the visible screen elements cycle down from white to black (like what happens when you gain an extra life in the original Manic Miner). That effect allows you to survey the whole cavern for precisely seven time-frames of the game, which does make it slightly more playable/less insane. (Nowhere near as playable as it is with Normans Sword's Torch beam though.) I wonder whether it would be worth 'borrowing' the flare idea to cover the few scenarios where the torch beam doesn't reach far enough. e.g. when dropping down into the open portal from the top of caverns such as the ones based on the Cold Room and Return of Kong. In both of those scenarios there is a horizontal guardian which intermittently either goes through the portal [Cold Room penguin], or passes the portal just above it [rolling rock in Return of Kong]. In Candle Mode it's pure guesswork when dropping down as to whether you're going to hit the guardian or not before you manage to reach the portal! Setting off a flare before you make the drop could help you to get the timing right.
  7. I wasn't suggesting anything needed changing with the blue conveyor, just thought it was worthy of a mention. As you say, it would be impossible to iron out every logical inconsistency. Another example: in the attached image, it could be argued that the red crumbly cells at the top right shouldn't be illuminated by the torch, considering that Willy is positioned behind a solid wall and floor at that moment in time. But trying to make the logic of the torchbeam's illumination contingent on the room layout surrounding Willy's current position would be a nightmare to implement! Anyway, you've done a great job expanding out Pyguri's concept of the torchlit caverns. :)
  8. I forgot to say that the question of whether or not the air supply depletion is paused (because Willy isn't moving), in the recording referred to above, follows the same pattern. i.e. Air continues to be depleted when Willy is only prevented from moving because he is blocked by a wall, but isn't depleted in all the other scenarios: when Willy turns on the spot, or jumps or drops vertically onto a conveyor whilst the 'upstream' key is pressed. Again, the discrepancy has been resolved in MP13.
  9. One more short recording, to demonstrate a (harmless) visual quirk I noticed in Torch Mode. See the conveyor above Willy's head when the torch beam is rotated to certain angles. Some portions of the conveyor seem to be colour-inverted compared with the rest of the conveyor. I think this is because the normal colour setting for the conveyor in question is black INK on blue PAPER, but in Torch Mode everything that isn't lit up by the torch beam is rendered in blue INK on black PAPER. MP12 Conveyor Animation.rzx
  10. If Willy is trying to walk up a conveyor but is stopped by a wall, he is technically still moving sideways (the Movement Flag is set). As distinct from when he jumps or falls vertically onto a conveyor with the 'upstream' key kept pressed, or when he does a 'turn around on the spot' manoeuvre on a conveyor. The attached recording was done whilst playing MP12 in Candle Mode. The first time Willy is on the conveyor, with the Right key depressed but up against a wall, I tried to rotate the torch beam using H-J but failed. Then I let go of the Right key and immediately pressed it again (then kept it depressed). Willy turns round on the spot and stays put. This time I could rotate the beam using H-J keys. I then made Willy fall onto the conveyor with the Right key depressed, and again I could rotate the beam. A bit later in the recording I jumped vertically up onto another conveyor, with the Right [upstream] key depressed, and once again I could rotate the beam. It's good that you have resolved the discrepancy between the different scenarios, in MP13. :) MP12 Conveyor Torch Rotation.rzx
  11. Thanks for the latest (final?) file, Norman! Having seen it in action, I can now answer my own questions in red:
  12. Regarding the above oddity, I've been back and checked and that was the case in the earlier Manic Panic files as well, I just didn't notice it at the time. **** Back on the subject of rotating the torch beam, if Willy finds himself on a conveyor belt standing still (e.g. if you fall onto a conveyor whilst keeping the 'upstream' sideways movement key depressed, so the keypress and the conveyor cancel each other out), are the rotate keys active whilst Willy remains stationary on the conveyor? I presume the answer is yes, because the sideways movement flag isn't set in that situation, even though a Left-Right movement key is being pressed by the player.
  13. Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?
  14. To be clear, I wasn't suggesting that Willy should automatically look downwards when he falls down a shaft. I just wondered whether the player retains the ability to rotate the torch beam whilst he is falling. I would have expected that this would not be possible in your earlier test file (described in post #164 of this thread), where you had forced the beam to face forwards based on Willy's facing direction AND based on his jump/fall counter*. But I would have expected that it would be possible to look down whilst falling in the later test file (described in post #166), where you only tested Willy's facing direction and not the jump/fall counter to decide whether to force a sideways beam. It sounds like you have proved me wrong on that point? (*Actually, there are two separate variables involved in jumping. There is a joint variable for Airborne Status, which is reset to 00 by default, holds 01 when jumping, values from 02 upwards when falling - acting as a Fall Counter - and is set to -01 [#FF] as a 'Willy is dead' indicator. And a separate Jump Counter variable which keeps track of Willy's progress through a jump. I presume the former is the one that we're talking about in terms of what you were testing at one stage, to determine whether to make the torch beam face forwards?)
  15. It is also not possible to look all around whilst Willy is being moved along by a conveyor, where you might expect* him to be able to do so. That would probably require a fundamental change in logic, with the check for Left-Right keypresses temporarily disabling the check for Clockwise-Anticlockwise keypresses. i.e. the basis for being unable to rotate the lamp wouldn't be "Is Willy moving sideways?", but "Is the player actively moving Willy sideways?" (*Then again, logic would dictate that his legs shouldn't animate in that scenario either, as you pointed out elsewhere a while ago.)
  16. Perfect! Hopefully also means that when falling from a great height into the portal in Return of Kong, you can turn the beam mid-fall to point it towards the portal. (Whereas in the previous version, with the additional check for the airborne status, the beam might have stubbornly reverted to point sideways?)
  17. Will the latest change mean that if Willy points the beam straight upwards, then does a vertical jump, the beam will still point straight upwards? Because in that circumstance - if you're trying to inspect what is located a few character rows above Willy - you wouldn't necessarily want the beam to automatically align left or right to match Willy's facing direction. Sorry if I'm being picky!
  18. I noticed it when doing a certain manoeuvre to collect the item on the right, halfway up the Central Cavern-style room - jump right off the crumblies, then before landing hit left+jump to perform a 'turnaround and jump straight up' to collect the overhead item, before proceeding to jump left onto the conveyor (and then onwards to the spiky bushes/clockwork robot, etc). I was expecting the beam to turn around at the moment Willy turned around, but because he does a vertical jump to get the item, during which he isn't actually moving leftwards yet, he was left facing into the blackness before I nudged him left. If that doesn't make sense I could do a quick RZX recording to illustrate.
  19. I've noticed a glitch with the way that the torch beam works. Say Willy is standing still, facing rightwards. If you nudge the Left key once, to turn Willy around, his beam still points rightwards. Only if you nudge Left again to make Willy walk one pace leftwards does his torch beam turn round to match his leftwards facing direction. (And vice versa.)
  20. I see what you mean (from the old 'rotate' file) about the items having an incongruous background in the 'non-black' rooms - now fixed.
  21. Lantern and Candle modes are fab! Especially in the likes of the Cold Room where the background PAPER setting isn't black, so it really shows off the rotating torch beam. B)
  22. That would certainly help. (Air supply static while Willy is static.)
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.