A total rewrite of JSW in 48k using Matthews core code

[IRF]

Good stuff Norman!

 

Also, I like the little extra feature that I spotted in 'Master Bedroom' (although note that there's a misplaced apostrophe in it).

[Norman Sword]

If you're referring to the last game post, i think you will find it has all the correct letters and punctuation.


Just not in the right order.


 

[IRF]

And you can't go to bed until you've put them in the right order!

[IRF]

The 'homing sprites' are cool. I seem to recall that there were some sprites with odd movements in the earlier file that you posted as well (the file attached to the first post in this thread). Those ones weren't quite as devious as these latest ones though.

 

Might we look forward to seeing a disassembly of the code that creates some of these 'alternative logic' sprites? :)

 

(P.S. In case anyone missed it, I've just noticed that Norman has uploaded a new 'homing test2' file to his post #20 on the previous page.)

Edited October 21, 2017 by IRF

[Norman Sword]

Other logic besides homing.

The file that was posted from the crashed hard drive, uses a mid sprite bounce.

On horizontal sprites, one bytes of the guardians data is not used. (I think it is offset 4) e.g. referenced by (Ix+4)

On a normal sprite moving left checks for minimum, and moving right checks for maximum.

By placing a value into offset 4 the routine was amended to check this value.



Moving left  check for value (ix+4)  and reverse if matched

Moving right check the (ix+4)-1 and reverse if matched

Moving left do the normal minimum check. If minimum reverse and toggle bit 7 of (ix+4)

Moving right do the normal maximum check. If maximum reverse and toggle bit 7 of (ix+4)
 

This type of modification has no affect if no value is placed in (ix+4). 

 

So as long as the sprite data has (ix+4)=0 on all horizontal sprites, the game will run as normal.

 

Inserting a value at (ix+4) which is between minimum (ix+6) and maximum (ix+7) will cause the sprite to bounce at a mid point

 

normal movement

    >>>>>>>>>>>>>maximum<<<<<<<<<<<minimum>>>>>>>>>>maximum

 

Mid sprite bounce

>>>>>>>max<<<mid>>>>>>>max<<<<<<<min>>>>mid<<<<min>>>>>>>max<<<<mid>>>max<<<<<<<min

 

 

Easy to do. But needs to heavily modify the code.

Edited October 24, 2017 by Norman Sword

[IRF]

Thanks for that, Norman.  It's a good use of the spare offset byte.   :)

 

I presume that 'homing sprites' are much more complicated than that?  :blink:

Edited October 25, 2017 by IRF

[IRF]

Here are a few comments/queries about some of the 'changing room elements' in Norman's file from the crashed hard drive (see first post in this thread):

 

 

The 'extending/retracting' platform at the top-left of The Bathroom reminds me of the moving platform in one of the Geoff Mode patches (in 'Willy Takes a Trip's room 10: 'A Quiet Corner to Rest in'), except that in The Bathroom it has 'asymmetrical logic':

 

- After the Geoff Mode moving platform has been moved along by a cell-column in either direction, the room cell which it has just vacated is restored with an Air block;

 

- In Norman's The Bathroom, the cells to the right of the platform are reverted to Air as the platform retracts leftwards, but when the platform is extending rightwards, the cells to the left of the rightmost end of the platform remain as floor/Water cells.

 

****

 

Opening walls - I think I'm right in saying that all instances where these appear are in rooms that only contain a single item (e.g. The Bathroom, Top Landing, First Landing)? So are these triggered by watching the 'collection flag' for the item in the room? (Are the item definitions still stored in a global Item Table?)

 

In Geoff Eddy's 'Willy Takes a Trip', there's a wall in Room 53 which opens when all the items in Room 24 have been collected, but that entails re-counting all the items in the global item table during each pass through the Main Loop, so it can cause a noticeable slowing down of the game!

 

****

 

Crumbling floors - presumably these operate using a similar mechanism to Manic Miner (i.e. a check for the appropriate attribute underneath Willy's feet)?

 

However, because of the '2 bits per cell type' compression format for rooms in JSW, I would guess that the crumbly platforms have to be superimposed on top of the basic 'four element' (Air/Water/Earth/Fire) room layout, around the same time that the ramps and conveyors are added?

Edited October 26, 2017 by IRF

[Norman Sword]

Part 1

 

 

Opening walls - I think I'm right in saying that all instances where these appear are in rooms that only contain a single item (e.g. The Bathroom, Top Landing, First Landing)? So are these triggered by watching the 'collection flag' for the item in the room? (Are the item definitions still stored in a global Item Table?)
 

 

There are multiple objects in multiple rooms which have removable walls. (all the central cavern style rooms)

 

 

Matthews logic for handling objects is flawed. It works as long as the game has only a few objects. As the object count increases the logic makes the game slower and slower.

However there are ways to overcome this slow method..

1) sort the object list into room order. (done once at the start of the game). on room expansion, find the first object for the current room and store its offset. On each game loop start at the pre calculated offset and search only until no match for the current  room.

 

or

 

2) On room expansion create a list of all the keys in the current room. On each game loop search only the new list of keys.  

 

The above removes the slow key search. 

 

Next a specific check for willy. Which enables objects to pass over keys and not collect them. Also ropes and arrows.  

 

At the same time as each object is drawn it counts them, so in every room there is a counter for the total keys in the current room. It is the key counter which is used to trigger removable walls. (which could also be used as room blockers) 

 

 

The keys are still stored in the same manner. (sort off) 

[Norman Sword]

Part 2

 

 

Crumbling floors - presumably these operate using a similar mechanism to Manic Miner (i.e. a check for the appropriate attribute underneath Willy's feet)?

However, because of the '2 bits per cell type' compression format for rooms in JSW, I would guess that the crumbly platforms have to be superimposed on top of the basic 'four element' (Air/Water/Earth/Fire) room layout, around the same time that the ramps and conveyors are added?

 

The crumbling floors are similar to Manic Miner, but they can have blank lines of data and are not switched off when an empty line of data occurs on the bottom row. All the data has to be removed for the floor to finish crumbling.

The routine uses 2 bit room data only because of the evolution from the original. The data is not stored in a comparable method.

 

Crumbling floors do overlay the room data in a similar manner to conveyors and stairs. But the routines complexity is caused not by this overlaying and addition of a new graphic. But by the need to check for the position of any keys in a room and remove crumbling floors that appear in the same place. This means the crumbling floor set up routine has to expand all the keys onto the room map as well.

 

Also unlike conveyors and stairs which overwrite everything underneath them, the crumbling floors have to also check for any graphics that is present and draw around them.

In its original form the crumbling floors, expanding walls and other graphics used no extra room data. The data was contained in the 256 byte room block.

 

 

 

[IRF]

There are multiple objects in multiple rooms which have removable walls. (all the central cavern style rooms)

 

Of course, silly me! It's been a while since I played the game file, and I forgot about the Manic Miner style caverns (multi-item), where of course the opening walls take the place of the flashing portals in original MM.

 

Sort the object list into room order. (done once at the start of the game). on room expansion, find the first object for the current room and store its offset. On each game loop start at the pre calculated offset and search only until no match for the current room.

 

Funnily enough, we're working on a forthcoming project in another thread, which has all the items arranged in a particular order, and which edits the value of the 'Index to the first item' (#A3FF) as the game progresses, in order to implement a 'moveable window' looking into the Item Table. I can't say more than that right now...

 

Crumbling floors do overlay the room data in a similar manner to conveyors and stairs. But the routines complexity is caused not by this overlaying and addition of a new graphic. But by the need to check for the position of any keys in a room and remove crumbling floors that appear in the same place. This means the crumbling floor set up routine has to expand all the keys onto the room map as well.

 

Of course, placing a collectable item within the same cell as a crumbly block is a good way to ensure that Willy has to climb up to collect an item, in circumstances where he could otherwise collect said item by jumping up from below and hitting it with his head.

Edited October 26, 2017 by IRF