IRF

Please see the attached test file. I've implemented a teleport routine, based on John Elliott's but in this case, each teleporter has six definition bytes, in turn: Source room number Source y-coordinate Source x-coordinate Destination x-coordinate Destination y-coordinate Destination room number So, unlike in John's original routine, the exact position of the teleporter may vary between source and receiver room. Or you could have a teleport which takes Willy from one part of a room to another part of the same room. y-coordinates are specified in terms of (pixelsx2) from the top (it's probably best if these are cell -aligned i.e. a multiple of #10, although there are a couple of half-aligned examples in the test file i.e. multiples of #08, where Willy falls into or out of a teleporter); x-coordinates are specified in terms of cell-columns in from the left column. All numbers are in hexadecimal. The subroutine to implement this is at #9718-#9765 (CALLed from #8B70), and the teleporter data are stored at #9767 (number of teleporters in the game) and #9768-#97AF (12 x 6-byte definitions). As part of the new code, there is a CALL to an existing subroutine at #8E9C, which is necessary to ensure that Willy's attribute coordinates remain aligned with his pixel coordinates. Final technical detail: Each time Willy enters a teleporter, there is a CALL to the 'Play an intro message sound [and border] effect' at #96DE. I haven't defined the input (A register) going into that routine, so it picks up the previous value stored in A (which happens to be the room number of the destination room). As a result, the pitch (and duration) of the sound varies from room to room. e.g. if Willy teleports into a room with a high value for the room number, the noise has a relatively low pitch and long duration, etc. (I recommend turning off the in-game tune to observe the variations in the noise associated with the teleporters.) ****** There are about twelve teleporters inserted into the test file. They take Willy on a tour of all the 'Forbidden Holy Grounds' in the original game, and then he ends up on The Bow of his Yacht. Enjoy! Teleport+ Test File.z80

I've re-named this thread to reflect the substantive subject matter. ('Swinging Curtain' was just one example of what can be achieved with this approach.) Here is a short disassembly of the changes made to the original code to implement ropes where the horizontal position is set at the pixel level: Original code (from Skoolkid's disassembly): 92A4 LD IY,$8200 Point IY at the first byte of the screen buffer address lookup table at 8200 92A8 LD (IX+$06),$00 Initialise the seventh byte of the rope's buffer to zero; this will count the segments of rope to draw [Note that the Adjacent Ropes patch is in place to prevent overspill of the rope's definition!] 92AC LD A,(IX+$02) Initialise the fourth byte of the rope's buffer; this holds the x-coordinate of the cell in which the segment of rope under consideration will be drawn 92AF LD (IX+$03),A 92B2 LD (IX+$05),$80 Initialise the sixth byte of the rope's buffer to 0x80 (Bit 7 set); the value held here is used to draw the segment of rope under consideration (N.B. In 'Jet Set Mini', this was changed to LD (IX+$05),$01 which sets Bit 0 instead.) New code: 92A4 LD IY, $8200 Point IY at the first byte of the screen buffer address lookup table at 8200 92A8 LD (IX+$06), $00 Initialise the seventh byte of the rope definition in the entity buffer to zero; this will count the segments of rope to draw 92AC CALL $9718 Call a subroutine to initialise the horizontal position of the top segment of rope (by cell-column and by pixel) 92AF NOP x 7 [i could have used some of these NOPs for part of the subroutine, but I decided to keep it all in the same place in the test files, for ease of understanding] -92B5 9718 LD A, (IX+$02) Load up the third byte (Byte 2) of the rope definition to the A register 971B AND $1F Keep only Bits 0-4 (representing the cell-column of the top segment) 971D LD (IX+$03), A Initialise the fourth byte of the rope definition; this holds the x-coordinate of the cell in which the segment of rope under consideration will be drawn 9720 XOR (IX+$02) This bitwise XOR operation leaves the A register holding the pixel-position of the top segment of the rope in Bits 5-7, whilst clearing Bits 0-4 of A 9723 RLCA 9724 RLCA 9725 RLCA The pixel-position of the top segment of rope has been rotated round to occupy Bits 0-2 of the A register; thus A holds a value between 0 and 7 9726 INC A A now holds a value between 1 and 8 9727 LD B, A Copy the value of A into the B register, in preparation for a DJNZ loop later 9728 XOR A The A register is cleared (A=0) and the Carry Flag is reset by this operation 9729 SCF Set the Carry Flag (in light of the previous operation, a CCF operation - complement the Carry Flag - would also work here) 972A RRA Rotate A rightwards - in the first instance, the value of the Carry Flag is rotated in to Bit 7 972B DJNZ $972A The preceding RRA command is performed B number of times, which leaves the A register with one (and only one) set bit 972D LD (IX+$05), A Initialise the sixth byte of the rope definition; the single set bit is used to draw the segment of rope under consideration 9730 RET Return to the rope-drawing routine, to commence the loop (starting at 92B6) which draws each segment in turn With the above in place, if the highest three bits of Byte 2 of a rope's definition hold the value 000, then the top segment of the rope will occupy Bit 7 (the leftmost bit) of the appropriate cell-column (as specified by Bits 0-4 of Byte 2). If Bits 5-7 of Byte 2 hold the value 111, then the top segment of the rope will be drawn in Bit 0 of its cell-column. All intermediate values behave as you would expect. And of course, Byte 2 for any guardian is specified on a guardian-instance basis, so only one guardian-class is required to populate a room with ropes that have different pixel-positions.

Four bytes can be freed up in the Move Willy (1) routine, at #8E2D-#8E35, by replacing the individual checks for Jumping Animation Counter values of #10 (16) and #0D (13), with a single check: CP #09 JP C, ##8FBC That way, when Willy is in the 'ascent' phase of a jump (Jumping Animation Counter = 01 to 08), the program bypasses the check for Left-Right movement keys (Move Willy (2)), and proceeds to Move Willy (3) to move him sideways (if appropriate). Now, the checks for jump-counter values of #10 (16) or #0D (13) ensure that Willy can only land (safely or otherwise), or gain traction on, a standonable block when he is cell-row aligned (i.e. when his sprite occupies two rows). But that task is immediately replicated in the original code by the check at #8E39. So the individual checks for jump-counter values of 16 and 13 aren't actually necessary! ****** P.S. If you simply NOP out #8E2A to #8E35, then Willy can perform a quirky 'step-up jump', which allows him to land on a platform one or two rows above his sprite without overshooting it and landing during the descent phase. This can enable him to land on a Water cell platform that is located in cell-row 2, without breaching past the top of the current room and ending up in the room above! (Think of this like climbing up, rather than jumping up, a ladder.)

Geoff Mode dispenses with most of the 'Game has just loaded' routine at #8400. The entry point into the game is simply set to #87C6, where only the absolutely essential stuff is done: 87C6 F3 DI 87C7 31FF5B LD SP, #5BFF (Although I think that will leave the address #5BFF unused, with the first entry onto the stack being placed at #5BFD-FE. Using LD SP, #5C00 instead would prevent such a 'gap' being left at the base of the stack.)

I did send a message to John on this forum (before I uploaded the files here actually, out of courtesy), but looking at the message it says "Not yet read". (Unless he's read it via a notification email, but then I think that would have just said "You have a message, here is the link to go and read it", rather than giving the full text of the PM in the email?) I might email him directly about it. But before I do, I want to make sure that the changes can be applied to all six JSW64 variants.

In 'Jet Set Mini' you get an extra life for every ten items collected.

I'm not aware of such a feature in a JSW project. Of course, Manic Miner has a 'high score'.

Catching up with the Yahoo group...

I've made a few modest changes to the test file - please see the attached. I spotted a sizeable chunk of unused bytes in the code (the strange unused routine at 96F4-#9717, a relic from Matthew's original game, was remarkably still present in the JSW64 game engine!), and so I have done the following: - added the sound effect when Willy is standing in a Solar Beam (based on Norman Sword's code, but optimised by one byte by using the D and E registers instead of D and C); - added a couple of initialisation commands at the start of the game for Willy's facing direction and frame of animation (in the attached, he starts off facing left in animation frame 03, but this can be adjusted by NOPping out the INC A at #970E and/or editing the value of the operand at #9713). MM Specials with Solar Noise JSW64X v.0.01 HL 13.tap

I just watched your recording Danny. Well done on making it up 'At the Foot of the MegaTree' to reach the Kong Beast switch - I have implemented an extremely limited air supply in that room (more limited than can be achieved by selecting a value of '0' in the 'Room options' menu in JSWED!)

I should add that I can't download and watch your recording right now, but I intend to do so later. (Perhaps watching it will answer my question?)

Thanks Danny!

*Novelties*, did you mean? As well as introducing some of the new guardian variants, I would suggest any Hacklevel13 should also tidy up the game engine where known bugs occur (such as the two bugs that you fixed, following John's advice, in the 30 Years Quiz). Other things could be added, such as the patch which makes sure that Willy always starts a game facing right (in animation frame 0).

Did you see the effect if Willy heads straight for the Offy item without stopping? (The timing of the wall collapsing means that the 'Eugene' drops to the bottom, trapping Willy.)

I would argue that there is no leading zero on the 12-hour clock. Also, the fix which I came up with so that time runs out at midnight might not work if you capitalise the 'A/P' and 'M'. (Almost certainly not, in fact. It considers the ASCII values of the letter 'a' or 'p' as a binary number, and uses an XOR gate to toggle them.) I think lowercase looks better and is certainly more traditional for a 12-hour digital clock.

Mickey, Andy makes a good point in this article, you might want to consider implementing this simple fix in your 'As Manufacturer Intended' project: http://jswmm.co.uk/page/guides.html/_/jetset-willy/fixing-the-item-and-time-reset-flicker-r8 :)

Yes, by the time it starts playing the Title Screen music, you've missed the actual 'start'!

Actually, #A4C7 should hold a value of #5C at the start of the game (i.e. Bit 6 is set, marking the item as 'uncollected'). i.e. 42183, 92. It'll go to #1C (Bit 6 reset) once you collect the item. (Although having said that, restarting the game should have sorted that out.)

Have you tried making the change in the hex editor?

Hmm, strange! Is the other byte for that item correct? #A4C7 should read #1C (that's 42183, 28 in decimal).

You won't see the item, because it's still invisible! Didn't the item count increment when you dropped into First Landing? (I just double-checked the POKE and it seems to work for me.)

If you move items around using JSWED's GUI - i.e. by deleting it from the old location (above the cross) and re-adding it at the top of the ramp - then in the intervening period, JSWED will have shuffled all the other items from earlier in the item list to 'fill the gap'. Then when you add the item again, JSWED will put it at the top of the list. So that's probably what's confused you? If you get a 'fresh' copy of JSW and apply the POKE I provided, then it should do the trick?

That should be doable in a single byte change - you could in theory place it anywhere in the top half of First Landing, just by changing the value of #A5C7 (let's say to #35). As you say, if it's near the top of the ramp, then Willy will have to pass through it on the way down. So in a sense it wouldn't matter that it's invisible (although it's not ideal). EDIT: Try POKE 42439, 53. That's definitely an improvement on the 'official' POKE which moves it to The Hall, because as you pointed out, the player could be jumping to avoid the Flying Pig/arrow and miss the item, at least in theory. (Although it's extremely unlikely that they'd miss it twice - both on the way out to The Front Door, and then on the way back again! :lol: )

That's true about West of Kitchen. Higher up would be better. The problem with West Wing and West Bedroom is that there's no item shape defined, so even though it would be within reach, it would still be invisible.

Further to the above, I've had a quick look at all the rooms in JSWED. There are seven possible locations which would see the item resting on a platform after applyin a single POKE to the address #A4C7 - see the attached screenshots. In three of these, I used the square cursor to highlight the location, because (just as in First Landing) the rooms don't have a defined item graphic (although in the case of West of Kitchen, there is an unused graphic next door in The Kitchen). In those three cases, a visible item couldn't be achieved using a single POKE, because you'd also have to give the item a shape to allow it to be seen by the player. So we can probably rule those three rooms out as being 'As Matthew intended'! I'd say the most plausible locations are Tree Root - where the 'slope' of the item means that it sits nicely on the ramp - or Swimming Pool - where the additional item provides some symmetry with the existing one, although it appears to be 'floating' on the water so it would probably look better a couple of columns to the right*. (*But to do that you would have to adjust the other definition byte #A5C7, which defeats the purpose of the exercise - if we're going to edit both item definition bytes, then we might as well put the item anywhere in the mansion!)