Jump to content


Norman Sword

Member Since 08 Mar 2017
Offline Last Active Nov 14 2018 08:47 AM
-----

#10336 Free space and code optimisation in "JSW"

Posted by Norman Sword on 14 November 2018 - 08:46 AM

Sorry if my editing of post #243 seems to indicate that post #244 is reiterating the same issue. What actually happened, was I looked at what I had written and edited it. Went away and made a cup of tea, came back and posted the changes. Without seeing the response via post #244

 




#10334 Free space and code optimisation in "JSW"

Posted by Norman Sword on 14 November 2018 - 07:27 AM

At #8828-34 and #88B8-C4, the LDIR method of editing the attributes of a character row can be replaced with a simple loop which uses the LD (HL), xx command.  The latter approach comsumes fewer bytes, employs fewer registers and is probably marginally faster.

 

 

The z80 mnemonic LDIR which stands for Load Increment and Repeat

 

LDIR moves each byte in memory over a period of 21 clock cycles or 21 T-states

 

Your code is slower and writes each byte in around 29 T-states

 

        LD HL, #5A60
        LD B, #20
Loop:
        LD (HL), #46        ;10T
        INC HL                 ;6T
        DJNZ Loop          ;13/8T 29 T-states compared to LDIR 21 T-states

 

You can speed this up from 29 T-states to around 24 T-states.

1) use the "C" register to load HL, this saves 3T states
2) use INC L instead of INC HL, this saves 2 T-states. In the code indicated, HL does not cross a page boundary.

 

But even this, is still slower than LDIR

 

        LD HL, #5A60
        LD BC, #2046
Loop:
        LD (HL),C            ;7T
        INC L                   ;4T
        DJNZ Loop          ;13/8T   24 T-states compared to LDIR 21 T-states

 

The timing T-states are ideal timings, writing to contended memory will slow this down.

 

However on very short writes when B is small, the slowing of the loop compared to LDIR will be counteracted by not having to load several registers. 

 

The change in code does save memory, which is the purpose of the code change.




#10304 New MM version for the Atari ST (preview)

Posted by Norman Sword on 04 November 2018 - 08:29 AM

Leave the animation as 4 frames in both directions (as originally)

I have edited the picture file to show the hand position in frame 2

 

 

Matthew drew the original in one colour, this edit whilst not exactly following what Matthew drew, will look correct.

 

(I have not yet watched the video)- but I am in the process of going out, and will not be back at a computer till much later today. 

Attached Thumbnails

  • hands.jpg



#10301 New MM version for the Atari ST (preview)

Posted by Norman Sword on 03 November 2018 - 11:22 PM

Looks great, but I see problems in how you have animated Willy.

The picture shows the four phases of Willy along the top (original)

The middle row shows the four phases as far as I can tell from your version (These are poorly scaled screen grabs)

The lower row is how I would correct the the animation. E.g. by editing the 2nd phase of animation.

The problem that I see, is caused by Willies hands not seeming to cross over the side of willies body.

 

Attached Thumbnails

  • frameD.jpg



#10249 Extra Caverns

Posted by Norman Sword on 20 October 2018 - 01:06 PM

If you read the comment I made and compare it with skoolkid's comment they are not the same.

 

The Skoolkid comment is that it draws the graphics twice.

In the Final barrier it draws the top half of the playing screen three times.

draw the top half of the room graphics  ---------------- 1) 1st write to the top of the screen
over writes with the Final barrier graphics-------- ------2) 2nd write to the top of the screen
draws the lower half of the room
Then writes the graphics for the final barrier again --------- 3) 3rd write to the top of the screen


  • IRF likes this


#10245 Extra Caverns

Posted by Norman Sword on 20 October 2018 - 09:40 AM

Trivia concerning the code that places the final barrier on the screen.
Manic Miner.

Code from 35388 to 35514

The Final Barrier

When this room is drawn, Matthew's code goes through an illogical sequence.

Matthews room drawing LOGIC as written in the game.

(1) Draw all the tiles for the top half of the playing area.
(2) Check we are in the Final barrier and erase the drawn graphics with the final barrier graphics
(3) Draw all the tiles for the bottom half of the playing area.
(4) And again check for the Final Barrier, then erase again the top half of the screen with the Final Barrier Graphics.

NOTE this writes graphics to the top part of the screen three times. (1), (2), (4)

 

This should have been as follows

Check for the Final Barrier and draw the graphics on the top half of the playing area.
Skip drawing the tiles for the top half of the screen
Draw the tiles for the bottom half of the screen.

Done

Draw the room routine at 35388
35388
    LD A,(33799) 
    CP 19   Is it The Final Barrier?
    jr nz,draw_it
    LD HL,40960   
    LD DE,28672 
    LD BC,2048
    LDIR
    jr draw2_it

draw_it
    LD IX,24064 
    LD A,112 
    CALL thirds 
draw2_it
    LD IX,24320
    LD A,120 

Thirds
    LD (S_M_C_A),A 
loop
    LD A,(IX+0) 
    ld de,9 
    ld b,8  
    LD HL,32800-9
ch_loop
    add hl,de
    Cp (hl)
    jr z,gotcha
    djnz ch_loop 
gotcha
    inc hl 

S_M_C_A equ $+1
    ld d,$
    ld e,lix
    call 37587 ; part of the print routine
    INC LIX  
    JR NZ,loop 
    RET

 

 




#10238 Extra Caverns

Posted by Norman Sword on 19 October 2018 - 03:21 PM

I will chuck some figures around concerning the big chunk of data that is stored "the final barrier". When I was presented with that piece of data I wrote a simple piece of code and compressed it. The expansion code is small. The Final barrier data and the title screen data compressed into 170H bytes. The keyboard was stored separately, I think the keyboard compresses into 10 bytes. (the expansion code for the keyboard is not very big)  

It would be relatively easy to move the Final barrier graphics (compressed) , the boot, plinth and swordfish data into the unused source code space. The rest of that space could be used for code and un-compression routines. This then allows the room data to be compressed freely.

Again it would be a simple task to write a routine to compress two sets of game data and place then into what is now the room data space.

Yes a lot of work, but you end up with 40+ caverns, which would be two games merged.

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

Another reason I would not do this is not concerning the data, compression or data layout, it concerns how the game mechanics check for room numbers before altering how the cavern plays.   


 




#10232 Extra Caverns

Posted by Norman Sword on 19 October 2018 - 01:25 PM

Curious to see the extent of room graphic data that is referenced by the game code, So I have done a quick scan through a listing.

Not as many as I thought.

These are the references to room specific data
The Final Barrier Data 

Boot Graphic Data
Plinth Graphic Data 
Swordfish Graphic Data 

(might be more, but not a significant amount of references)




#10230 Extra Caverns

Posted by Norman Sword on 19 October 2018 - 12:38 PM

Compressing caverns is very easy, however the game engine uses specific references to data within the room data. 

These references would all need changing 

JSW moves the room data into a specific area and the game engine then uses the fixed data positions. 

It would be possible to compress the data and modify the game engine to used fixed references (as per JSW) when playing a room, this permits the full usage of very aggressive compression on the room data. 

I would imagine 40+ rooms easily,  (without looking at any data to quantify my statement) 

This is not something I plan on doing or want to do.
 




#10225 [File] JSW 128 VK3.Tap

Posted by Norman Sword on 18 October 2018 - 11:47 PM

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)



 
 




#10195 [File] JSW 128 VL5

Posted by Norman Sword on 13 October 2018 - 01:49 PM

File Name: JSW 128 VL5

File Submitter: Norman Sword

File Submitted: 13 Oct 2018

File Category: Jet Set Willy [Remakes]

System: Sinclair
Third Party Author(s): Norman Sword.


JSW 128 VL5

 

This was written just after JSW 128 VK3.

 

It is an extension of the game, which I pushed towards the feel of Manic Miner
In this version changed over a period of two weeks, I took the idea of game save status and changed the way JET SET WILLY plays. If you can play JET SET WILLY then this version might actually be a hindrance to you.
For the lesser player it adds the ability to keep on trying a sequence of the game until they master it.
The only constraint to finishing is the time limit. There are no lives to be decimated, you are totally free to roam, and free to try any action.
The catch is simply that for every instance that you would normally die and loose a life you transported back to the last portal that you visited. Infinite lives and lots of time, sounds easy to finish?
The double catch is that every time you die the game re-installs all the objects collected since the last portal, it also resets the ammo.
This makes collecting objects different from when you play with infinite lives, a death jump or leap to collect an object, will not collect the object but will transport you back to the last portal, which might be some distance away. You have to perfect all the paths that collect objects and manage to get to a portal and save them.
It also changes the way willy re-appears back in a room after death. In this version that simply does not happen, he is moved back to the last portal.

 

f you don't visit the portals then a death could take you back many many rooms and many, many objects collected. Those portals are the most important place to visit.
If the game was easy in the standard format, then this version will not have any change in how you play, its design is for the casual player to permit wandering without real consequence.
One technical change from JSW128 VK3 was that is Willy does not change colour when immune. This was changed to the room name changes colour when immune instead. This small change was to enable willy to jump on ropes when immune.
It has an inbuilt cheat mode, which uses a different cheat code from all other versions.


Click here to download this file




#10114 Vic20 Version - Perils

Posted by Norman Sword on 29 September 2018 - 12:22 PM

Updated to the 3rd method. (with the other 2)

Was not happy with the speed. So decided to use stack copy with a sprite screen save routine. E.g. The sprite draws on the screen and at the same time saves the background it writes to. Doing this removes one of the long and slow stack copy routines.

100% this is easily fast enough to do perils of willy.




#10112 Vic20 Version - Perils

Posted by Norman Sword on 27 September 2018 - 05:57 PM

wrote a stack copy version and wondered why it was so slow. Checked the code, and noticed I was redrawing everything on every loop. (it was a test file)

With the stack copy the game is viable in this format.




#10110 Vic20 Version - Perils

Posted by Norman Sword on 27 September 2018 - 03:59 PM

Interested in how this would look if written in the manor I would write it.

File included. written over three hours.

I have no intention of writing this game, and was more interested in the speed aspect of adding a big chunk of extra screen.
Possible to increase speed with stack copy. Perhaps I should alter this code to see what a stack copy would do.


The screen mapping is the same height as perils and the width would be mapped as 1.5 blocks per original block. Would still need platforms jiggling about.

 

Again I will state I have no interest in writing this. 

 

1st file "pow.tap" uses LDI
2nd file "Pow Stack 2.tap" uses Stack copy -  can move left right.
3rd file "Power.tap" uses a block save and stack copy

 

Attached Thumbnails

  • power.png

Attached Files




#10108 Vic20 Version - Perils

Posted by Norman Sword on 27 September 2018 - 08:16 AM

The spectrum playing area and hence the editing area of jsw on the spectrum is 32 tiles wide by 16 tiles high,
The perils of willy uses the Vic 20 screen which is 22 tiles wide and 23 tiles high. (this can be changed).

Just the fact that the vic 20 game perils of willy has more than 16 tiles in height makes a conversion to the spectrum a non event using the existing clones of jsw on the spectrum. I am ignoring the tile aspect ratio, and the problems with the width. 

If the screens are remapped to use only 16 tiles in height, then it is not a rewrite onto the spectrum, but a re-design based on the Perils of Willy, which is not the same.

The Perils of Willy has a set of known bugs that are used to progress in the later levels. These bugs might be present in JSW on the spectrum, but if they are not then a copy has to remap the screen and change the movement of the game, and hope that it bears resemblance to the original.  

Easier to start again- how about using PGD?