-
Posts
596 -
Joined
-
Last visited
Posts posted by Norman Sword
-
-
-
Follow on:-
Available on E-bay for £14.95 + £3.00 P&P
No idea of quality or any other aspect.
https://www.ebay.co.uk/itm/194237192617?hash=item2d397059a9:g:a5AAAOSwwlVgNDbf
- Spider and jetsetdanny
- 2
-
reference TobyLobster/jsw2021 from GitHub
Quote:-
Documenting the Remaining Minor Differences
-
The jump parabola shape is very slightly different (while still being the same height and length overall) since the code seems to have problems with odd numbers of pixel height changes within the jump. This makes only a few minor changes overall:
- Nomen Luni: On the BBC you can jump from the top of the slope, under the Moon enemy to land on the platform under the ledge. On the Spectrum you have to jump to the lower platform first.
- The Bow: to jump up from the platform next to the wheel item needs two platform tiles instead of just one.
- Top Landing: Jumping into the Chapel area lands on the top level of flooring not the tiles below as on the Spectrum.
- The Forgotten Abbey: The platform under the item should be a wall, but changing this means the player can't fall down past it, trapping them at the top of the room.
- All the differences above match what is seen in the Spectrum's JSW II, so I imagine the jump parabola there matches the BBC version.
A correction to the above statement- highlighted in red. JSW II uses the correct parabolic data. The reason -The Bow-, has two blocks instead of one in JSW II is the consequence of JSW checking the wrong blocks. This also causes the bug of passing into floors when jumping in -the First landing- going towards -the Chapel-. The code in JSW does not handle the double crossing of block edges, when entering a new block diagonally. That is when it moves both vertically and horizontally across a block boundary. This also is the reason why JSW II can clear the wall in the Garden and the same move is impossible with the code of JSW.
- TobyLobster, JianYang and jetsetdanny
- 2
- 1
-
The jump parabola shape is very slightly different (while still being the same height and length overall) since the code seems to have problems with odd numbers of pixel height changes within the jump. This makes only a few minor changes overall:
-
Spider wrote
I kept thinking about the Eugune 'removal or harmless' cheats I wrote but they sort of spoil it a bit. What I could do with is something to either:
> Slow his descent down to about half its current rate
or
> If he is moving upwards when the last object is collected, do not make him move down until he's reached the top. This has both advantages and disadvantages.
I'm thinking more along the lines of the first option, if there's no sane space a quick JR out into a bit of dead area would do just fine.
My response follows with two pieces of code:-
First of the two posts was half speed Eugene on object collection. e.g. Eugene moves up and down as normal Until last object is collected then moves only downward. Eugene's speed is slowed to half its normal speed and Eugene finally stops when over the portal
The second was ignore direction change for Eugene - E.g. Eugene moves up and down as normal until the last object is collected. From then onwards Eugene will continue moving as normal but will stop when over the portal. (this removes the forced direction change to only downward on all objects being collected)
- jetsetdanny and Spider
- 1
- 1
-
; eugene keep movement - lock on portal
org #8df8
move_eugene
ld hl,#80dc ; Y POS
LD DE,#80DB ; DIRECTIONld a,(de) ; the direction
or a
jr z,descend
;else going up - ignore possible collection of all objects
ld a,(hl) ; y position
dec a ; move eugene up
jr z,change_dir
dec (hl)
jr draw_eugenedescend
ld a,(hl)
cp #58 ; PORTAL POSITION
jr z,change_dir_maybe
inc (hl)
jr draw_eugenenop ; pad out
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
change_dir_maybe
ld a,(#8074) ; last item attribute
or a
jr z,draw_eugene
change_dir
ld A,(DE)
XOR 1
LD (DE),Adraw_eugene
ld a,(hl); from here #8e27 the same as the old code
; FROM HERE ---- THE OLD CODE
and #7f ; as old code
end move_eugene -
Half speed....
;eugene slow
org #8df8
move_eugene
ld hl,#80dc ; Y POS
LD DE,#80DB ; DIRECTION
ld a,(#8074) ; last item attribute
or a
jr z,descend_slow
ld a,(DE) ; the directionor a
jr z,descend
ld a,(hl)
dec a ; move eugene up
jr z,change_dir
dec (hl)
jr draw_eugenenop ; my code is smaller - so pad out
nop
nop
nop
descend_slow
ld a,(#80bd) ; game clock - steps in 4
bit 2,a
jr z,draw_eugene ; slow to half speeddescend
ld a,(hl)
cp #58 ; PORTAL POSITION
jr z,change_dir
inc (hl)
jr draw_eugenechange_dir
ld A,(DE)
XOR 1
LD (DE),Adraw_eugene
ld a,(hl); from here #8e27 the same as the old code
; FROM HERE ---- THE OLD CODE
and #7f ; as old code
end move_eugene- JianYang and jetsetdanny
- 2
-
Cunning - I assume that the revised routines are passive.
The original added blocks to an exposed face, actively over writing the screen with the new block
I assume the revised routine adds blocks to the hidden faces - passively adding blocks with no overwrite of existing blocks.
I will come back to this when I have the time to do so.
- jetsetdanny, JianYang and Spider
- 2
- 1
-
When the routine Block.tap was listed. (written in basic) I wondered if the same type of routine could be used to generate the familiar JSW title logo. So I wrote something that emulated the visuals of the basic. Whilst that code took an hour to write, I could not generate the JSW logo using the routine I wrote. It can draw what looks like the LOGO with a flicker. The Flicker is the result of not being able to stop the drawing at any point, with the graphics needed. It has to keep on updating the screen to form a flickering image.
So a failure and not what I wanted. This is the Block Tap equivalent in Assembler.
Hold "A" to slow down to the speed of drawing the basic blocks.Hold "D" to freeze
- Spider, jetsetdanny and JianYang
- 2
- 1
-
Best viewed from the moon. e.g. not close
pulsing Psychedelic
This uses two separate routines to move colours - the colours are then merged.as usual - I looked at the code - it was not quite what I wanted . Pulsar is more symmetrical in code and output.
This separates the bright ink and paper - so this uses 3 routines and then merges them- jetsetdanny, JianYang and Spider
- 2
- 1
-
10 PLOT INK RND*7 ; RND*255 , RND*175: GOTO 10
Explode.tap is just a bit more complicated.
The backdrop has 128 stars that are being tracked. E.g. Every so often a star in the backdrop is moved.
The explosions move 160 points. The maximum number of explosions is 8. so the explode routine tracks and moves 1280 points - giving the total of 1408 points the program is tracking and moving.
The whilst the above is happening it changes the attributes of differing squares.
-----------------------
-
This is basically a re write of the routine I added to Manic Miner (dual - Software Projects and Bug Byte).
Major difference being it is not constrained to a game playing area, and the backdrop. -
Balloon Popping. The solar ray is controlled by the vertical sprites.
The skylab sprites step sideways. Either left or right with a programmable defined step. (each sprite has its own step) Due to the start positions being anywhere, that stepping could move the sprite over a wall and/or the graphic depiction of the remaining air/oxygen. Whenever this instance happens, the sprite is moved again. Whenever the double move condition is done, the solar ray is switched on and off.
The magenta skylab comes down 3 times before stepping onto the edge. It switches on/off the solar ray and is moved to the left of the screen to repeat.
+ the yellow Balloon moving left
-
The last sprite in Particle Collision Chamber has a horizontal component of movement. I did try most of them having a horizontal component and concluded -<NO>-
In Particle Collision Chamber when played in TORCH mode. The balls have a high vertical velocity which when coupled to a horizontal component made their paths seem erratic when they could not be seen.Your response (above) was while I typed this.
In Balloon Popping -- The solar ray is only switched on in EXPERT, ACE and TORCH modes.- Spider, IRF and jetsetdanny
- 2
- 1
-
The room/cavern count was set as (you will not know, until you try)
Technically their are 7 caverns in this code. It was just as hard for me to delete the rooms/caverns as it was to add new ones. Having now changed the code to now allow room deletions I can alter room count with greater ease.
Caverns included. That are changed.1) Smelly Genes, 2)Yellow stones, 3)Balloon Popping, 4)Virus attack, 5)Particle Collision Chamber
Left as a game terminator - Control one.
Particle Collision chamber is different from the final version.
In Balloon popping -- When playing the room, the direction of deflection of the solar ray is set to the side of the room that Willy is in relative to the beams start point. In other words the beams will deflect left or right depending on where Willy is.
- jetsetdanny, IRF and Spider
- 2
- 1
-
Very similar - written in assembler - I took the visual idea of above and wrote the code in assembler.
twirl.tap
the 2nd version, is the progression in complexitythe 3rd version plays with speed as well
twirl3.tap
The very last version - which changes the checker pattern
The real purpose of writing this was to show the size difference between C and assembler.
Footnote. Each of these tap files contains a header and a basic loader. All the running code data is contained within the assembled file. The size of each version is 121 bytes less than the files size. E.g. Twirl tap has 367 bytes of code and data. -- Twirl2.tap has 387 bytes of code and data -- etc..
-
I decided when I was writing Manic Panic to make the screens as easy as possible - To celebrate nearly 600 downloads (on this website) (it is 598 at the moment) , I will show how four of the screens started off and where then changed to be easier.
Only 4 screens here.
-
I looked at the code from the above - it was not quite what I wanted - This is more how I wanted it to look.
The struggle between areas of colour, for domination.
========================================
The routine fills the screen with colour.
Then it selects a (random) position and checks to see what colour is dominant in that area.
The dominant colour, then fills the local area.
The selection of areas continues for 10,000 loops.Then the whole process is repeated.
-
I write in assembler. This is called shape.
Surprisingly it is running flat out with no delays.- jetsetdanny and Spider
- 1
- 1
-
The full list of alternate (shorter) opcodes using either RRCA for RRC A and RLCA for RLC A in JSW.
The two sets of opcodes are not exactly the same in operation regarding flags. But in their context within JSW swapping to the shorter version has no impact on the code.
Besides the value at #8f14, all the other uses are in the conveyor routine.
RLC A at #9514 and #9516
RRC A at #9527 and #9529- Spider, jetsetdanny and IRF
- 2
- 1
-
I will leave you to get on with it then.
Addendum
Meaning :- I will not bother myself any further on your behalf.
-
-
- JianYang, IRF and jetsetdanny
- 3
-
-
On 4/14/2021 at 4:13 AM, jetsetdanny said:
The page features a full screenshot gallery, but if Norman Sword follows Ian's suggestion expressed above, I will be happy to update the screenshots accordingly.
I took up the challenge. Apart from the full size main screen pictures, I have changed every single screen.
The auto play in only one cavern is different. (Amoebatrons' Revenge.)
LASTv2.tap
[File] JSW+ Ve22 rv1
in Download Discussions
Posted · Edited by Norman Sword
Tidying text.
The short notes that accompany jsw2+ was never really updated, for the subsequent updates. Those note are in essence mostly what the first and original version of JSW2+ did.
In those notes it talks about a short maze. That maze is NOT seen in any of the updates writen after the test version.
What the maze did was present the player with what appeared to be very similar rooms. Those rooms were interlinked in a complex cross cross logic and unfortunately the logic was complicated enough that the people testing the routine, could not work out how to escape the maze.
I have played the maze and when told the sequence needed to escape from it. Using the specified logic, it was a simple enough thing to repeat and escape. However it was concluded that the logic, whilst it never changed - Was not in keeping with the simplicity the rest of the game exhibits when moving around.
The Maze rooms were moved and placed in a linear fashion as Glitch in holodeck x. The complex room logic removed and since it was plugging the hole that escaped the NCC1501 (via a death contact). The multitude of objects were added to compensate for the loss of life.
So the Maze does not exist in the final version.
Addendum.
The maze was originally between top landing and first landing.