Spider
-
Posts
5,228 -
Joined
-
Last visited
Everything posted by Spider
-
Thanks both. :) I need to digest in detail what you've written (later today) I know it works with JSW as I edited a few screens then moved the room start data although it did mess the items up a fraction, with care it can be done, just means that subsequent editing would make a mess. I realise this is not JSW but the vague principle of "get the screen right then move it later" would likely work in MM too.
-
I was thinking about this previously but did not post about it, as even now I have not looked into it at all. Simply put: Has anyone considered a bit of compression in the cavern design/code space to allow more to exist ? Perhaps 30 or at a push 40 caverns ? I thought about some code saving by moving a lot of the routines to take advantage of the large-ish 'dead space' which would provide 2480 bytes at least, however that is quite a bit of an undertaking I think, plus you'd lose the easy ability of editing via JSWED unless you edited them 'where they were' then moved them after. As I say I've not even looked into this to see how feasible or not it would be to employ some compression to increase the number of caverns, that compared to moving and adjusting/relocating the 'engine code' to provide more space near the higher end of memory is equally as much work I think. Any thoughts ? :)
-
http://clrhome.org/table/ Z80. Quite useful, shows what registers are effected by each instruction as well as a very brief description of what the instruction does. Simply hover over the one in question. :)
-
This looks very interesting, thanks Norman. :)
- 4 replies
-
- 1
-
-
- faster
- norman sword
- (and 3 more)
-
I did try an inverted cavern earlier this morning but the results were quite poor even after I'd inverted the guardians so they worked correctly (and looked half decent) upside down, I even tried with the platforms as \ / instead of / \ but it was not really any better so I did not keep the results. :)
-
BBC Micro, author of the listing is Andrew Waite Short (under 10 seconds) video of it "in action" : mw_anim.zip Screenshot :
-
A BBC Micro Emulator ... For the Spectrum (yes really) This is obviously an off-topic thread but that's partly what 'Chat' is for aka "other things" :) I do not have any up to date information as of yet regarding this, although it looks very interesting it was quite a few years ago work on this was started...
-
Potentially a new quirk/bug ? My leaning is towards a quirk with it though :unsure: Yes! :D I'm not sure :unsure: as the one I posted (36477) is the one that's been used for years, its still implanted in my head! I can see that would change the LD A , 12 to LD A , 1 (preserving the sound) however a quick test showed that Willy still died from a reasonable fall from the Bathroom ramp ? :) EDIT... Replied to a PM with an .rzx regarding the last point, something slightly amiss is going on.
-
I did notice that as it does eventually call the death routine, I suspected as the AirBourne indicator had reached its final value. I did note yesterday actually with one of the Fall variants at least even if you set the infinite falls via: 35809 , 255 / #8BE1, #FF M.W will eventually die as he's gone too far. :D To be fair that poke is intended to prevent a cavern 'accident' not really a wrap around I suspect. There is at least one other poke for it as well, that one is from the Disassembly. The alternative one is: 35682 , 0 / #8B62 , #00 But that removes the INC A instruction to increase the AirBourne counter, you can easily tell if that one is applied as the fall sound is static rather than the regular decremental blips. That reminds me actually of the two erm choices for JSW for the same thing thinking about this: JSW: 36578 , 16 / #8EE2 , #10 , Falling sound preserved! JSW: 36477 , 1 / #8E7D , #01 , Falling sound ruined! , this one is the more common one that's been around a longer time iirc
-
That makes sense! :D A minor variation, I did this before I saw your above reply just now. Mainly to see the effects of a bit of a gap around some of the edging as such. Variations of a theme I guess, although I moved the items to just be above and below the portal as well as spacing sensibly the climbing water cells a bit: I was able to walk along under the Portal with a bif of care, grab the two items there then move to one side and jump reaching the upper plaforms, then it was just a case of falling straight down collecting the above Portal items on the way! :lol: MM Fall Test Five.Tap EDIT... .quick rzx of three slightly varied cavern completions: Fall Test Five.rzx
-
Likely yes, the same way you can stand on the lower area if the platform is at the top (as per the first test) , I've not quite got my head around the quirks in the engine permitting this, the same as you can move/wrap around the edge of the screen and end up with half a sprite temporarily.
-
Much increased falling! If you do it from the lower platforms there's a barrier it seems! :D If you jump right to left he appears to 'move up' as well.
-
Great! :D Thanks both. @Ian is interesting to watch and thanks for the detailed explaination too. @Danny I had a vague inspiration (if you can call it that) from playing Frankenstein earlier in the day and the mirrored platforms thought partly came from that: I'm attaching a third variant I did not get chance to upload late yesterday, it is quite similar however the positioning of the earth horizontal platform and conveyor is opposite, as in the conveyor is higher up than the earth platform. In addition the lower two items were positioned beneath the Portal itself. The screenshot will assist... ... and the file... MM Fall Test Three.Tap Finally the .rzx played a couple of times: Fall Test Three.rzx Finally I'd forgot to remove (as pointless as it was) 2048 bytes from 40960 / #A000 , the title screen top third pixel data, as it served no purpose given the fact the attribute data is not present. The first two .tap files in the initial post are updated to reflect this too, nothing at all else was touched.
-
I think that's usually the case! :blush: :lol: :thumbsup:
-
Intended so he falls through to wrap around if the Portal is not active. This can happen with 'Test One' , no cheats applied: Short .rzx: Under The Portal.rzx , plays back fine in Spin/Spectaculator First time as expected he falls through once he's clear of the 'top earth cells' even though he's on the lower screen. Second time around note what he does, he can wander around the Portal to the right but not the left, the left floor area makes him fall through, assuming (untested) if he jumped up top via the left instead of the right he would be able to walk on the left but not the right. Third time around shows the walking about in more detail. I would not expect him to be able to walk underneath the Portal at all though :unsure: ? :) As there's nothing up top as such for him to be using to stand on... EDIT... Either the Portal position or the top water cells permit this it seems as in 'Test Two' its not possible. I could be wrong! :lol:
-
Attached are two test files, built from the Bug-Byte version: MM Fall Test One.Tap MM Fall Test Two.Tap There are slight differences between the two, as illustrated by the combi screenshot... ... In essence, the gap is larger in 'two' compared to 'one' , the portal and items immediately above are a block higher. The reason for this second file is if M.W falls in 'one' he can land and walk on the floor area underneath the portal. The extra file was needed to confirm if the small gap at the top between the water platforms or the portal was the immediate cause. The use of the conveyor and gaps left to right along with the conveyor being further down was to test out the effects of left/right exit with regard to M.W's position when he emerged on the other side of the screen. The 'saw' guardians are set to slow and mainly there as 'filler' along with the roof nasty fire cells, easily avoidable. They were built mainly to test the effects as indicated above, falling and jumping through left/right nearby or onto cell types. The layout of the cavern was picked to be relatively simple to quickly tweak to do 'other things' It should be noted this is a cut down game file, no cavern data exists beyond the first one! Attempting to teleport into the next cavern will result in a lockup! The INC A instruction to increase the cavern number at 36907 / #902B was NOP'ed out to prevent a crash when completing the cavern or running demo mode. The files provided are the full 32K ones with a mildly tweaked loading pic (simply as I had it to hand as an executable file rather than screen data) but are JSWED editable (at the loss of the non-standard loader but that's not a concern, again I had that 'to hand'). It would be quite easy to provide a much truncated file but this would then preclude ease of editing. Enjoy ? :unsure: :)
-
To expand on this: ( 1 ) , The JP 0 instruction to reset the machine was changed to JP 34762 rather than change the previous JPZ to a JP ( 2 ) , The standard fix of 59901,82 was used ( 3 ) , The standard fix of 60231,0 was used ( 4 ) , The standard fix of 56876,4 was used ( 5 ) , The Air Ink was changed via 57248,5 to set it to cyan ( 6 ) , The distance checks at 37782 and 37786 were changed from 12 to 15 ( 7 ) , The instruction at 35620 which by default reads IN A , © was changed to IN A , (254) ( 8 ) , The standard fix of 42183,11 was used with the addition of reading the item bytes from 63716-63721 (only 5 bytes) and copied to 52196 ( A ) , The pause fix was tested on real hardware to confirm it worked properly as it also slightly alters an instruction around the IN as well. ( ? ) , The line numbers in the Basic are purposely chosen to allow the main original Basic loader to be safely MERGE'd in without any other alteration. ( C ) , The Basic was written to try to make it efficient (smaller) in size rather than make it readable hence the large use of the VAL instruction. Finally, much credit is due to "SkoolKid's" excellent disassembly for making my life much easier in assembling this simple file.
- 1 reply
-
- 1
-
-
View File JSW Fixer A simple small file to load before the main JSW tape. It provides the following fixes to the standard game: 1. The second keypad code is always accepted 2. The invalid arrow in The Attic is rectified 3. The impossible Fire Cell in the Conservatory Roof is removed 4. The single Earth Cell in Banyan's Tree's trunk is replaced with an Air Cell 5. The air ink for Swimming Pool is changed to allow Willy to collect the item by himself 6. The top distance on ropes was reduced preventing Willy from accidentally jumping up where it was not intended 7. The interface1 pause lockup is fixed 8. The hidden First Landing item was moved to The Hall and given a shape borrowed from West Wing Roof It should be noted this is intended for a standard game, its effects on third party variants of JSW is unpredictable. Submitter Spider Submitted 10/03/2018 Category Other resources
- 1 reply
-
- 1
-
-
8 downloads
A simple small file to load before the main JSW tape. It provides the following fixes to the standard game: 1. The second keypad code is always accepted 2. The invalid arrow in The Attic is rectified 3. The impossible Fire Cell in the Conservatory Roof is removed 4. The single Earth Cell in Banyan's Tree's trunk is replaced with an Air Cell 5. The air ink for Swimming Pool is changed to allow Willy to collect the item by himself 6. The top distance on ropes was reduced preventing Willy from accidentally jumping up where it was not intended 7. The interface1 pause lockup is fixed 8. The hidden First Landing item was moved to The Hall and given a shape borrowed from West Wing Roof It should be noted this is intended for a standard game, its effects on third party variants of JSW is unpredictable. -
You're welcome. :) I'll see if I can find any more variants although those are the only 'immediate to hand' ones. I'm not 100% sure if you can download the version from the archive link though, but while (hopefully not permanently) the live version is down it appears to be the only link.
-
The only links I can find for this are as follows. :) I have not examined the files to check their reliability or freedom from virii but I would be surprised if they did contain anything they should not: https://www.old-games.com/download/2358/jet-set-willy-ii-the http://div-arena.co.uk/wips/view/302 , Note: This link is not currently working. Try via the Archive here instead
-
Yes. :) The one in 'To the Kitchen' because as you know he can jump and land on top of it = not good! But you're completely correct regarding jumping up/across. See pic "in action" The Wine Cellar while I jump to avoid the floor guardian:
-
Yes :) , he can walk through them but not either jump from below or above and hit them, as in if he jumps all the way through it, he will die.
-
There is a side-effect from this actually I just noted. Willy can pass though fire cells in some instances, with a bit of care. The asterix on 'To the Kitchens...' he can pass through it from left to right if he jumps from underneath, with care, he must not land on top of any fire cell however. Passing right to left is a case of just walking through it! :) Standard un bug fixed (complete with keypad and attic bug etc) game engine, no other pokes applied except the one you indicated.
