Jump to content


Photo

Pokes for Fixing the Cell Graphics Bug in JSW


  • Please log in to reply
47 replies to this topic

#41 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 237 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,139 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,276 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
  • 237 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,276 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,276 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,276 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,276 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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users