zub Posted May 9, 2020 Report Share Posted May 9, 2020 Okay, so it turns out that SkoolKid committed his fix in the SkoolKit disassembly about a month before I posted my fix! I Quote Link to comment Share on other sites More sharing options...
IRF Posted May 9, 2020 Author Report Share Posted May 9, 2020 Okay, so it turns out that SkoolKid committed his fix in the SkoolKit disassembly about a month before I posted my fix! I Spider 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted May 9, 2020 Author Report Share Posted May 9, 2020 Also J.G.Harston's 'JSW Extensions' page was updated in 2017, which seems to be when he added the CGB fix. So Stuart (Zub)'s fix on this forum seems to have been the first to be 'published' (unless you count Skoolkid's Github entry, prior to it being transposed to a disassembly update). Spider 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted May 10, 2020 Author Report Share Posted May 10, 2020 Note that both SkoolKid Quote Link to comment Share on other sites More sharing options...
IRF Posted May 10, 2020 Author Report Share Posted May 10, 2020 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.) zub 1 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted May 10, 2020 Report Share Posted May 10, 2020 (edited) 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 Edited May 10, 2020 by Norman Sword zub, IRF and Spider 3 Quote Link to comment Share on other sites More sharing options...
IRF Posted May 10, 2020 Author Report Share Posted May 10, 2020 Sorry yes, not a search in the sense of looking for a matching value. I was picking up the terminology introduced by Zub about unbounded vs bounded searches, and trying to make the point that your method (like his) will only use data from within a fixed, intended range. Quote Link to comment Share on other sites More sharing options...
IRF Posted May 10, 2020 Author Report Share Posted May 10, 2020 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. zub and Spider 2 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted May 10, 2020 Report Share Posted May 10, 2020 (edited) 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, Edited May 10, 2020 by Norman Sword zub 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted May 10, 2020 Author Report Share Posted May 10, 2020 (edited) 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. 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, 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.) Edited May 10, 2020 by IRF zub 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.