Jump to content
Jet Set Willy & Manic Miner Community

[File] JSW jagged finger effect (demo)


Norman Sword

Recommended Posts

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.


 

Link to comment
Share on other sites

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.

post-125-0-64805900-1490825250_thumb.png

post-125-0-19874200-1490825258_thumb.png

post-125-0-19012000-1490825267_thumb.png

Edited by Norman Sword
Link to comment
Share on other sites

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 by IRF
Link to comment
Share on other sites

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>
Link to comment
Share on other sites

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 by IRF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.