Extra Caverns

[Spider]

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 ? :)

[IRF]

It should be possible to calculate a couple of 'invalid cavern numbers' which would map to the following unused areas of code: #9400-#97FF and #9800-#9BFF.

 

That would allow you to have two extra caverns without compressing the existing ones.  But you would need to edit the start of the 'Move to the next cavern' routine to get the game to access the two new caverns (and so that Willy proceeds after completing them back to the Central Cavern).  As things stand, they would both be 'horizontal and vertical guardians present' caverns by default.

 

And as you say, you would have to manually create the caverns in the hex editor, because the GUI in JSWED wouldn't display them.  But you could open a new file, create the new 'invalid caverns' from scratch in the place of two existing caverns, and them copy their definitions wholesale (1024 bytes per cavern) across to the above addresses in the original game file.

[Norman Sword]

Compressing caverns is very easy, however the game engine uses specific references to data within the room data. 

These references would all need changing 

JSW moves the room data into a specific area and the game engine then uses the fixed data positions. 

It would be possible to compress the data and modify the game engine to used fixed references (as per JSW) when playing a room, this permits the full usage of very aggressive compression on the room data. 

I would imagine 40+ rooms easily,  (without looking at any data to quantify my statement) 

This is not something I plan on doing or want to do.
 

[IRF]

Obviously compression of the cavern data would allow a lot more caverns, but as Norman says it would require a lot of work on the code to implement.

 

Just to add to my two penn'orth from earlier, the two new caverns that you could create without compression, by using the spare addresses #9400-#9BFF, would have technical cavern numbers #39 (57 in decimal) and #3A (58 in decimal).

 

You could test this out by copying data from existing 'new' caverns* into those addresses, load up the file and POKE the current cavern number (POKE #8407, #39) whilst the Title Screen tune is playing, and then press ENTER to start up the game.  Things will break down once you enter the portal in the second of the two caverns!

 

(*I would suggest something sufficiently distinctive from the 20 original caverns, so that it's clear that the 'invalid caverns' are working properly. e.g. why not choose a couple of caverns from Andrew Broad's laterally inverted version of MM? Make sure you choose two of the later caverns without 'special' features. i.e. two caverns with vertical guardians but no Skylabs, Kong, Eugene, Solar Beam or Final Barrier.  Obviously you could just copy two of the original MM caverns from the higher addresses of the same game file, but then it wouldn't be immediately evident that Willy wasn't just occupying one of the regular caverns!  I think that '...Mutant Telephones' and 'The Bank' would be best, because the difference in the mirrored version is obvious by the fact that the '10p' coins and the '

Edited October 20, 2018 by IRF

[Norman Sword]

Curious to see the extent of room graphic data that is referenced by the game code, So I have done a quick scan through a listing.

Not as many as I thought.

These are the references to room specific data
The Final Barrier Data 

Boot Graphic Data
Plinth Graphic Data 
Swordfish Graphic Data 

(might be more, but not a significant amount of references)

[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.

[Spider]

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

[IRF]

 

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

 

Items should be okay in MM as they are specified in each cavern's data, unlike in JSW where there is a global item table.

[Spider]

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.

[IRF]

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.

 

Sorry, is that a response to my suggestion, or Norman's?

 

Because you wouldn't have to move ANY routines to use caverns #39 and #3A.  The addresses that they occupy is unused source code, you can just NOP it out and it makes no difference to the running of the program.  So it would just be a case of populating it with 2048 bytes (two caverns worth) of cavern data!