Jump to content

Norman Sword

Member Since 08 Mar 2017
Offline Last Active Jan 14 2018 12:32 AM

Posts I've Made

In Topic: Free space and code optimisation in "JSW"

14 January 2018 - 12:31 AM

The terminology that I used was "Mid Sprite bounce". Indicating a bounce in the mid part of its path. NOTE I keep on using Mid and not Middle.  


Mid has a multitude of definitions  Its preposition definition is      --- in the course of ---



You define a bounce point in the course of the sprite path.  

In Topic: Free space and code optimisation in "JSW"

12 January 2018 - 07:55 PM

Yes an increment of IX.


The code must also copy the y position.....Which it can do when setting the arrows phase in room set up..

(different from what I have at present... So I will change my own code) 



If a pair of arrows are defined and they are facing each other and cross on the screen. Then one needs setting as even and the other odd. (x position)


Erroneous spelling noted. The assembler code is 540k of ASCII  text. It has become difficult to read and bits and pieces get missed.  

In Topic: Free space and code optimisation in "JSW"

12 January 2018 - 05:43 PM

The seven empty slots. Which because of the code that double up arrows, gives fourteen arrows in that room. Of note it only uses ONE guardian definition, the others are defined by the position. E.g. the code below is all it takes in the room set up.


But first a quick run down of my thoughts...


bit 0 gives the arrow bug

but just taking the first 16 values and removing that bug leaves values 00,02,04,06,08,10,12,14


we also have a feature/bug that stops the code working on the extremes of chars, so values of 00 or 14, should also be avoided.
leaving 02,04,06,08,10,12 = 6 values from the first 16.  or for the full screen playing area 16*6 values. 96 values from 256 in total.


I fail to see why this is used. If the arrow had been confined to a fixed position within the char. Then only four bits are needed to define an arrow.
The other four bits could be used for any multitude of applications.


At present an arrow is defined by a fixed guardian. If a JSW2 style volley is wanted then each arrow would need its own guardian slot/definition.


By juggling those four bits a shift can/could be introduced into the fixed timing phase of the arrow. (done at room set up)
This then permits one guardian to be defined as having up to 16 sub classes, just by allowing a phase change on just the one guardian definition.


patched into the room set up, after testing for an arrow type guardian. With no attempt at reducing the code size.


ld a,(iy+arrow_y)
ld b,a
and 15
add a,a
add a,a

add a,(iy+arrow_x)
ld (iy+arrow_x),a
ld a,b
and $f0
add a,8  ;middle of char
ld (iy+arrow_y),a

In Topic: Free space and code optimisation in "JSW"

12 January 2018 - 05:01 PM

Re arrows:-


The arrows, my first play with them introduced a second arrow into the same guardian slot.


Mentioning wasted bits I decided to implement something I had thought about concerning the arrows.


This file shows what the wasted bits can do. Only demonstrated in the bathroom. 


This arrow demo, is tagged onto a file that keeps on being added to. (it needs deleting)



In Topic: Free space and code optimisation in "JSW"

11 January 2018 - 11:22 AM

I amended the routine the handles depression into a block for ramps. It was not listed because it was another problem, separate from the ramp code.


Plus my version can not be used because it uses subroutines and the routine itself is another subroutine. I would have needed to rewrite it.