SkoolKid Posted February 9, 2016 Author Report Share Posted February 9, 2016 Hello Richard, The following doesn't relate specifically to the use of base 10 or hex, but I thought I'd point it out here anyway: In the 'Corrupted Conveyors' section of your disassembly, the conveyor in The Nightmare Room has only been partially fixed by the cell-graphics bug patch. [snip] Very interesting. I find your argument compelling! I'll add a note to the 'Corrupted conveyors' item about this - or add a new item - for the next release. Thanks! Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 9, 2016 Report Share Posted February 9, 2016 (edited) I think the improved look of the screen speaks for itself, with my argument merely providing corroborating evidence! Stuart came up with Pokes which would fix the conveyor, if you hold fire I'll try and dig them out and come up with one that fixes the ramp cell as well. Edited February 9, 2016 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted February 9, 2016 Report Share Posted February 9, 2016 (edited) Actually, the pixel pattern of the third row of the conveyor cell is set to 11111111 - the 'missing' byte for the bottom pixel row of the ramp cells - so if that is shifted back by four bytes to 'fill in' the last row of the ramp cell, and the four subsequent bytes all cascaded down by one, it achieves the fix without affecting the last five pixel rows of the conveyor cell (except, of course, that their colour scheme has now been altered for the better by the change to the attribute byte). Stuart has suggested that: "[Matt Smith] was working without a level editor so he probably just miscalculated the address of the conveyor belt graphic when he entered its data." So the fix can be achieved by using just five additional Pokes - but bear in mind that these must be applied on top of the cell-graphics bug fix: POKE 56780, 255 POKE 56781, 2 POKE 56782, 165 POKE 56783, 255 POKE 56784, 90 The same in Hex: POKE ddcc, ff POKE ddcd, 02 POKE ddce, a5 POKE ddcf, ff POKE ddd0, 5a P.S. I should have mentioned when I attached a 'Fixed' screenshot that it is taken from an early build of JSW The Nightmare Edition (complete with fire cells and Nightmare font!), so if you plan to put a screenshot up on the disassembly then to avoid confusion, it would probably be best to apply the above Pokes (and the cell-graphics bug fix) and then take a fresh screenshot. Edited November 7, 2016 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted February 12, 2016 Report Share Posted February 12, 2016 (edited) In the meantime, feel free to point out other places where the use of base 10 is jarring or inconvenient, and I'll make a note of them. :) The room numbers - when manually entering teleport data, it would be useful to have the room numbers in hex. And 'page containing the sprite data' in the list of entities. Edited February 12, 2016 by IRF Quote Link to comment Share on other sites More sharing options...
SkoolKid Posted February 17, 2016 Author Report Share Posted February 17, 2016 All suggestions duly noted... One thing I didn't mention in my first post is that, just like the decimal versions of the disassemblies, copies of the hexadecimal versions are available for download (for offline viewing). To download the hex version of the JSW disassembly, first go to the gh-pages branch of the jetsetwilly repo on GitHub: https://github.com/skoolkid/jetsetwilly/tree/gh-pages and then click the 'Download ZIP' button. The same applies to the hex version of the Manic Miner disassembly: https://github.com/skoolkid/manicminer/tree/gh-pages Just pointing this out because it's not obvious unless you're already familiar with GitHub's interface. Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted February 25, 2016 Report Share Posted February 25, 2016 (edited) Actually Richard, as it happens if The Nightmare Room pixel patterns (for ramp and conveyor) are fixed using the five Pokes above without the generic Graphics Bug Fix in place, then the Graphics Bug doesn't actually kick in in that particular room, as the match between the conveyor attribute byte and a row of pixels in the Water cells doesn't occur. Unless you're working with the mirrored version of Jet Set Willy, where all the layouts and pixel patterns are mirror-imaged left-to-right. In which case the corruption occurs in a very different way - see attached! Edited February 25, 2016 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
Spider Posted March 13, 2016 Report Share Posted March 13, 2016 Richard as you probably may know its possible for Willy to exit a room via a rope in a room where a 'top exit' is not normally permitted. A good example is 'The Beach' although its quite fiddly to get him into the exact place (for me at least) and then jump I've seen it done and managed it myself now. This obviously causes a 'wrap around' effect. We had a discussion about various things and this was one thing that came up, so its not my 'credit' as such if anything its to be shared between myself, Ian and Danny really. The 'fix' appears quite simple: ... 37780 LD A,(HL) ; Pick up the rope status indicator at 34262 37781 CP 12 ; Is it 12 or greater? 37783 JR NC,37787 ; Jump if so 37785 LD (HL),12 ; Set the rope status indicator at 34262 to 12 (there is nowhere to go above this rope) 37787 LD A,(HL) ; Pick up the rope status indicator at 34262 ... Changing those two values highlighted in red to 14 should be enough I'd suspect and not too much to restrict genuine movement: POKE 37782,14 POKE 37786,14 If it is counted as a bug ? :) IDK what you'd call it though "Rope Exit" , "Rope Jump" , "Rope Wrap" :unsure: Quote Link to comment Share on other sites More sharing options...
IRF Posted March 13, 2016 Report Share Posted March 13, 2016 (edited) I still managed to jump off the top with it set to 14. I think 15 should do it, although it'd be best if someone independently tested it and came up with the optimal number that stops the jump off the top without setting the height limit too low (which could restrict the gameplay of the rest of the screen). Edited March 13, 2016 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
Spider Posted March 13, 2016 Report Share Posted March 13, 2016 (edited) I still managed to jump off the top with it set to 14. I think 15 should do it, although it'd be best if someone independently tested it and came up with the optimal number that stops the jump off the top without setting the height limit too low (which could restrict the gameplay of the rest of the screen). I could not with it set at 14 but that's me and I'm not the best player but I do enjoy trying. I will admit I only tested it a couple of times though. I am now able to jump off and exit easily with it at its default of 12 however. :) I'm interested to see what Richard has to say about this. I'd count it as a bug but that is just a personal opinion nothing more. Edited March 13, 2016 by Spider Quote Link to comment Share on other sites More sharing options...
SkoolKid Posted March 13, 2016 Author Report Share Posted March 13, 2016 I'd definitely count this as a bug too - and I didn't have a description of it anywhere in my notes, so thanks for bringing it to my attention! I'll have to examine the code closely to see what the smallest value is that can be POKEd into 37782/6 to prevent Willy from jumping through the top of the screen... Spider 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.