Jump to content


Photo

Willy disassemblies in hexadecimal


  • Please log in to reply
117 replies to this topic

#11 SkoolKid

SkoolKid

    Advanced Member

  • Contributor
  • 54 posts

Posted 09 February 2016 - 10:46 PM

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!



#12 IRF

IRF

    Advanced Member

  • Contributor
  • 3,891 posts

Posted 09 February 2016 - 10:56 PM

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 by IRF, 09 February 2016 - 11:02 PM.


#13 IRF

IRF

    Advanced Member

  • Contributor
  • 3,891 posts

Posted 09 February 2016 - 11:58 PM

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 by IRF, 07 November 2016 - 01:02 PM.


#14 IRF

IRF

    Advanced Member

  • Contributor
  • 3,891 posts

Posted 12 February 2016 - 10:34 AM

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 by IRF, 12 February 2016 - 01:30 PM.


#15 SkoolKid

SkoolKid

    Advanced Member

  • Contributor
  • 54 posts

Posted 17 February 2016 - 08:03 PM

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/s...y/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/s...r/tree/gh-pages

 

Just pointing this out because it's not obvious unless you're already familiar with GitHub's interface.



#16 IRF

IRF

    Advanced Member

  • Contributor
  • 3,891 posts

Posted 25 February 2016 - 10:06 AM

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!

Attached Thumbnails

  • Nightmare Room Alt Fix.png

Edited by IRF, 25 February 2016 - 10:09 AM.


#17 Spider

Spider

    DEC (HL)

  • Administrator
  • 3,486 posts

Posted 13 March 2016 - 06:24 PM

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:
Changing order to chaos since 1984

#18 IRF

IRF

    Advanced Member

  • Contributor
  • 3,891 posts

Posted 13 March 2016 - 06:33 PM

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 by IRF, 13 March 2016 - 06:34 PM.


#19 Spider

Spider

    DEC (HL)

  • Administrator
  • 3,486 posts

Posted 13 March 2016 - 06:41 PM

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 by Spider, 13 March 2016 - 06:46 PM.

Changing order to chaos since 1984

#20 SkoolKid

SkoolKid

    Advanced Member

  • Contributor
  • 54 posts

Posted 13 March 2016 - 08:03 PM

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






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users