Spider
-
Posts
5,289 -
Joined
-
Last visited
Everything posted by Spider
-
I was thinking about this earlier, although not terribly practical (maybe?) , there may be little need to actually compress the caverns at all. Perhaps utilising the 128's extra memory via bank switching would allow plenty of caverns. I've not looked into how this could be done without moving a whole chunk though rather than just the cavern 'area data' Food for thought perhaps...
-
That looks very good indeed! :) :) Will follow progress, thank you for sharing the information with us! Am sorry to hear you have had issues actually registering here, I do plan a change on this actually at some near point to hopefully simplify it a little bit.
-
External reviews: http://www.indieretronews.com/2018/10/manic-mixup-remix-of-matthew-smiths.html http://idpixel.ru/games/manicmixup/ http://planetasinclair.blogspot.com/2018/10/manic-mixup-2018-manic-miner-remix.html Google Translate or similar may be needed for the latter two. It is (in Google's Cache at least) mentioned on http://www.elmundodelspectrum.com/index.php however I am not able to currently find their 'review' of it. Another > https://www.classic8bit.com/games/sinclairspectrum/842-manic-mixup Spectrum Computing > https://spectrumcomputing.co.uk/forums/viewtopic.php?t=1074 https://pulsaunatecla.blog/2018/10/28/manic-mixup/ YT video as well from ZXSpectrumUser: https://www.youtube.com/watch?v=-sRNliKMdns YT video from SabreMan: (download link on the video description is currently incorrect) https://www.youtube.com/watch?v=k1rFn2FQR5M
-
Ian: Sorry. It was not really directly aimed at anyone apart from the first line about the items location. :)
-
That's a very good point about the items. :) JSW went a bit screwy when I experimented briefly with this a few months ago (I did not really have time to look into it much then), although I think if you either have the 'moved rooms' to have no items you'd probably get away with it. Either that or not editing it at all in JSWED once the room data was moved. A different tool would have to be used, there are some Basic ones floating about that could be very easily modified to take advantage of the differing room start address, although in comparison to JSWED they are quite fiddly to use. Back to MM: Changing all the addresses in the main loop and other routines to move the code up to free that large space chunk is quite a bit of work! My logic tells me that in itself would provide space for two more caverns without any compression to them, given that each one is 1024 bytes and you'd free 2484 or so bytes up. :unsure: It does seem quite a lot of work for a small gain though.
-
I have moved some of those items Norman mentions (Ian will be aware what I am on about here with 10CC) to occupy other space, easy enough to put them elsewhere and a couple of tweaks. The main one is the Final Barrier data really as that's a relatively large chunk to hide somewhere
-
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
-
