fawtytoo

I know you weren't scolding me (it's my port after all and I'll do what I want with it), but it made me think if I'd done too much to it on that level. Level design, for any kind of game, usually avoids being designed that allows game engine bugs to creep in, which is what my post is about. That particular level illustrates that. I guess that the change I made was a kind of "that's how I would have done it" but now feel I've deviated from the OG which isn't the design goal. "Game play is 100% identical" I think is my claim. That level breaks that rule. I'm just thinking out loud. Suggestion welcome.

When you die or exit a level in MM, nothing is drawn in it's final positions. That is, it's all one frame behind the game logic. This is most noticeable in the "Sixteenth Cavern" when you drop into the portal, collect the final item and exit the level. If everything was drawn up-to-date, the final item would be erased and you would see Willy's feet below the portal. But that doesn't happen. In order to address this and have the drawing up-to-date, I use an "Action" in my port that allows the game logic (ticker) and the drawer to complete before changing the state of the game. This works very well. Except for level 16. If I use the exact same level layout as the OG, as Willy falls through the portal to the final item, the item is collected. But as Willy is still falling, on the next frame he is no longer "inside" the portal and so falls onto the conveyor below. If I correct this, then I end up with the same visual anomaly as in the OG. Further fixes could be made but not without making the code unnecessarily complex for such a simple game. My solution was the move the final item one tile lower. But that looks odd and begs the question as to why. To further the solution and add a "reason" for the change was the add a gap in the conveyor below the portal to make it more obvious as to why the item is lower. The "reason" given was to provide more of a challenge to get the final item. On reflection, the final item should be placed immediately below the conveyor for the "challenge" and the conveyor gap was not necessary. But then why didn't Matt Smith do that? The whole point of this is that I considered that final item to be pointless and didn't need to be there. I think this is analogous to the uncollectable item in JSW "Conservatory Roof" where the solution was to remove the offending nasty whereas another solution would be to remove/reposition the item. @JianYang referred to my change as "very naughty". So I thought it needed a dedicated thread for the explanation/discussion.

Maybe. I wanted to remain faithful to the original but I just thought that level needed "correcting". I considered it a bug. If I'd been involved in the original development, the level handling would have been more like in my port. That is, no attribute dependency. That is the main flaw in both games that prevented having a "split" conveyor (amongst other things). Although, there are other ways he could have made that gap.

Compiling on Linux is a lot easier than on Windows. You need to install the packages ... libsdl2-dev build-essential ... then download the source code and type "make" from a command line from the same directory as the Makefile. Probably should add that to the README.md.

Hi guys and gals, Just thought I'd upload the latest releases of MM & JSW for Windows. They are 64bit only but should work on 7 onwards. Any feedback on compatibility would be welcome. Regards, Steve ManicMiner.zip JetSetWilly.zip

Thanks to @AukonDK for the Windows builds. Would anyone here be interested in maintaining a Windows build on my GitHub repository? It's just that I've just fixed a crucial bug and now those builds will be out of date. Or, at the very least, maintain those Windows builds on here or somewhere else I can link to?

This bit took me ages to work out using the disassembly from skoolkit. As regards JSW, the movement mechanics were altered to fit the situations (such as The Forgotten Abbey), hence the head height bug. In my re-write, I fixed the situations with new block types to keep the MM mechanics. Of course, I did the changes only to fix the bugs and not change the game play.

I signed up to this website after noticing this thread. I'm not much of a binary kind of guy, just happy to share the code. Not much interested in Windows, so sorry there too. Thanks for the mention here.