Resource centre for ZX Spectrum games
using Manic Miner and Jet Set Willy game engines
Archive of the
Manic Miner & Jet Set Willy Yahoo! Group
messages
|
|
|
|
|
Message: 6958
Author: rushforthian
Date: 30/11/2016
Subject: Re: Ropes and Broadsoft Lifts
> I was unaware of any interaction between ropes and lifts when I wrote JSW64MM:JB.I'll upload some example files over on jswmm when I get a chance, probably as part of a series of articles I intend to write at some point on various rope-related phenomena.
There are two categories of rope-lift interactions. A 'bug' in the code can mean that ropes act as lifts in some circumstances; that can be fixed via the 'tweaks' to the code which I suggested in my Message 6936. (The fix also 'tidies up' the code, in the sense that it prevents a theoretical Stack Overload from occurring - would you be averse to the idea of using it as the basis of an 'officially-designated' Broadsoft Lifts v0.2a ?)
However, the stuff I have been discussing in the past few days relates to rooms that have a Broadsoft lift and a rope coming into close proximity; such interactions (which might be considered a desirable feature by some game designers) would be unaffected by my suggested 'tweaks'.
I can appreciate it can't have been easy fitting each whole Bond movie into a single 'cavern'!
> The reason that all the ropes (except the one in "Quantum of Solace") are non-swinging is economy of space.
James can't progress high enough up the only swinging rope in "Quantum of Solace" to trigger the quirky interaction, because Earth cells block his way.
> The Broadsoft Lifts patch was only ever an unstable beta-release. I was aware of the following bugs:
> 1. The lifts pick the player up too early when (s)he is below them.
Do you mean "before he is above them"? In my experience, the player has to be at least level with the lift before it will pick them up. e.g. I've got a file based on original JSW, in which I've made the vertical cyan 'Printing Press' in West Wing into a lift, and I've slowed its speed down to one pixel per time-frame. With Willy stood at the edge of the left-hand platform (to the right of the red bird), flush with the edge of the platform, in his right-facing animation-frame 0, his attributes coincide with those of the vertical lift when it drops down, but he is safe from any pixel-collision (because his sprite only fills the left-hand half of his 2x2 square of cells). As the lift drops down, observing it frame-by-frame, it doesn't pick him up until the point at which it would have been exactly cell-row aligned with Willy's sprite (at which point his sprite is instantaneously lifted two cell-rows up).
However, if Willy is on a ramp, the usual rule applies that his true y-coordinate can be higher (up the screen; i.e. a lower value is stored at #85CF) than he is displayed on the screen, so in those circumstances he can be lifted up by an approaching lift that is seemingly several pixels higher than him.
Incidentally, the code can be tweaked in the way that I mused upon in my Message 6932 above. i.e. by editing the 'CP #FE' to 'CP #E0' at xHxL+#3D in the JSW48 variant. That causes a lift to 'hoover up' Willy if he is directly underneath it, shifting him up by four cell-rows to sit atop it in one fell swoop!
That would be good. Were you also hoping to make the lift carry Willy along smoothly, as if it were a conveyor? (That would probably require the addresses of the top half of the lift in the Empty Room Attribute Buffer [#5Exx-5Fxx] to be constantly updated to match the defined attribute for conveyor cells [and its previous addresses restored to Air], as well as flipping the conveyor direction byte every time the lift turns around to go the opposite way - quite complicated!)
> 2. I was hoping to make the vertical lifts carry the player down smoothly instead of letting him/her fall.
> 3. I was hoping to make the code that draws the player shift him/her downwards by the number of pixel-rows between the top of the lift's cell-row and its actual pixel-row, like when (s)he's on a ramp.
In the case of Willy on a ramp, the offset is calculated on the basis of Willy's animation-frame, but there is no direct relationship between a vertical guardian's frame of animation and its y-coordinate, so the calculation would have to be quite different.
> 4. If a lift carries the player up off the top of the screen, it actually takes him/her to the room below!
Not unrelated to one of the effects in my little project "JSW Heaven & Hell"! (Although that's a quirky rope-based phenomenon.)
I look forward to it at some point in the future!
> I'm afraid I have no plans to resume work on Broadsoft Lifts, JSW64MM:JB, or any of my old MM/JSW projects, but I hope to implement better lifts if I ever get round to writing my H* game engine...
Thanks, Ian
|
|
|