[File] JSW 128 VK3.Tap

[Norman Sword]

All objects should be now collectable. I have moved the one in "West of Kitchen"

127 rooms now have an object to collect

Only "Entrance to Hades", has no object.

To edit the game and change the layout or item position, is no more difficult than any edit using the standard edit programs.

;------------------------------   When writing the game  ------------------

The repeated editing eventually wore me down. On every edit it must be remembered to put the arrows last. Fine, but a quick edit and putting an extra sprite in here or there, necessitates moving the sprite order around. So easy to forget, when it was just a quick edit.

For the above reason, I added a routine to sort the sprites at run time. (just for the arrows) so every room is checked for sprite order, and pesky arrows are automatically moved to the last sprite slots. The routine was meant to be removed, but it uses only 60 bytes and saved me so much time on needed re-ordering, it was left. (having checked the present data, it has little effect - no arrows collide with sprites in the rooms it has need to re-order )

 

[jetsetdanny]

To Norman Sword:

 

Thank you for your splendiferous, rocambolesque, scrumdiddlyumptious reply to my question!

 

And thank you for Version K3. It is much appreciated :).

 

Another question: I would like to add your game to the list of JSW games on JSW Central. Would you agree that a new category should be created for it, as the changes introduced are so numerous that they make it hard to consider it a game using the original Jet Set Willy (JSW48)  game engine?

 

If this is the case, would you have any suggestions for the name of game category? So far the list embraces the following ones: I. Manic Miner (MM), II. Jet Set Willy (JSW48), III. Jet Set Willy II, IV. Jet Set Willy 128 (JSW128) and V. Jet Set Willy 64 (JSW64). It would be good to differentiate the name of your game engine from the already existing Jet Set Willy 128 (JSW128). Any ideas?

 

 

[Spider]

I concur thank you for the updates. :) The changelog is also an excellent read to see what relevant changes were made between each release too.

[Norman Sword]

I made a statement "WORLD'S FASTEST" in one of the screens on JSW128 VK

So here I will justify the claim, and add some data.  The Timing quoted  for all versions is the time taken to do the same double room walk. 

The double room walk,  is the walk through "The Kitchen" and then through "West of kitchen"

Times are displayed to 100th of a second. Whilst the timing is accurate, my reactions varied a lot.

Since music only slows this down, all times are without music.

The T-states quoted are the times needed to copy one byte from memory and move it elsewhere.
This timing is needed because the slowest part of the game is the huge amount of data copied on each and every game loop. It is these copies which have one of the largest influences on how fast the game runs.

(an edit to revise and hopefully lay out this data in a clearer manner revision done 21st October 2024) 

Matthews unmolested code using LDIR   - each byte taking 21 T-states - manual timing to do the Double room walk -  19.96 to 20.12 rounded up to 20.00 seconds.
LDIR 21T-states - WALK 20 seconds

My code changed back to using ldir's is comparable in time, which considering all the extra routines, is to be expected. - 20 seconds
LDIR 21T_states - WALK 20 seconds

My code using a long line of LDI's ---- each byte taking 16 T-states plus a small overhead -
15.46 seconds.
LDI 16 T-states - WALK 15.46 seconds
 
Mark Woodmass posted a "marginally faster" versions of Manic Miner and Jet Set Willy to alt.binaries.comp.sinclair on 27th January 2002 - his version of jsw does the double room walk in 15.51 seconds. Mark Woodmass uses a stack copy routine and it also destroys the rope routine. (e.g. it is bugged)
STACK COPY 10.5T-states - WALK 15.51 seconds
 
Mysterion posted his Turbo versions, so I will list the times from his versions. These use a stack copy method and the 128k, increase in speed is achieved by rolling the code out further. Matthews code using Mysterion Stack copy --- stack copy has a theoretical minimum of 10.5 T-states, but the overhead is quite high two sets of timing - 13.71SEC IN TURBO JSW IN 48K and 12.14SEC IN TURBO JSW IN 128K
STACK COPY 10.5T-states - WALK 12.14 seconds in 48K
STACK COPY 10.5T-states - WALK 12.14 seconds in 128K

My code . These are the speed of my stack copy routines -
STACK COPY 10.5T_states - WALK 10.61 in 48k
 
This is 3.1 seconds faster than Mysterion's version in 48k
My version in 48k is still 1.43seconds faster than Mysterion's version which is rolled out and will waste quite a large chunk  of the 128k of ram needed.

So yes  "WORLD'S FASTEST" (At the time)

NOTE the timing depends on the individuals response to the change of screen and partially to the machine it is being tested on. The times I list are consistent with the machine and hardware I use. (others will obtain different timing) however the overall trend will still be as above.

Addendum concerning Speed and T-States

From the above it is easy to see the relationship between the double room walk time and the T-State's for the method used to do the screen copying.

LDIR                21   T-states     20     seconds
LDI                  16    T-states    15.46 seconds
STACK COPY 10.5 T-states    10.61 seconds  

 

Edited October 21 by Norman Sword

[IRF]

I actually find it difficult to progress by a single frame of animation (a useful manoeuvre in some tight* spots) because the game engine is so fast, and therefore so sensitive.  For that reason, it is very useful that you provided the ability to slow the game down (using the K or L key, the other key speeding the game back up again - I forget which is which).

 

(* No pun intended on the former use of the Bear Brand Factory that was discussed earlier!)

[Norman Sword]

I walk into the "banyan tree" room, slow it down to the slowest setting and then can pass through the room nearly every time, at the first attempt. Something I can not manage when I play the original.

I will time the slow speed. ----- It is timed at  25.93 . So the slow setting is around 25%+ slower than the original....

so a 25%+ reduction in speed makes it so much easier.  And a doubling in speed makes the traversing a lot faster.

[IRF]

The ability to slow the game down would be useful for the room 'The Garden' in JSW2 [original version], the crossing of which requires a succession of well-timed, pixel-perfect jumps.  :o

[Spider]

The ability to slow the game down would be useful for the room 'The Garden' in JSW2 [original version], the crossing of which requires a succession of well-timed, pixel-perfect jumps.  :o

That is quite tricky due to the conveyor floor :) It is something that I can manage myself (yes, really!) so I guess its not hard more as you say a question of careful timing.

[Norman Sword]

edited extract 

 

The Timing quoted  for all versions is the time taken to do the same double room walk.

 

The double room walk  is through "The Kitchen" and then through "West of kitchen"

 

Times are displayed to 100th of a second. Whilst the timing is accurate, my reactions varied a lot.

Since music only slows this down, all times are without music.

 

The T-states quoted are the times needed to copy one byte from memory and move elsewhere.

This timing is needed because the slowest part of the game is the huge amount of data copied on each and every game loop. It is these copies which have one of the largest influences on how fast the game runs.

 

Matthews unmolested code using LDIR   --- each byte taking 21 T-states

19.96 to 20.12 rounded up to 20.00 seconds.

 

My code changed back to using ldir's is comparable in time, which considering all the extra routines, is to be expected.

20 seconds

 

My code using a long line of LDI's ---- each byte taking 16 T-states plus a small overhead

15.46 seconds.

 

Mark Woodmass posted a "marginally faster" versions of Manic Miner and Jet Set Willy to alt.binaries.comp.sinclair on 27th January 2002

his version of jsw does the double room walk in

15.51 Mark Woodmass uses a stack copy routine and it also destroys the rope routine. (e.g. it is bugged)

 

Mysterion posted his Turbo versions, so I will list the times from his versions

These use a stack copy method and the 128k, increase in speed is achieved by rolling the code out further

Matthews code using Stack copy --- stack copy has a theoretical minimum of 10.5 T-states, but the overhead is quite high

13.71SEC IN TURBO JSW IN 48K

12.14SEC IN TURBO JSW IN 128K

 

 

And finally I will list the times from My stack copy routines

10.61 in 48k

 

 

A long time has passed since the I wrote the above. I have been looking at ideas for a slightly different format, which would be inherently slower. So i investigated an idea and wrote the code to implement the idea. I eventually achieved a working game, and the code I tested and changed was from the above game.

 

Worlds fastest was my claim at 10.61 seconds.

 

The implementation of my idea in the game brings the above time down to.

 

New game copy Method,

 

8.48 seconds.

 

This is very, very, very fast:

--------------------------

 

Whilst the method works on Jet Set Willy, I do not feel that it gives me enough scope to change the game into the format I had planned. Simply because speed was just one of the problems my new layout would present. The other is the amount of code that would need changing to implement the new layout.

 

I had planned a big deviation in the basic screen shape, which ultimately modifies how every part of the game needs to handle the screen.

 

Jsw is restricted by design to its present screen layout. The speed up code worked. Yet the multitude of changes needed to modify the screen are extensive, and in most of the cases that I have looked at the relevant code is not easy to change.

 

 

--------------------------------------------

 

Double room walk down from 20 seconds to 8.48.     with a lot of extra code. (but still 128 rooms and only 48k)

 

.