Pokes for Fixing the Cell Graphics Bug in JSW

[Norman Sword]

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)

 

 

 

Edited November 20, 2017 by Norman Sword

[jetsetdanny]

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  ;) .

[IRF]

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/topic/185-free-space-and-code-optimisation-in-jsw/page-8?do=findComment&comment=6101

[Norman Sword]

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)

 

 

 

tile_bug.tap

Edited November 22, 2017 by Norman Sword

[IRF]

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'.

[IRF]

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)?

[IRF]

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.

[IRF]

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 December 4, 2018 by IRF

[zub]

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

Edited May 9, 2020 by zub

[zub]

BTW, as it has been asked about: it

Edited May 9, 2020 by zub