IRF Posted July 24, 2017 Report Share Posted July 24, 2017 I've always been a bit wary of this (generally) as you are sort of then reliant (as I see it at least) on the stack being correct so it knows 'where to go' , this is a bit like jumping into a GOSUB routine in a way when it his the RETURN it needs to have "somewhere" :) :unsure: I see what you're saying though. I've implemented the principle successfully, in several instances, in 'Mini'. :) Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
Spider Posted July 24, 2017 Report Share Posted July 24, 2017 I've implemented the principle successfully, in several instances, in 'Mini'. :) Oh its OK. :) I'm not saying there's anything wrong with doing it just I've been a bit wary of it as things potentially could get messy, a bit like a loop in a loop that jumps out of the 'outer' (outer not inner) then back again. :D IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 25, 2017 Report Share Posted July 25, 2017 (edited) I wonder whether we've been getting the terminology correct here? Having given some thought to the matter, I now believe that: - The 'Patch Vector Subroutine' is the four-byte subroutine that is CALLed from the Main Loop (or from the Room Setup Routine), which picks up a two-byte address stored within each room's data, and jumps to it; - 'Patch Vector' is the term for the jump destination address, stored across two spare offset bytes within the room data for each room (i.e. the Patch Vector refers to the coordinates where the Patch for that room is located); - A 'Patch' is a subroutine, located at the address that is pointed at by the 'Patch Vector' for the current room; the Patch is CALLed up from the Main Loop (or from the Room Setup Routine) via the 'Patch Vector Subroutine'. So for a game in which the Main Loop contains a CALL to the Patch Vector Subroutine, all rooms have one Patch Vector (no more, no less), although a room may feature more than one Patch if several are 'daisy-chained' together before a RETurn command is encountered during flow of execution. In such a game, if a room's Patch Vector points directly at a RETurn command, then it would be the case that that room doesn't have a Patch, but it does have a Patch Vector. ****** Following the above definitions, one would say that each room in the SE of 'Willy's New Mansion' has exactly one Patch Vector, and one or more patches. ****** Another example: in the recently-released 'Jet Set Mini', there is a CALL to a Patch Vector Subroutine from both the Main Loop and the Room Setup Routine. Every room therefore has precisely two Patch Vectors - a Room Setup Patch Vector and a Main Loop Patch Vector. However, some rooms don't actually feature any Patches at all (both Patch Vectors point straight at a RET command); some rooms contain a Main Loop Patch but no Room Setup Patch (or vice versa); some rooms feature both a Room Setup Patch and a Main Loop Patch; and some rooms contain more than one Room Setup Patch and/or more than one Main Loop Patch. Furthermore, some Patches may be shared by more than one room (where the Patch Vectors for both of those rooms point at the same address), or a Patch might be partially shared by more than one room (if two Patch Vectors point at different entry points into the same Patch). Finally, some Patches in 'Jet Set Mini' make use of existing subroutines within the original JSW code (e.g. by setting appropriate values for the register-pairs and then CALLing up the 'Print a sprite' subroutine at #9456). Where such a feature forms the only or final element of a room's Patch, then JUMPing to the subroutine instead of CALLing it means that there is no need to insert a RETurn command at the end of the Patch; the RET at the end of the existing subroutine will do the job of returning the flow of execution back to the Main Loop (or to the Room Setup Routine). In light of the above, I'm not sure my notion of an 'Item-Collection Patch Vector' quite fits in with the definitions? I suppose it's a modification of the concept: rather than each item definition holding a unique two-byte address where the Item-Collection Patch is stored, the exact nature of the special effect associated with the collection of each item is hard-wired to the item number [effectively; although it's actually determined by the item's position in the Item Table at #A4xx-#A5xx, which amounts to the same thing]. In that sense, it's more similar to the checks of the current room number in original JSW, which are the way in which the special effects in The Nightmare Room, The Bathroom and the Master Bedroom are implemented. Edited July 25, 2017 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
Spider Posted July 25, 2017 Report Share Posted July 25, 2017 Slightly confused by that, although what you're saying (if I'm right?) is its more "item x" rather than "room x" that is going to trigger it. By this I mean regardless of room if its in that position in the item table = trigger IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted July 25, 2017 Report Share Posted July 25, 2017 (edited) Slightly confused by that, although what you're saying (if I'm right?) is its more "item x" rather than "room x" that is going to trigger it. By this I mean regardless of room if its in that position in the item table = trigger Yes, in fact some rooms have several items (e.g. Ballroom West), each of which have different effects on Willy in 'Mixup'. :) Edited July 26, 2017 by IRF Spider 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.