zub

First Landing fix ported to the Spectrum:
 
POKE 42183,156 POKE 56545,129 POKE 56546,195 POKE 56547,126 POKE 56548,60 POKE 56549,24 POKE 56550,24 POKE 56551,24 POKE 56552,60
Conservatory Roof fix ported back to the Spectrum:
 
POKE 60231,0
POKE 60375,187
POKE 60377,5
POKE 60269,1
POKE 60270,84
POKE 60278,1

Norman Sword

Ah, I guess I had no way of knowing, then! Looking back, I included an acknowledgement of SkoolKid

Thank you for sharing that: I had not actually bothered to check what was there in memory! Given that the graphic drawn will vary, that makes the case for saying it's less of an issue if an unbounded search is used. From a computer science PoV, I still really dislike that sort of code, but I suppose I must admit that on the Spectrum, it wouldn't be much of a practical concern.

Thank you for sharing that: I had not actually bothered to check what was there in memory! Given that the graphic drawn will vary, that makes the case for saying it's less of an issue if an unbounded search is used. From a computer science PoV, I still really dislike that sort of code, but I suppose I must admit that on the Spectrum, it wouldn't be much of a practical concern.

Norman Sword

That seems reasonable. However, it may worth noting that mine was a fix for both MM and JSW, and I wanted to avoid unnecessary differences between the MM version of the fix and the JSW version.
 
It did occur to me that JSW might be immune for the very reason that you state, but given that the JSW engine tends to be full of interesting

I'd forgotten about The Final Barrier, it's actually a good example of what I was talking about. Some of the cells in the upper half of the cavern are drawn using data that is supposed to represent Willy's start position, movement flags, fall counter, etc for the top seven pixel-rows, and the conveyor direction byte for the bottom pixel-row of the cell.

In other cases, the Cell Graphics Bug causes 'classic' corruption of cells in the upper half of The Final Barrier - like you see in several rooms in JSW - where the defined attribute value inadvertently matches with a graphical byte value (one of the defined cell bitmaps).

But of course, none of this is ever seen in The Final Barrier - it happens 'behind the scenes' in the pixel-buffer, but is then overwritten by the graphic from the title screen before gameplay commences.
 
 
 
I don't think the search will ever go beyond the address #8068 that immediately follows on after the end of the cell graphics table, where HL is left pointing if the CPIR loop comes to an end without a match.  So there's no danger of a scan through the whole of memory (unless a patch has been applied that is based on an unbounded search, as per Skoolkid's or J.G.Harston's methods).
 
But I agree that it would be good to reduce the length of the CPIR loop by 9 (i.e. reduce the value assigned to BC by 09, prior to the CPIR being executed), so that the 'default' graphic for a 'none of the above' cell type can be defined and controlled, rather than the program picking up unassociated data for the purpose.
 
That would also have the benefit that you would be able to have different coloured switches within a single Kong cavern.  (The switch graphic definition uses the last slot in the table of cell graphics, and collision-detection between Willy and a switch isn't attribute-based.)

Talking about the Final Barrier in Manic Miner. and graphic matching using the CPIR code. (re write to clarify)
 
1)

When the final barrier is drawn. The top part of the room contains graphic data. Which is also interpreted as the colours for the room. The room is then expanded out after matching these graphics colours. They are colours from the picture, but the room draw routine will interpret tham as room graphics
 
The colours are not intended to match the room graphics, they are the colours of the picture but the CPIR routine will still try to match the colours.
 
From memory I think the top graphic data has more than 9 differing colours.

Checking one of my source code lists . The top part has around 18 differing graphics- so in every case the graphics will not match the room graphic colour data. So in every case this would. if unchecked. possibly scan all memory.


2)

If the CPIR steps past the last known graphic, and onto stair data etc. Then it indicates that the loop should be shortened to stop on the last known graphic,

For reference, Norman Sword's fix for the CGB (as part of a more fundamental rewrite/optimisation of the Room Expansion routine) is listed here:
 
http://jswmm.co.uk/topic/496-source-code-for-jsw/?p=11166
 
It involves a bounded search.
 
(P.S. My tablet attempted to autocorrect that to "a bouncer search", which sounds like a plotline from Neighbours during the 1980's.)

Incidentally, you can see the effect of a bounded search in action in Manic Miner (albeit that the data picked up falls beyond the intended range of the bounded search, if you insert* an attribute value into a cavern layout which doesn't match with any of the attribute or graphical bytes in the cavern's cell definitions.
 
(*e.g. Manually via the Hex Editor, not in JSWED's GUI.)
 
What happens is that when the CPIR loop comes to an end having failed to find a match after searching through the range of addresses #8020-#8067, HL is left pointing at the next address in the cavern buffer: #8068. The next eight bytes - #8068-#806E (various parameters which define Willy's state upon entry to the cavern) and #806F (which defines the conveyor direction for the cavern) are then interpreted as graphical bytes to draw the pixel pattern of the errant cell.

I will correct the notion that it does a search. It uses an algorithm that does not do any searches. it places known data from a fixed position into a fixed position. 


It also removes the major bug that stops duplication of colours that should allow differing graphics, if specified. 

E.g. in JSW (out on a limb) we specify a stair and a platform to have the same colour.  Using the method I use will allow a stair to be drawn as well as the platforms. NONE of the methods listed elsewhere will permit this to happen

Ah, I guess I had no way of knowing, then! Looking back, I included an acknowledgement of SkoolKid

BTW, as it has been asked about: it

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

BTW, as it has been asked about: it

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

I thought it would be good to have a standalone topic for easy reference, containing the Pokes in Hex (EDIT: and in Decimal) that fix the Cell Graphics Bug.  The credit for most of these goes to Stuart Brady (AKA Zub), although I had a bit of input into fixing the ramp/conveyor pixel patterns and conveyor attribute byte in The Nightmare Room.
 
I'm not sure if this should be in the 'Remakes' section of the forum or elsewhere; I can relocated it if necessary.  However, I thought this might be the best place as it is highly advisable for anyone developing a game/remake using the JSW game engine to apply these Pokes, to prevent their intended cell graphics from being corrupted in an erratic manner!
 
The Cell Graphics Bug fix (a generic patch to the game engine) is achieved using the following sixteen Pokes:
 
POKE 8d54, 06
POKE 8d55, 06
POKE 8d56, cd
POKE 8d57, bb
POKE 8d58, 93
POKE 8d59, 59
 
POKE 93bb, 11
POKE 93bc, 08
POKE 93bd, 00
POKE 93be, be
POKE 93bf, 23
POKE 93c0, c8
POKE 93c1, 19
POKE 93c2, 10
POKE 93c3, fa
POKE 93c4, c9
 
EDIT: The above, in decimal:
 
POKE 36180, 6
POKE 36181, 6
POKE 36182, 205
POKE 36183, 187
POKE 36184, 147
POKE 36185, 89
 
POKE 37819, 17
POKE 37820, 8
POKE 37821, 0
POKE 37822, 190
POKE 37823, 35
POKE 37824, 200
POKE 37825, 25
POKE 37826, 16
POKE 37827, 250
POKE 37828, 201
 
An additional fix, specific to The Nightmare Room (where we believe Matthew Smith's intended attribute byte for the conveyor was misplaced in the code, as the bottom pixel row of the ramp cells; this had a knock-on effect on the colour scheme and pixel pattern of the conveyor, even with the Cell Graphics Bug fix in place), can be achieved using the following five Pokes:
 
POKE ddcc, ff
POKE ddcd, 02
POKE ddce, a5
POKE ddcf, ff
POKE ddd0, 5a
 
EDIT: The above, in decimal:
 
POKE 56780, 255
POKE 56781, 2
POKE 56782, 165
POKE 56783, 255
POKE 56784, 90

regarding the JSW Editor for Dragon I have now talked to my friend and we will give it a try to transfer it over to the PC, but after Christmas! :)

Cool! Is there a disk image of this on the net that we can play with?
 
It seems Dragon disks use MFM so should be dumpable with a PC (although admittedly an old one) with the right software.
 
The floppy formats seem to be the same as those used for the PC, so perhaps these will work in some USB floppy drives, although I won

Cool! Is there a disk image of this on the net that we can play with?
 
It seems Dragon disks use MFM so should be dumpable with a PC (although admittedly an old one) with the right software.
 
The floppy formats seem to be the same as those used for the PC, so perhaps these will work in some USB floppy drives, although I won

Hello!
 
I am new here, but I am obessed by everything regarding MM & JSW!
 
regarding the topic I have an editor for the Dragon machine :)
 
/Dasse ( from Sweden )

Hello!
 
I am a newbie and from Sweden!
 
I have collected MM & JSW since 2004, and have a site you can check em out :)
 
http://www.dasse.se
 
as you can see at my site, I also collect other series as well!
 
take care!
 
regards,
Dasse