Jump to content


Photo

Pokes for Fixing the Cell Graphics Bug in JSW


  • Please log in to reply
63 replies to this topic

#41 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 359 posts

Posted 20 November 2017 - 10:41 AM

Re Cell Graphic feature:

 

None of the "solutions" posted in this topic address the problem. What every "solution" does is eliminate one problem and ignores the fact that this method simply does not work.

 

As an example a familiar scene from JSW edited very slightly to include a ramp, a stair and a conveyor. JSWED has drawn what should be drawn by the game in the room. If the fix does not draw the graphics as shown, then the fix has not cured the problem.

 

In the case of the three graphics Stair-Ramp-Conveyor all being in the same room. Matthews code can not handle this scene properly. (The conveyor will cause the most problems in horizontal animation/movement)

 

Remove the conveyor and change its colour, then this room would play with these graphics exactly as expected.

 

I have posted a method elsewhere that draws exactly what was defined.

 

 

(picture edited to remove jswed cursor)

 

 

 

Attached Thumbnails

  • rampy2.jpg

Edited by Norman Sword, 20 November 2017 - 10:54 AM.


#42 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 2,250 posts

Posted 20 November 2017 - 07:39 PM

The point I was making is that SPECSAISIE prints the initials 'BGB' for at least half of the rooms in JSW!  But you only appear to have spotted the ones that happen to sit in the right-hand columns of the tables ('jutting out' from the main tables, so to speak).

 

If you look again you will see there are 'BGB' entries scattered throughout the tables that you failed to spot the first time!  ;)

 

OK, yes, you're right, I failed to spot those. I didn't really look at the content of the tables, so when I saw some "BGB" entries printed on the side of the tables, I assumed this was how the program was showing it had come across a problem  ;) .



#43 IRF

IRF

    Advanced Member

  • Contributor
  • 4,485 posts

Posted 22 November 2017 - 03:49 PM

I have posted a method elsewhere that draws exactly what was defined.


For reference, this was the post that Norman Sword is referring to (thanks Norman):

http://jswmm.co.uk/t...age-8#entry6101

#44 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 359 posts

Posted 22 November 2017 - 04:05 PM

Curious to see how much of a problem the Cell Graphic Feature is.

 

So I have modified a game with most of the original data in it, just to display the room and show any graphic problems.

 

The room data above $c000 is pretty much as used in the original. (might be a hand edit or two but nothing extensive)

 

This version has had the game rem'd out. It will start in the bathroom minus willy.

 

The initial room will not show the graphic data (too lazy to change this)

 

But from the initial room onwards you can wander around the game using the keys

 

1=left  2=right   3=up   4=down 

 

Along the line below the room name will be displayed data in this format

 

two digit room number in decimal

 

Followed by 3 background tiles/ /3 floor tiles/ /3 wall tiles/ /3 baddy tiles/ /3 ramp tiles/ /3 conveyor tiles

 

Each group of three tiles are generated by the various methods.

 

The first tile is matched using CPIR

The second tile is matched using CP (HL) and stepping

The third tile is the actual definition.

 

What is noticeable is there are very few incorrect matches.

 

EDIT---

 

The program now outputs a second line of data (the same data minus the colours)

 

 

 

Attached Files


Edited by Norman Sword, 22 November 2017 - 05:05 PM.


#45 IRF

IRF

    Advanced Member

  • Contributor
  • 4,485 posts

Posted 22 November 2017 - 04:34 PM

What is noticeable is there are very few incorrect matches.

Which could suggest that Matthew knew about the problem, but worked around it rather than fixing it? I guess we'll never know.

Thanks for the file and the analysis.

P.S. One thing that your graphics on the line below the room name doesn't show, is any defined pixel patterns that are 'hidden' because the associated cells have a defined attribute with matching INK and PAPER settings. e.g. the ramp cells in 'Under the MegaTree'.

#46 IRF

IRF

    Advanced Member

  • Contributor
  • 4,485 posts

Posted 24 November 2017 - 06:21 PM

Not that the defined ramp pattern in 'Under the Megatree' actually makes any sense for a ramp - it's a horizontal line, due to the value #FF stored at #C2C8.  Willy would 'sink through' the line as he walked along it, if ever it were present and visible on the screen.

 

Possibly Matthew inserted that non-zero graphical byte by mistake, whilst inserting values of #FF as default attributes for the ramp and conveyor (at #C2C4 and #C2CD)?



#47 IRF

IRF

    Advanced Member

  • Contributor
  • 4,485 posts

Posted 04 December 2018 - 01:21 PM

Have you checked whether the Cell-Graphics Bug affects any cavern elements in Manic Miner?

 

 

I have, and the answer is no, it doesn't.

 

I'm not sure whether SkoolKid's response above applies only to all the cavern elements that are actually present when you play Manic Miner, or whether he also analysed all the unused cavern elements in the game. i.e. where Matthew Smith defined graphics for a block type but didn't actually place any instances of those blocks within a particular cavern.

 

(There are plenty of examples of unused block graphics in a cavern which replicate identical block graphics from other caverns - e.g. the 'poisonous pansy' static nasties from 'Central Cavern' are also defined for 'Abandoned Uranium Workings' but are unused in that cavern - and even one example of a cell graphic which Matthew created but which doesn't appear anywhere in the game - the Crumbly graphic in 'Skylab Landing Bay'.)

 

So it's possible that the Block Graphics Bug could manifest itself if you modified the layout of Manic Miner (without changing the game engine)?  An analogy (which I discovered and reported earlier in this thread) would be the static nasties in JSW's The Nightmare Room: they have a defined graphic but none are present in the original game; however if you insert one into that room then the graphic gets corrupted when you playtest it, because of the influence of the BGB.



#48 IRF

IRF

    Advanced Member

  • Contributor
  • 4,485 posts

Posted 04 December 2018 - 03:45 PM

To answer my own question from the previous post, there is actually a non-trivial example of where the Block Graphics Bug would manifest itself in Manic Miner - if there was a Type 1 Nasty placed in the layout of 'Ore Refinery', then its graphic would indeed be corrupted, because the attribute byte for Nasty 1 (#44) matches a graphical byte from another block type (halfway down the floor tile) that is listed earlier in the cavern definition.

 

There is also the issue that both of the unused-but-defined nasty graphics in 'Skylab Landing Bay' would not get drawn if a nasty (of either type) was placed in the layout, because their attribute byte is set to zero, matching the first (and indeed all) graphic bytes for the background tiles.  However, you wouldn't see the defined nasty graphics in that cavern anyway, even if the Block Graphics Bug was fixed, because 00 = black INK on black PAPER.  Therefore I would categorise that as a trivial example of the 'Lurking Block Graphics Bug' (alongside a number of other even more trivial examples, arising from completely undefined cell types whose attribute and graphical bytes are all set to zero).

 

**

 

All of which is to say that, if you were to pass the original Manic Miner through SPECSAISIE's 'Find the Block Graphics Bug' function, you would see quite a few 'BGB Flags' in the output (for various reasons).

 

 

EDIT: Andrew Broad's 2008 Remix of Manic Miner has Fire 1 cells placed within the cavern 'Ore Refinery', and they are indeed corrupted by the Block Graphics Bug!

And 'Skylab Landing Bay' in the 2008 Remix contains a black INK on black PAPER Fire cell, which is also blank apart from the bottom pixel-row, which has the following bitmap which flashes momentarily but visibly when Willy is killed:

 

01001100

 

That is equal to #4C, which is the attribute byte value for the first floor tile definition (which follows on from the background tile definition).  So after the topmost pixel-row of the background (non-)graphic matches with the Fire attribute byte, the Fire cell is drawn using the background's remaining seven blank graphic bytes, then the floor tile attribute byte interpreted as a bitmap for the Fire cell's bottom pixel-row (normally not visible except at the point of Willy's demise).


Edited by IRF, 04 December 2018 - 03:56 PM.


#49 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 09 May 2020 - 05:43 PM

Jonathan (J. G. Harston) is acknowledged in the Credits section of SkoolKid's disassembly. Since I believe his fix has been available online for a long time (before SkoolKid's otherwise great disassembly was created), if the two solutions are similar (or the same, perhaps?), I wouldn't be surprised if Richard (SkoolKid) had actually copied Jonathan's solution.

 

Sorry to revive an old thread, but are you sure about that? I tried my best at the time to search for an existing fix, and would feel rather rotten if it turns out I overlooked someone else’s!

 

JGH’s post the week before this said that “a couple of days ago he was looking at the block graphics drawing code and not being able to remember seeing a bugfix for it anywhere I thought Id test a fix Id had sitting at the back of my mind for years. Is this simply borne out of a perception that everything on mdfs.net must have been there since the dawn of time?

 

I too, had been meaning to write a replacement for the buggy CPIR-based routine since I saw it in the late 1990s, although it’s possible that JGH had a more concrete idea as to how to go about this, but the first snapshot on archive.org before JGH’s post has no mention of a block graphics fix. It’s not like it’s really a big deal, but it’d be nice to know if I can safely say that my fix for this was the first to have been made publicly available!

 

JGH’s fix seems good to me, although I’m unsure exactly how many POKEs it would need, and what all of the pros and cons are compared with the one that I provided.

 

SkoolKid’s fix seems very impressive in that it requires only 10 POKEs, although it’s worth being clear that it occupies part of the memory region that would otherwise be used for the room 63. I can’t see that anyone has done a disassembly of this (and at the risk of being a little critical, it would be good for any page that provides disassembly of a game engine to also provide the assembly for any suggested fixes to that engine!) so here goes:

  org 0x8d51
; unbounded search of the graphics definitions
  ld hl,0x8097    ; As per JGH's fix: "Start at the background attribute"   
                  ; (Only one byte changed) 
  ld bc,0x0009    ; As per JGH's fix: "Nine bytes per block"
                  ; (Only one byte changed) 
  call gfxsearch  ; Three bytes changed

  org 0xff26 ; Replacing TRSDOS code in "Room 63"
; A relocation of JGH's fix and some of the original code:
gfxsearch:
  add hl,bc       ; As per JGH's fix: "Step to next block"
                  ; (One byte changed)
  cp (hl)         ; As per JGH's fix: "Does attribute byte match?"
                  ; (One byte changed)
  jr nz,gfxsearch ; As per JGH's fix: "Check next block"
                  ; (Two bytes unchanged - ingenious to reuse this jump!)
  ld c,e          ; Relocation of the original code
  inc hl          ; As per JGH's fix: "Point to bitmap"
  ret

Note that both SkoolKid’s fix and JGH’s fix perform unbounded searches. I.e. mine matches the original behaviour in JSW of using the address following the the block of graphics definitions if the lookup fails, whereas both JGH’s fix and SkoolKid’s fix will search the whole of memory until they find a result. In practice, it is a virtual certainty that a matching byte will be found (as the size in bytes of the address space of 65536 and the size in bytes of each graphics definition of 9 are coprime), but this could perhaps be a risky fix to port to any machine that uses memory-mapped I/O. Using an unbounded search would trivially save three bytes in my version.

 

The reason I used a bounded search is that I wanted to be absolutely confident that I wasn’t introducing a (possibly masked) bug into the Nightmare Edition. It’s perfectly reasonable to use an unbounded search, but it would make sense to verify (using code!) that this does not affect the rendering of any levels, first. (We have since found out that the nasty in A bit of tree was corrupt too, which goes to show the risk of a fix going beyond what was intended or at least known about at the time.)

 

The reuse of a two-byte jump instruction in the TRSDOS code by SkoolKid’s fix is fairly ingenious, although note that twelve POKEs would be required if relocating the fix to allow use of room 63, rather than the original ten.


Edited by zub, 09 May 2020 - 05:50 PM.


#50 zub

zub

    Space Marine

  • Contributor
  • 98 posts

Posted 09 May 2020 - 05:45 PM

BTW, as it has been asked about: it’s almost certain that Matt Smith would have known about this at the time, as he would have been bound to have kept tripping up over it. It’s possible that he would have moved on from having written the block graphics search routine, especially as it is unchanged since Manic Miner, and that perhaps he hadn’t realised that the cause of this was the CPIR instruction... but it seems plausible that the use of CPIR was a quick time-saver that got left in during development, and then quite possibly cost time later on as it kept getting triggered.

 

Sometimes, the bug is not so noticeable (especially for walls and floors) but in other cases it would have been highly noticeable (ramps, conveyors, nasties) as must surely be well known to those who have done extensive editing of JSW levels. When it occurs and is noticed, the choice becomes one of changing the pixel data in the preceding graphics, changing the attribute data of the affected graphic, or putting up with the graphical corruption.

 

One can imagine that he might have been pushed further towards making false economies in the run-up to release. At least, if he had wanted to do tooling and/or game engine work in order to hunt down and fix the “last few” bugs, I could see how that might not be well received. This part is all, of course, sheer speculation!


Edited by zub, 09 May 2020 - 06:22 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users