Spider

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]  

No not tried the sound effects yet. :) Yes understood as its the 'supply' for the room: The next byte is copied to 32956 and specifies the initial air supply in the cavern. 45756 DEFB 63 That's from the Central Cavern but I see exactly what to do with those anyway :thumbsup: In decimal I'm changing the 'supply' byte to 95. Simples (famous last words!)

Very quick test and it worked :D Thank you. I 'forgot' the cavern supply one first which resulted in a near full lower third of air bar, but once I'd applied that and reset it was straightforward. Quick pic: More about why I wanted to do this over the next few days. Its not what you may think though. :)

Thanks. I'll have a play with this later. Its more complex that it first appeared though as the MSB for the display is set at 34517 LDA,82 and there's some minor sub going on. I really should just put a few breakpoints into that routine and the one around 35388 to determine exactly what is going on. I'll try your code shortly to see. I have a 'quick test' file which simply has all the lower screen area set to black paper / white ink on all of it so its very easy to see where exactly its 'drawing' I did have it drawing attribute blocks on the playing area at one point due to too high an MSB which then caused some concerns. :D

Are there any MM variants with the 'air' bar in a different location ? :unsure: It does not (at first glance) appear that simple to move it as its using the game clock to set the LSB and / or the MSB The MSB is set at 34517 to 82 I did do this once quite a long time ago but I can't quite remember how exactly. Just wondered if there are any games with it in a slightly different place. I need to shift it down one row as such. I've not spent a lot of time looking** however as there may be a game already with it done to look at **apart from a few tweaks as if you attempt to adjust the values without care you can cause a crash too but that's partly expected as it will attempt to 'draw' where it should not.

Portal not required ;) (try it!) Bug-Byte version: POKE 36809,176 : POKE 36810,128 : POKE 36815,177 : POKE 36816,128 Software Projects, Ventamatic and MAD re-release versions: POKE 36820,176 : POKE 36821,128 : POKE 36826,177 : POKE 36827,128

Eugene not interested in 'guarding' the Portal when all the items are collected from his lair: Bug Byte version: POKE 36348,0 : POKE 34349,0 : POKE 36438,24 Software Projects, Ventamatic and MAD re-release versions: POKE 36359,0 : POKE 36360,0 : POKE 36449,24 The first two pokes prevent him noticing the items are all collected, the last one simply stops him colour cycling as its a slightly different part of the routine to switch that on/off.