Spider
-
Posts
5,294 -
Joined
-
Last visited
Everything posted by Spider
-
I had chance to play this Sunday evening, once I'd figured out the very strange way disk images are accepted in Steem (its not explained that well in the emulator readme, or I missed it!) and got a suitable TOS for it as the higher version one did not play nice. :) , none of that is related to the game however. The game plays quite nicely, it has the feel of the SamCoupe version to it in that the movement is more fluid than the Amstrad/Spectrum versions. I sent you a PM reply about the text (you have that already) The sound is very good and I like the effects of the Portal too. The air supply decrements quite slowly although this may or may not be a concern. There are some interesting novelties too such as Willy dancing on the title page with his erm 'partner' as well as the arcade style left/right to enter a name into a high score table. A+ for this addition! The cavern design particularly the 'pac man' wall effect is also excellent. The only real concern I had in my short playtesting time (so far) was the boot takes a while to initially start to descend on the Game Over page. :) Summary is this is so far an excellent piece of work imo. :thumbsup: I'm attaching a few screenshots too! Finally a few screenshots I took 'mid play' :) Proof in the pudding as they say with my Hi-Score, unfortunately emulation did not pause in Eugene so I lost a life taking a screenshot!
-
The solution is so obvious when I saw it. :blush: I stayed on the righthand side of the wall and then tried various tricks to jump/land safely, with a vague idea of passing his head through a cell. Come to think of it I'm not quite sure how well those kind of 'quirks' are in JSW64 / JSW128 if at all... The extra fire cell is about where I would of placed it too, to prevent an 'unintended escape' :)
-
Yes it by default removes four "units" of air: Any more than four is quite difficult, sometimes just two can be if the player is a bit slow to manoeuvre around
-
That's quite good. The change is very easy to see. Regarding the small challenge: I was not able to survive the jump down after the wall had gone, despite trying! I suspect the correct method may involve a quirky manoeuvre, possibly by allowing his head to pass into a solid cell :unsure: However I managed to *ahem* cheat my way out ;) I don't (think) this was intended escape route as its possible in both versions ? , one extra fire cell could prevent this though. Attaching two very small .rzx's of the escape, the 'fixed version' one is slightly quicker... Unfixed_Escape.rzx Fixed_Escape.rzx
-
I fixed the math results, although they did "pass" when I tried them, but I could see a potential problem especially for those for whom English is not their primary language. :) This time there's no doubt as its not shown. I registered correctly with a normal combination, FB and TW register can be slightly off sometimes but its due to external factors unfortunately, I might actually disable those. At least you're here now! :thumbsup: Downloaded. :) :) Will try it out later today all being well.
-
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.
