[File] pyramid.tap

[geoff]

pyramid.tap

View File

---

Hello peopleses,

 

Those of you with long memories may recall that many years ago I informed Dr. Broad that I had been doing some sporadic work on "Willy does the Great Pyramid". What actually happened was that the game wasn't happening and had ground to a halt, and I ended up leaving it in limbo. Recently, however, thanks to - ahem - medical factors, I found myself with some Copious Free Time, and after acquiring some round tuits, I returned to the Pyramid and bashed it back into shape. This is the result.

Speculation about any aspect of the game is welcomed, encouraged even. I'm not going to spell everything out beforehand, since I rather like the idea of watching you all explore it in the way we all did when JSW originally came out 🙂 Hacking is permitted, but I think to avoid spoilers it should be conducted in a separate thread.

And finally: MegaTree-sized thanks to Daniel Gromann and Ian Rushforth for their invaluable help in play-testing and fixing, without which the Pyramid would be undoable. I hope you enjoy it.

---

• Submitter
  geoff
• Submitted
  03/27/2021
• Category
  Jet Set Willy [Remakes]

 

[IRF]

I've just discovered that the game was mooted here on Dr Broad's site, back in the day:

https://www.oocities.org/andrewbroad/spectrum/willy/list.html

Geoff Eddy has (according to Daniel Gromann on 12th August 2006) been "working sporadically" on Willy does the Great Pyramid, which "may appear for real sometime in the next year or so..." On 9th October 2006, Geoff himself told me: "At the moment all 64 rooms have been designed, complete with items, and I started placing the guardians. That was a few months ago, and due to my lack of both CFT and inspiration, I haven't done anything else since. I was wondering if anyone might want to have a look at it and finish it off, or suggest patch vectors and the like."

Edited March 27, 2021 by IRF

[jetsetdanny]

The fact that some authors return to their unfinished games and complete their projects after a looong time since starting them, or that some authors return to the scene with new games after many years of absence from it, is a great thing about JSW games! Geoff's return with "Willy does the Great Pyramid!" is a prime example. Thank you for this great game, Geoff, and I hope that it won't be the last game from you that we'll be able to enjoy! 🙂 

[jetsetdanny]

Geoff,

Have you announced the release on WoS or Spectrum Computing yet? If not, would you like any assistance with it? (if for whatever reason you don't want to announce the game there yourself, I can do it for you).

Another question: how would you classify "WDGP"? All of your games released previously are traditionally classified as using "Geoff Mode". The first three (J4 (The Fourth Remix, Willy the Hacker and Willy Takes a Trip are considered to use "Geoff Mode I", while "ZX Willy the Bug Slayer" is the first game to use "Geoff Mode II".

How would "Willy does the Great Pyramid!" fall into this classification? Is it "Geoff Mode II" perhaps, or maybe "Geoff Mode III"?

I am planning to create a page for it on JSW Central in the near future (time permitting) and I would like to know how to describe it. Incidentally, it will be game #50 on the list of new games using the JSW48 game engine! 😁

[IRF]

I would say Geoff Mode III. The Patch Vector system is implemented differently for a start. (There are both Room Setup and Main Loop patches, each of which only uses a single offset byte in the room definitions.)

[geoff]

I prefer "Pyramode" myself...

[IRF]

On 3/30/2021 at 9:04 AM, IRF said:

I would say Geoff Mode III. The Patch Vector system is implemented differently for a start. (There are both Room Setup and Main Loop patches, each of which only uses a single offset byte in the room definitions.)

Further explanation: In Geoff Modes I and II, a Main Loop Patch Vector for each room is stored (as a two-byte word, giving the location of the start of the room's patch) at Offsets #EE - #EF in the room definition.  A subroutine is CALLed from the Main Loop which loads up the Patch Vector to the HL register-pair and then flow of execution jumps to the patch, via a JP (HL) command.  (If a room doesn't have a patch, then the Patch Vector just points at a RETURN command.)

In Geoff Mode III (a.k.a. 'Pyramode'), each room has a Room Setup Patch Vector and a Main Loop Patch Vector, but still only two offset bytes (#EE and #EF) are used in the room definition.  Offset #EE corresponds to the Room Setup Patch Vector and Offset #EF to the Main Loop Patch Vector.  The actual Patch Vectors are stored in a lookup table which starts at #8600.

Subroutines are CALLed from the Room Setup routine and from the Main Loop, which pick up the value stored at Offset #EE and #EF respectively for the current room.  That value is then used as an index to point at the appropriate place in the lookup table at #8600.  Since each entry in the lookup table is a word (pair of bytes), the value taken from the Offset byte is doubled so that each incrementation of the value skips forward two places in the table.

Once the correct Patch Vector (entry in the table) has been identified, the same approach as Geoff Modes I and II applies. i.e. the value is loaded up to HL, and then flow of execution proceeds to the appropriate patch via a JP (HL).

 

I believe the above provides a sound body of nomenclature for the Patch Vector system (though perhaps Geoff may wish to comment?)  In other words, the Patch Vector for a room is simply a means of pointing the programme towards the Patch for the room - it tells you the location in memory where the actual patch is stored.

Under the above arrangement, it would not be correct to say that only certain rooms have a Patch Vector, whilst other rooms don't: in Geoff Modes I and II, all rooms have a (singular) Patch Vector - even if, for some rooms, it merely RETURNs flow of execution straight back to the Main Loop without doing anything - whilst in 'Pyramode', all  rooms have precisely two Patch Vectors (Room Setup and Main Loop).

Similarly, it would not really be meaningful to say "Room X has a nice Patch Vector".  For example, if Room X has a nice, non-standard visual effect, or a guardian with an unusual trajectory, or whatever - implemented via the Patch Vector system - then what you're really talking about there is a Patch.  So it would be more logical to just say "Room X has a nice patch"!

At least, that's how I see it anyway. 🙂

Edited April 1, 2021 by IRF

[Norman Sword]

Misuse of terminology.

The data held for each room does not contain a vector (jump address) it contains an index number. The index number is used to index into a jump block and from there an address is extracted.

The usage of jump blocks to store a list of address's for routines is used in several operating systems and is nothing new.

However in the context of JSW the usage of using an index number to index into a jump block was used 36 years ago in JSW2.

Here an index number was obtained from the room data (event data) and that number was used to index into two tables . The first table was a list of initialisation routines for the event. The second table was a list of Main Loop runtime routines for the event.

So you are using a primitive version of JSW2 event processing

[IRF]

Thanks, Norman. It looks like I was on the right track. 🙂 The table I was referring to in 'Willy Does the Great Pyramid' is the jump block (I wasn't aware of that term).

However, in Geoff's older games, the patch data for each room was indeed held in the form of a vector (a two-byte jump address within the 256-byte room definition).

I suppose it would be possible to compress the current two Offset bytes (one each for a Room Setup patch and a Main Loop patch) into a single Offset byte - using the upper bits to index the Room Setup patches, the lower bits for the Main Loop patches, and extracting out the appropriate bits to obtain the indices into the jump block (or jump blocks plural - the Room Setup and Main Loop patches are intermingled in '...Pyramid', I believe, but they could be held in two separate blocks).  That would be possible because there are fewer than eight Room Setup patches in '...Pyramid', so only three bits are needed to account for those; and there are fewer than sixteen Main Loop patches in the game, requiring only four bits.

P.S. I've seen use of jump blocks in the JSW64 game engine as well, to deal with moving and drawing the various guardian types (there are many more types of guardian in JSW64).

Edited April 1, 2021 by IRF

[jetsetdanny]

Four comments have been posted so far under the YouTube version of the walkthrough of "Willy Does the Great Pyramid!". They are worth reading. Two are very positive, one is a question about the in-game tune and one is negative (but not directed against this particular game, but against "Miner jet set mods" in general).