jetsetdanny Posted July 4, 2016 Author Report Share Posted July 4, 2016 I had a case of matching attributes while working on "WNM SE" earlier today. The beginning of a PV code - the LD HL command (21) - placed where the attributes for the conveyor normally are matched the attributes of the Water cells in "Willy's Personal Hideout". I set the starting point within the figure of Willy in that room (for testing purposes) and was surprised to find out I couldn't move, only jump! Then I set the starting point to "Copin' with Ropin'" and when I entered the Hideout everything seemed to be fine. So I was even more puzzled, until I reached Willy's figure made up of Water cells and Willy ("the little one") started running to the right. And then it dawned on me what was happening :) . I solved the problem by shuffling two pieces of the PV code around: I put an LD DE (11) instruction up front, it is now followed by the LD HL (21) instruction. Fortunately, it was an easy fix. I am writing this not to discourage anyone from using the attribute byte in the way we are discussing, but to give a true account, the first ever (in the history of the Universe :lol: ) of such a problem as a testimony that it can arise, and that it can also be solved satisfactorily :) . IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 4, 2016 Report Share Posted July 4, 2016 (edited) I solved the problem by shuffling two pieces of the PV code around: I put an LD DE (11) instruction up front, it is now followed by the LD HL (21) instruction. Fortunately, it was an easy fix. You could also fix such a problem at the 'other end of the equation', by inversing both the pixel pattern and the Paper/Ink colours for the Water cells.. was surprised to find out I couldn't move, only jump! You must have also had an 'invalid' value for the Conveyor Direction Byte (at Offset #D6), causing the Water-Conveyor composite cells to turn Sticky! Even more 'fun' could be encountered if you accidentally matched up the Ramp Attribute Byte with the Attribute Byte of one of the other room elements, and you had selected an 'invalid' value for the Ramp Direction Byte (Offset #DA)! Because that could trigger off all manner of 'Invalid Ramp'-related 'special effects', and you know how unpredictable they can be!! :wacko: Edited July 5, 2016 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 4, 2016 Report Share Posted July 4, 2016 I just tried inserting a value of 'C9' as the Border Colour byte (at Offset #DE) in a test file. It yielded a Blue border, with no apparent adverse effects, so the relevant code must just be selecting the lowest three bits of the hex value C9 (001), when determining what colour to render the border in. Therefore, if you were trying to insert some code into a room's spare definition bytes, but you found you were just short of space [as I did in similar circumstances earlier, when I devised a Patch Vector that just fit into the available space - but then I realised I'd forgotten to account for a terminating Return command!], then you could carry on through the Ramp definition bytes, utilising #DA-DC (though you would have to leave Offset #DD as '00', which is probably interpreted as a NOPped out byte by the program when reading this area as Z80 code, but in parallel it is also interpreted as 'Ramp Length = Zero' by the routine that draws [or rather in this case, doesn't draw] the Ramps). Then whenever the program, whilst implementing the Patch Vector meaning of the code, reached the Border colour byte of 'C9', it would interpret that as a Return command, thereby terminating the routine! The point is that you can pull off a lot of optimisation tricks, as long as you're careful and you know what you're doing! jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 5, 2016 Report Share Posted July 5, 2016 (edited) I just tried inserting a value of 'C9' as the Border Colour byte (at Offset #DE) in a test file. It yielded a Blue border, with no apparent adverse effects... Admittedly, I didn't try playing the file in SPIN; we earlier discovered that setting the border colour beyond the usual range of 00-07 meant that sound effects associated with a border colour effect were inaudible (or gave rise to a barely audible 'blip'!) in SPIN... Edited July 5, 2016 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted July 11, 2016 Report Share Posted July 11, 2016 (edited) I believe that the four bytes at #92B2-92B5 could be freed up, by inserting the Rope Segment Drawing Byte directly into the Rope Definition Bytes at #A00D (and the equivalent location if other Rope Classes are defined), rather than an empty (00) byte being copied across (via the LDIR loop starting at #8922) and then the appropriate byte in the Guardian Buffer being filled by the command at #92B2-92B5. This would also open up the possibility of different Rope Classes having differently defined Rope Segment Drawing Bytes, rather than one generic value. i.e. one Rope Class could start off at the top of the screen with the left-most pixel in its starting column filled in (as is the case for all Ropes currently - the relevant byte is given the value #80), while another Rope Class could have its top segment occupy the right-most pixel. (i.e. By inserting a value of #01 instead of #80 into Byte 5 of the Rope definition.) EDIT: I tried it, and it makes the Rope really 'jerky'. (The top segment, which should be a fixed point, keeps shifting, which also affects the rest of the Rope.). So it doesn't really work, unless you want 'jerky' Ropes. It might be possible, with a rethink, to achieve the 'incidental' result of having the drawing byte definable by Rope Class (instead of being hard-wired into the game engine). However, that probably wouldn't yield a byte saving, which was the original point of the exercise, and it may even require extra bytes. Anyway, you can see the jerky effect in the attached file, in the start-up screen The Beach (or any room with a Rope for that matter, since only one Rope Class is present in the file). Jerky Rope test.z80 Edited July 12, 2016 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 21, 2016 Report Share Posted July 21, 2016 (edited) Preambling quote from another thread: Pressing the 'Fire' button on a joystick can also be used to start up the game when the title music 'Moonlight Sonata' is playing, which could have the same effect. Although looking at the code it would appear that, curiously, the joystick Fire button does NOT provide the function of starting up the game whilst the scrolling message is in operation! I think there may be a way to iron out this inconsistency in the way that the joystick's 'Fire' button works (or doesn't) in starting up the game from the Title Screen. And in the process, it may achieve a saving of 6 bytes! I haven't tried this out yet, but if the 9 bytes from #88E3-88EB were replaced with a 3-byte CALL to the subroutine at #96C9, shouldn't that do the trick? If it works, it would be of great assistance in implementing the code changes nearby (in the 'Start the Game' routine) that allow a Guardian Class 127 to be created! UPDATE: I just tried it, and it does seem to work - certainly the ENTER key starts the game up with no problems both during 'Moonlight Sonata' and during the scrolling message (alas I haven't got a joystick to try the Fire button out in both scenarios). Edited July 22, 2016 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 21, 2016 Report Share Posted July 21, 2016 (edited) Does anyone ever use the number keys to control Willy's movement in JSW? I believe that if you were prepared to sacrifice the ability to use the number keys to move Willy, then the following bytes could be 'recycled': #8F1A-8F31 and #8F78-8F7F - that's about 32 bytes that could be freed up! N.B. This stills leave the options of pressing Q-P for left-right movement and the bottom row/Space bar for jumping, or else using a joystick. (EDIT: Also, the number keys would then allow you to unpause the game without causing Willy to move, or altering the On/Off status of the in-game music.) Edited July 21, 2016 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted July 21, 2016 Author Report Share Posted July 21, 2016 Personally, I don't ever use the number keys to control Willy's movement. So I wouldn't mind these keys being assigned a different function. IRF 1 Quote Link to comment Share on other sites More sharing options...
Spider Posted July 21, 2016 Report Share Posted July 21, 2016 I do not use them either. Bear in mind part of the reason for those keys to control him was for the Sinclair joystick option (which used 67890 or 12345) but that's not of much practical value these days, emulation tends to use Kempston anyway The only caveat would be someone on a real machine (a +2 / +2A / +3) using the built in joystick ports as these *are* those key combinations. :) IRF and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
Spider Posted July 21, 2016 Report Share Posted July 21, 2016 To clarify this a bit: Sinclair Joystick on Interface2 (left socket) 1=left 2=right 3=down 4=up 5=fire Sinclair Joystick on Interface2 (right socket) this is the one most used: 6=left 7=right 8=down 9=up 0=fire 'Cursor' interface Joystick: I don't think these were too common 5=left 6=down 7=up 8=right 0=fire Kempston: Not 'directly' mapped to any keys so its popular. Can be read from Basic too with IN 31 such as: 10 PRINT AT 0,0;" " 20 PRINT AT 0,0;IN 31 30 GOTO 10 IRF and jetsetdanny 2 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.