[File] JSW jagged finger effect (demo)

[Norman Sword]

JSW jagged finger effect (demo)

View File

---

In both Manic Miner and Jet Set Willy the screen is copied by a simple LDIR. This simple copy does also have one simple flaw. The look of this flaw can best be described by a jagged finger look. When a sprite is moving the LDIR screen update of the sprite is sometimes overtaken by the physical raster update. This is what causes the break up flicker of Willy as he moves around the screen. The breakup is dependent on the movement of the sprite and thus what part is being updated. E.g. the breakup is dependent on the difference between the old and new position of a sprite as the screen is updated. If Willy is static then no breakup will occur. The most noticeable breakup will occur when willy move diagonally up or down stairs.

 

The screen is physically updated from top to bottom, one raster line after the other. The LDIR instruction just copies one block of ram from one place to another and this copy does not follow the raster layout of the screen.

 

I have modified an original version of Jet Set Willy to have two distinct copy routines. These two copy routines alternate between a simple LDIR and a proper raster screen copy.

 

In this demo version (which will have problems with the end game due to the nature of the modification) the screen will alternate between the two differing methods of screen update

 

1) when the time ends in an odd number the screen will update with LDIR.

 

2) when the time is even the screen will update using a simple raster copy routine.

 

This demo is not stable and I do not know how long it will work till problems occur. Its purpose is to demonstrate a problem.

---

• Submitter
  Norman Sword
• Submitted
  03/29/2017
• Category
  Other resources

 

[Spider]

Is the file OK ? Its a headerless block however the timing of it is not quite right, I can't open it with Taper to examine the actual sync / pulse data actually. :unsure:

[Norman Sword]

File downloads and runs on FUSE. (file was originally saved from fuse.

 

Since the only purpose was to illustrate a problem in the screen copying. I have captured some screen shots that show what the problem looks like.

 

This problem is mainly removed by a raster copy.

Edited March 29, 2017 by Norman Sword

[IRF]

Does the extent of the problem depend on which emulator you use?

[Norman Sword]

I am not going to spend my time elaborating on spectrum hardware. 

[IRF]

I am not going to spend my time elaborating on spectrum hardware. 

 

Fair enough, it was more of a 'wondering out loud' type question.  It's just that I haven't observed the issue occurring on the online emulator (QAOP) that I tend to use most of the time.  Then again, maybe I haven't trained my eye to look for it?

 

I have noticed the separate issue whereby the screen's display file is updated slightly before the attribute file.  This is most noticeable in rooms where the background's INK and PAPER settings are different, and fast-moving elements traverse the screen. e.g. arrows in a room with a rope, where it manifests itself in the arrows flickering in a different colour to the usual white (in that example, the arrows would be seen for the briefest of moments in the same colour as the rope).

Edited March 30, 2017 by IRF

[Norman Sword]

Sorry I forgot to add the code that should be changed in order to fix the LDIR problem

 

 

;Matthews  ldir 

;this is compromised by the copy being overtaken

; by the physical screen updates 

; once noticed this defect is hard to ignore

 

 

35317 LD HL,24576   ;3

35320 LD DE,16384  ;6

35323 LD BC,4096    ;9

35326 LDIR               ;11

35328 LD A,(34271) ;14

35331 AND 2             ;16

35333 RRCA             ;17

35334 LD HL,34258) ;20

35337 OR (HL)         ;21

35338 LD (HL),A      ;22

35339 LD A,(34253) ;25

35342 OR A             ;26

35343 JR Z,35366   ;28

 

;unused portion of code

35345 DEC A            ;29

35346 LD (34253),A ;32

35349 RLCA             ;33

35350 RLCA             ;34

35351 RLCA             ;35

35352 AND 56           ;37

35354 LD HL,23552 ;40

35357 LD DE,23553 ;43

35360 LD BC,511    ;46

35363 LD (HL),A      ;47

35364 LDIR              ;49

 

; change the code above to the code below.

; This routine does a raster style copy.

 

org 35317

 

35317 ld hl,#8200     ;3

loop    ld e,(hl)          ;4

           inc l                ;5

           push hl           ;6

           ld d,(hl)           ;7

           ld l,e               ;8

           ld h,d              ;9

           res 5,d          ;11

           ld bc,32         ;14

           ldir                 ;16

           pop hl             ;17

           inc l                ;18

           jr nz,loop         ;20 ; for the raster screen copy

;----------------------------

           ld a,(34271)    ;23 ; this code is moved down in memory

           and 2              ;25

           rrca                 ;26

           ld hl,34258     ;29

           or (hl)             ;30

           ld (hl),a           ;31

           jr 35366           ;33 ; 5 bytes bigger 

 

;16 unused bytes <here>

[jetsetdanny]

Does the extent of the problem depend on which emulator you use?

 

 

I am not going to spend my time elaborating on spectrum hardware. 

 

 

Emulators - running, by definition, on platforms other than the ZX Spectrum - can hardly be considered "Spectrum hardware".

[Norman Sword]

The effect is hardware induced/ via Ldir and the screen layout. You are asking me what effect an emulator has on a spectrum's hardware.... I have no idea how it enhances/masks this problem etc 

Edited April 2, 2017 by Norman Sword

[IRF]

I can't get the file which you uploaded to work. But thanks to the disassembly which you also provided, it should be a relatively easy task to insert the alternative 'screen-drawing regime' myself into a test file to check it out. :)

 

******

 

I think I've got my head around how it works... Considering Willy's sprite (although the effect is also manifested in moving guardians):

 

In the original code, pairs of Willy's graphic bytes are drawn in the following order when he is cell-row aligned:

 

1st pair of bytes [top of his hat], 9th pair of bytes, 2nd, 10th, 3rd, 11th, 4th, 12th, 5th, 13th, 6th, 14th, 7th, 15th, 8th pair of bytes, 16th pair of bytes [bottom of his feet]

 

This is further complicated when his sprite isn't cell-row aligned (when he is climbing a ramp/jumping/falling/on a rope). e.g. at times when he is exactly half a cell-row (four pixel-rows) out of alignment with the screen cells (such as when he's fallen downwards by one increment off a platform), then the pairs of Willy's graphic bytes would be drawn in the following order:

 

5th, 13th, 6th, 14th, 7th, 15th, 8th, 16th, 1st, 9th, 2nd, 10th, 3rd, 11th, 4th, 12th.

 

******

 

Now, with Norman's fix in place, Willy's sprite is simply drawn a pixel-row at a time [along with the rest of the screen, but I'm just concentrating on Willy here] from top to bottom, regardless of how he is aligned within the cell-rows:

 

1st, 2nd, 3rd, ... 15th, 16th

 

Is that right?

Edited April 2, 2017 by IRF