Extra Caverns

[Norman Sword]

I will chuck some figures around concerning the big chunk of data that is stored "the final barrier". When I was presented with that piece of data I wrote a simple piece of code and compressed it. The expansion code is small. The Final barrier data and the title screen data compressed into 170H bytes. The keyboard was stored separately, I think the keyboard compresses into 10 bytes. (the expansion code for the keyboard is not very big)  

It would be relatively easy to move the Final barrier graphics (compressed) , the boot, plinth and swordfish data into the unused source code space. The rest of that space could be used for code and un-compression routines. This then allows the room data to be compressed freely.

Again it would be a simple task to write a routine to compress two sets of game data and place then into what is now the room data space.

Yes a lot of work, but you end up with 40+ caverns, which would be two games merged.

--------------------------------------------------------

Another reason I would not do this is not concerning the data, compression or data layout, it concerns how the game mechanics check for room numbers before altering how the cavern plays.   


 

Edited October 19, 2018 by Norman Sword

[Spider]

Ian: Sorry. It was not really directly aimed at anyone apart from the first line about the items location. :)

[IRF]

Another reason I would not do this is not concerning the data, compression or data layout, it concerns how the game mechanics check for room numbers before altering how the cavern plays.

That would benefit from a rewrite to take a 'Patch Vector' approach, like Geoff Eddy's JSW games, using a spare pair of offset bytes in the cavern data to determine which special effect routine (if any) to implement.

Edited October 19, 2018 by IRF

[Norman Sword]

Trivia concerning the code that places the final barrier on the screen.
Manic Miner.

Code from 35388 to 35514

The Final Barrier

When this room is drawn, Matthew's code goes through an illogical sequence.

Matthews room drawing LOGIC as written in the game.

(1) Draw all the tiles for the top half of the playing area.
(2) Check we are in the Final barrier and erase the drawn graphics with the final barrier graphics
(3) Draw all the tiles for the bottom half of the playing area.
(4) And again check for the Final Barrier, then erase again the top half of the screen with the Final Barrier Graphics.

NOTE this writes graphics to the top part of the screen three times. (1), (2), (4)

 

This should have been as follows

Check for the Final Barrier and draw the graphics on the top half of the playing area.
Skip drawing the tiles for the top half of the screen
Draw the tiles for the bottom half of the screen.

Done

Draw the room routine at 35388
35388
    LD A,(33799) 
    CP 19   Is it The Final Barrier?
    jr nz,draw_it
    LD HL,40960   
    LD DE,28672 
    LD BC,2048
    LDIR
    jr draw2_it

draw_it
    LD IX,24064 
    LD A,112 
    CALL thirds 
draw2_it
    LD IX,24320
    LD A,120 

Thirds
    LD (S_M_C_A),A 
loop
    LD A,(IX+0) 
    ld de,9 
    ld b,8  
    LD HL,32800-9
ch_loop
    add hl,de
    Cp (hl)
    jr z,gotcha
    djnz ch_loop 
gotcha
    inc hl 

S_M_C_A equ $+1
    ld d,$
    ld e,lix
    call 37587 ; part of the print routine
    INC LIX  
    JR NZ,loop 
    RET

 

 

[IRF]

That fixes the Cell Graphics Bug as well, doesn't it?  (The Cell Graphics Bug doesn't actually affect any of the graphics in the original Manic Miner, but that's more by luck than judgement.)

 

The Trivia section of SkoolKid's disassembly has recently been updated with a mention of the dubious room-drawing logic in 'The Final Barrier':

 

http://skoolkid.github.io/manicminer/reference/facts.html#topHalfTwice

Edited October 20, 2018 by IRF

[Norman Sword]

If you read the comment I made and compare it with skoolkid's comment they are not the same.

 

The Skoolkid comment is that it draws the graphics twice.

In the Final barrier it draws the top half of the playing screen three times.

draw the top half of the room graphics  ---------------- 1) 1st write to the top of the screen
over writes with the Final barrier graphics-------- ------2) 2nd write to the top of the screen
draws the lower half of the room
Then writes the graphics for the final barrier again --------- 3) 3rd write to the top of the screen

[IRF]

Skoolkid is correct that the the graphic that you see as the end product gets drawn twice (no 2 and no 3 in your list).

 

But he omits to mention the first occasion that 'something' is drawn to the top half of the screen, although that 'something' (which never gets seen) is quite different.

 

****

 

More related trivia:

 

The attached screenshot was created by using POKE #8AAE, #C9 in order to disable the special graphic for the top half of the Final Barrier. 

 

Any attribute values in the layout of the upper half that aren't recognised as being the attribute of a defined cell type (or, thanks to the Cell Graphics Bug, a graphic data byte), cause the cavern-drawing routine to draw an apparently random pixel pattern into the corresponding screen cells.  (See the 'tree trunk' in the attached screenshot, for example.)

 

However, that pixel pattern is not random.  In the event that the CPIR loop in the original routine exits without having found a matching value for the attribute value that it is seeking for, (from the list of cell definitions stored in the region #8020-#8067), then HL will be left pointing at the next byte along, namely #8068.

 

The routine then picks up the next eight bytes #8068-#806F and interprets them as a pixel-pattern in order to draw a graphic in the appropriate cell.  But the first seven of those addresses are actually the bytes which define Willy's location and movement status upon his entrance to the cavern (#8068-#806E), whilst the eighth byte (corresponding to the bottom pixel-row of the odd graphic) is the conveyor direction byte (#806F).

 

****

 

P.S. In the attached screenshot, the crown of the tree and the windows of the house are examples of the Cell Graphics Bug in action.  The colour-attribute written to those parts of the screen don't match with an attribute from the list of the cavern's cell types, but they do match with a graphic data byte from some of the defined cell graphics for the cavern - the wall tile definition in the case of the crown of the tree, and the 'dangling spider' Fire cell in the case of the windows.

 

You can see part of the wall tile graphic drawn across the tree's crown, whilst the windows of the house are drawn using part of the 'spider' Type 1 Fire cell, and part of the (defined for the cavern but unused) 'stalactite' Type 2 Fire cell.

 

 

P.P.S. The green and yellow grassy areas provide a perfect attribute match with the wall tiles, so the full wall graphic is drawn across the 'lawn' areas of the upper half of the screen in the attached screenshot.

Edited November 29, 2018 by IRF

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