News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_pmeier

Boulder Dash All Stars

Started by pmeier, 17:48, 27 October 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

pmeier

Can't get enough of Boulder Dash:o

After converting the caves from Boulder Dash 2 from the C64, I wondered how all the other caves would feel like with the BD4 engine...

So I converted all caves from BD1 and BD3, too. Back in the days I was too lazy to convert the caves with the Construction Kit. Without tools this would be just too much work. Sadly I never converted cave I in which you really see the difference between BD1 and the BD4 reimplementation. Curiously BD4 feels like the Nintendo conversions. IMHO. (I can't say which engine is better BD1 or BD4...)

The zip contains two disks, because I provide all caves ready to play and to edit. BD4 came without editable caves which was quite a pity. But now there you go: I also reimported the BD4 caves. The colors should now be closer to the original and I tried to make the caves behave as they were intended. But I also added the original caves.

I also added BD2, so this is a very complete collection  8)

To do all this I wrote some command line tools in Java to convert the caves. Maybe you find them useful, too. [LINK REMOVED, UPDATE COMING]


pmeier

To convert the C64 caves I had to understand the CPC file format. Unfortunately we don't have such an awesome page like the C64 Boulder Dash Inside FAQ, so I had to to it myself:

Boulder Dash Construction Kit for Amstrad CPC
---------------------------------------------

.CAV/.INT file format
---------------------
Offset  Bytes  Range  Description
------  -----  -----  -----------
0000    0045          AMSDOS header (start address: #0051, length: #0385)
                      NOTE: Nothing in the header is used, just make sure
                            start/length/filename/checksum are valid!
0045    0001   40-5F  background color  (not used, see #400)
0046    0001   40-5F  foreground color1 (not used, see #401)
0047    0001   40-5F  foreground color2 (not used, see #402)
0048    0001   40-5F  foreground color3 (not used, see #403)
0049    0001   40-5F  border color      (not used, see #404)
004B    0001          filename[4] (not used)
004C    0001          filename[5] (not used)
004D    0001          filename[6] (not used)
004E    0001          filename[7] (not used)
004F    0031          AMSDOS header
0080    0370          40 x 22 = 880 bytes of cave description (including all borders)
03F0    0001   0-99   cave delay as decimal hex (*)
03F1    0001   0      unused
03F2    0002   0-999  cave time in seconds as decimal hex (high byte first)
03F4    0001   0-99   diamonds needed as decimal hex
03F5    0001   0      unused
03F6    0001   0-99   diamond value as decimal hex
03F7    0001   0      unused
03F8    0001   0-99   bonus diamond value as decimal hex
03F9    0001   0      unused
03FA    0001   0-99   slime permeability as decimal hex
03FB    0001   0      unused
03FC    0002   0-999  amoeba time of growth as decimal hex (high byte first)
03FE    0002   0-999  magic wall time as decimal hex (high byte first)
0400    0001   40-5F  background color
0401    0001   40-5F  foreground color1
0402    0001   40-5F  foreground color2
0403    0001   40-5F  foreground color3
0404    0001   40-5F  border color

(*) decimal hex: #11 means 11 seconds, #A-#F is never used

Boulder Dash Objects
#00 = space
#01 = voodoo Rockford
#02 = slime
#03 = growing wall
#04 = boulder
#05 = brick wall
#07 = magic wall
#08 = dirt
#09 = butterfly
#0a = firefly
#0b = diamond
#0d = titanium wall
#0e = amoeba
#10 = open exit
#11 = exit
#12 = inbox
#13 = border titanium wall

.GAM file format
----------------
Offset  Bytes  Range  Description
------  -----  -----  -----------
0000    0080          AMSDOS header (start address: #060a, length: #11f5)
                      NOTE: Nothing in the header is used, just make sure
                            start/length/filename/checksum are valid!
0080    0001          number of caves + 1 as decimal hex (example: #11 means next cave is cave no. 11)
0081    0001          number of caves + 1                (example: #0B = 11)
0082    0002          last cave address (high byte first)
0084    0013          1 byte for each cave:
                      #00 = not selectable intermission
                      #01 = selectable intermission
                      #80 = not selectable cave
                      #81 = selectable cave
0097    0001   0      unused (start of cave data header, header length = #18)
0098    0002          cave end address (high byte first) where cave end address is:
                      first cave end address: #0622                     + length of cave data (including header)
                      next  cave end address: previous cave end address + length of cave data (including header)
009A    0001          cave delay as decimal hex
009B    0001   0      unused
009C    0002   0-999  cave time in seconds as decimal hex (high byte first)
009E    0001   0-99   diamonds needed as decimal hex
009F    0001   0      unused
00A0    0001   0-99   diamond value as decimal hex
00A1    0001   0      unused
00A2    0001   0-99   bonus diamond value as decimal hex
00A3    0001   0      unused
00A4    0001   0-99   slime permeability as decimal hex
00A5    0001   0      unused
00A6    0002   0-999  amoeba time of growth as decimal hex (high byte first)
00A8    0002   0-999  magic wall time as decimal hex (high byte first)
00AA    0001   40-5F  background color
00AB    0001   40-5F  foreground color1
00AC    0001   40-5F  foreground color2
00AD    0001   40-5F  foreground color3
00AE    0001   40-5F  border color (end of cave data header)
00AF    11C5          run length compressed cave (including all borders)
                      each byte has this compression rule:
                          the first three bits are the count, the last five bits are the element
                          if the first three bits are zero, then the byte is the element itself and the next byte is the count
                      element specification is identical to .CAV file format
                      ends with #FF, then follows next cave end address and so on...
1274    0001          in theory: the last byte of the last cave, in practice: garbage,
                      because it is unlikely that a cave will fit exactly in the remaining space

Hope this could be useful for future projects... Like including the new elements in BD4?? Or even use this file format in BD1??  :o

XeNoMoRPH

#2
your amstrad news source in spanish language : https://auamstrad.es

pmeier

Yeah, it's cool that the BD scene is still active... But be warned: I can do bulk imports with my tools  ;D

Powered by SMFPacks Menu Editor Mod