Spider

A new level (level 0) was added to the 'Builder' file: This 'new' level is intended to show the Trimmer action as such. No other code routines were removed. Details are available in that linked listing.

It does work well however it can cause much mayhem with JSWED it seems. I was able with a little bit of careful sprite movement to have a theoretical 71 or so rooms without any loss of sprite data (or moving them "out of normal range" either) simply by removing the gaps and re-arrangement. You'd have to either split the room data up and edit it peacemeal or more sensibly would be to set the first 9 or so rooms correctly, move them and then edit the rest of the game, with the finished code you'd then (in theory not tested) just add that room data section to the 'first' save. Final minor tweaks may be needed for which one of the elderly Basic editors would more than suffice I think as they would be very easy to modify to allow for the initial room data location. This method in theory means you'd get the advantage of 'friendly' JSWED to use for the majority of the game but you could also 'tidy up' (item location and oddities) the 'full set' afterwards with another editor. I will investigate this a bit closer as and when time allows. A more simpler 'fix' would be to permit JSWED to accept a different value for the room starting data instead of it being hardcoded to 49152... :unsure: hmmm

To slightly clarify on this: The 'keypad remover' is safe on third party games unless the area has been recycled already. It would be prudent to check this. it is provided for this purpose. The 'expanded' one is the one to use in 99% of cases as this removes the keypad as the 'remover' plus the garbage data (easily seen in JSWED) from the sprite area. This is the one to use on an original game before editing. It is likely to work on the majority of third party games too. Here is a comparison picture of the relevant section of the sprite area from JSWED when the 'expanded' one has been used: And two quick pics (in the download descriptor anyway) of it 'in action' Keypad only: Keypad and remnant: It should be noted no other 'unused' or otherwise data is removed, this 'extra' was merely to assist in the initial tidy up of the sprite area, nothing more. :)

View File JSW Keypad Trimmer A simple Basic program to remove the Keypad data completely from the JSW game code. Load in your game code, load the 'trimmer', run it and save the game code afterwards. Two versions are provided: 1. The basic keypad only version. This replaces the long pointless startup routine with a much shorter (32 bytes vs 10 bytes) and removes the following: The keypad messages "Enter code at grid location etc" - 64 bytes starting 34187 The keypad reading/display routines - 156 bytes starting 34463 The keypad graphics and attributes - 255 bytes starting 39680 The codes themselves - 178 bytes starting 40448 Note this does not remove (most) of the 'garbage data' sat in the sprite editing area as its not all stritcly keypad related. For that see (2) below... 2. The slightly extended version. This does not remove any 'unused routines' , it merely expands slightly on the above as some random data is present in the sprite area, this will remove it too. See the screenshot of the before/after for this. It is not recommended to use this one on a third party game before checking said areas have not already been recycled for sprite or other data however it is recommended to use this on a standard game before editing it. To clarify this, as well as the above the following are also emptied: Source remnant - 64 bytes starting 39936 Data remnant - 333 bytes starting 40627 Data remnant - 1152 bytes starting 42624 Submitter Spider Submitted 07/26/2017 Category Tools and Patches  

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

http://devserver.com/jswmm_ips45/files/file/99-%7B%3F%7D/

The 'modified' screens were mockups with paint. :) I've not directly tried that method no, perhaps adding a single cell lower down would 'fix' that. I see what you're saying though now. I have tried the 'two earth cell' method though. :thumbsup:

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

I was looking at this recently with some new and interesting thoughts... First of all lets take a look at the standard 'tree' on the Spectrum: The usual fault here is the earth cell on the right, preventing Willy from climbing the tree. However lets take an alternative view of this, what if that cell was intentional ? As it stands you cannot climb the tree even with the 'head height' concern, from either side. However if you add another earth cell thus: You *can* now climb the tree from the left side. It is very difficult to time it correctly however the jump between the platforms means he hits his head on the new earth cell, resulting in him being 'in' the water cells rather than just falling down. Its possible, I've done it. Another scenario although this one is very unlikely, how about adding some water cells a bit higher up ? This way he can climb from the left again and pass through to the right... As I say I think that is very unlikely. A more likely plausible case would be to question why there are currently 'useless' platforms on the left side halfway up. Lets take another scenario instead, assuming the 'single earth cell' in the tree is correct how about just adding a couple of water cell platforms on the left thus: Now, Willy can climb the tree but only from the Orangery. This seems reasonably plausible as its slightly tricky to reach that area anyway. It also means the ramp on the lower left is more a 'preview of the tree' than anything else. It does mean the right hand platforms are redundant however, but in the same way the left ones are currently. Food for thought (depending on what fruit the tree provides, assuming it is a fruit tree) ;) As a bit of amusement here is a large picture of the tree from a few different platforms. I've only covered the major versions and some variants look so similar (for example the Einstein version looks identical to the Spectrum completely) I left them out. Bear in mind the Spectrum version was obviously first so it was logical they used the same layout, however given the 'hidden / unreachable object' issue as well as things like the 'Conservatory Roof vs fire cell' item, it does not mean what we 'see today' is how it really was intended to be... No prizes for identifying each tree variant though. Finally here are the individual pics from that 'combi' above as it may be easier to view them this way:

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'll just leave this here... ;)

I got held up with other tasks however this did work very well for my tests, thank you. :)

Yes its quite a decent port/conversion all in all. Yes. :) http://devserver.com/jswmm_ips45/files/file/46-%7B%3F%7D/ Recommended Windows emulator is Oricutron (works with x64) or Eurphoric (i386 only unfortunately) There is a 'MESS' module/plugin available to use that instead though too if preferred.

Thank you. :) I'll have a play with this tomorrow (well, later today really now I guess)

There was no 'real' reason for this other than plain curiosity really. As I had quite a bit of free space towards the end of the sprite area (I'll explain why in another topic later) I thought about the code to load the room: The code at 35090 / #8912 effectively reads: At this stage, HL is 49152 / #C000 , simply as 49152/256 = 192. It then sets up an LDIR to copy the room definition to the status buffer I set mine a bit lower down, I actually set the OR instruction to be 181 / #B5 which means it 'starts' at 46336 / #B500 as that space onwards was actually 'free' and then proceeded to move the room data 'up' (or down, depending on which way you want to count) externally to be sure it was intact from 49152 to 46336. This worked until I left a room ( ! ) as I had an IDS and I noted that the objects were not moved but I half expected that. I'm not 100% sure why the room ID's changed though :unsure: as logically unless I've missed it, it is only really looking at that address, I do not see anything in the "move Willy to the room above/left/right/below" that could directly influence the 'room exit ID' as such. I can't provide a file for this at the current time until I finish something else within a day or two, I just need to do a small writeup of it first. I wonder if I have overlooked something. I do realise in effect it "locks" those 8 or 9 rooms in this case outside the remit of JSWED however manual editing or using one of the other editors with a few tweaks (as they are usually written in Basic) would no doubt work. I may try this to see if I can force the changes through if nothing else.

I should point out I have a static sprite to use but that's not an issue as I can (test it) by disabling the piece of code to pick up the note to decide what frame to use, well probably :unsure: I did this once before and it was easy to pick the sprite this time it is being slightly annoying for some reason I'll have another look at it then see if I do need further intervention or otherwise.

That sort of works. :) I'll prepare a new topic tomorrow time permitting explaining all this in more detail as I've substantially modified quite a bit of the game code for various other things...

I was going to say 7 is enough :D rather than 'filling' the display although I can see why you said that as that's the 'full screen' as such minus 'boot'

Its similar to what I had (sort of!) thought. I'd planned on where the part of the code starts to add the life, simply jump out elsewhere (there's plenty of free space) and the 'new routine' will check the total and return without if its already too high, if its not then it will do the add then call the screen-flash if needed then return. The existing few bytes of the routine to check it would be empty apart from three bytes to do a 'call' to the new routine. :) I must admit I am having an odd issue with getting it to display a different sprite for lives for some reason, :unsure: but I need to look at this in detail really.

I've not looked at how that counter was done. I'm assuming that they used the extra space digits that were not 'printed' for this. Although I'd expect once it reached 0 it may drop to display a " / " , as a "0" is chr$ 48 / chr$ #30 and the "/" being 47 / #2F :unsure: I'm basing this simply on some 'accident's I had when erm 'adjusting' the clock digits a while back to do other things. I'd expect there is no check for the far left digit in his code ? In which case the DEC will simply drop the "0" down one character to "/" , all being well (or not!) EDIT... Pic ?

Its OK I have something else there ;) As I have the bar 'start' a bit further to the right too. :D

While looking at something else (different sprite for lives) but that did not quite work out as I intended as it seems not as easy as you'd think to change the sprite properly although I did not look *too* closely at this. Anyway the 'too many lives' scenario generally there are two usual options here: 1. Do not display them as per the 'fix' in the disassembly 2. Change the scoring code to only give them at 100,000 instead of 10,000 (a bit mean?) or reduce the scoring down instead I'd like to suggest an alternative: Option 3. At the code to add a life jump out into a bit of spare space and see how many lives are actually present. Rather than complicate it by jumping back further down the code without adding if there are more than x, simply see if there are more than ideal, reduce it to x instead then return. The advantage of this should be that its slightly simpler and potentially less messy, a simple check of the value of 33879 / #8457 should be enough. If for example (lets say max 7) that contains 6 or more, reduce it by one then return. That way the 'extra add' will only ever take it to 7 in total...

View File JSW - The Attic Bug The well known 'Attic Bug' , less commonly known as a "bad program bug" back in the day has been quite well documented on various sites over the years however apart from a small test file submitted here a while ago and a selection of screenshots not a great deal else was provided. The cause is relatively simple: A misplaced arrow which then overwrites various sections of game code, it damages the guardian entity bytes for the following rooms: Room 01: The Bridge Room 06: Entrance to Hades Room 08: Inside the MegaTrunk Room 12: Tree Top Room 13: Out on a limb Room 14: Rescue Esmerelda Room 15: I'm sure I've seen this before Room 16: We must perform a Quirkafleeg Room 23: The Kitchen Room 24: West of Kitchen Room 26: East Wall Base Room 27: The Chapel Room 38: Priest's Hole One of the best detailed but 'easy to read' descriptions is the one provided by SkoolKid in his excellent disassembly here of the JSW game. This submission contains a standard JSW game (with keypad bypass) although all the keypad routines, data and unused code is still present. To assist in the exploration of the mansion, a few small 'helper' tweaks were necessary otherwise an instant IDS would occur upon entering certain screens, Kitchen and East Wall Base for example would trigger this due to the damaged guardians. Immunity to arrows, guardians, fire cells and long falls Infinite lives 'Writetyper' enabled The starting location has been set to The Attic to ensure the 'bug' is triggered more or less immediately. If you would like to reset this back to normal (after starting the game once) then its simply POKE 34795,33 applied via your emulator/multiface. It is hoped this small submission will allow those still curious about the effects of this to be able to explore the mansion and see it in action as it progresses in relative safety, at least until the corruption becomes too heavy and/or the game itself crashes completely. Interestingly the effects do seem to vary a little bit each time it is played although this is likely due to differing player routes and / or the amount of time spent on a room. You'll note various odd effects such as invalid characters appearing the description and clock, sometimes these are permanent and will not clear upon starting a fresh game. A reset would be needed in this case. Although it is stating the obvious but please bear in mind this is merely a test file: I would strongly not recommend attempting to recycle it or use it for building a game from. Enjoy the potential mayhem! :) Submitter Spider Submitted 07/07/2017 Category Jet Set Willy [Patched]