Boulderdash conversion

[HerzAusGold]

Hi,
I now convert nearly all D64-Files for BoulderDash from TOSEC.
I upload the new version of RNDTEST with some loader's for original BoulderDash games with "level" format (means where "level" can changed)
e.g.:
- ArnoDash21 (packed by DeluxePacker)
- AtlantisDash25 (fixed cave 8 )
- AtlantisDash26 (fixed cave 16 )
- BilderDash (not packed - is 1:1 OTO)
- BoulderChange (BD64 packed format)
- BoulderDashRocky (BD64 packed format)
- BoulderDash (BD64 packed format)
- BoulderDash01 (BD64 packed format)
- BoulderDash02 (another shorter BD64 packed format, WLC2)
- aso.

In summary there are about 48.800 levels available.
In directory BoulderDashTosec:
CAV Files: 30287
INT Files: 6753
WLC Files: 10312
OTO Files: 1181
DLP Files: 294
-----------------------
summary 48827

Many levels are playable, but many level's are not playable - because there is no real BoulderDash-Engine.
OTO levels have many new elements which not exists in RnD. So they are not playable.
But can take as an example for new levels.
Unknown elements can be configured in bdcff.conf (example included)

Here: http://www.arthurdent.de

Have you already played one of the BD games? Or all caves?

Now it's up to you Holger to write a Boulderdash engine.

Reader for the .RAW dump will be uploaded soon.

[Holger]

Have you already played one of the BD games? Or all caves?

Not all , but some of them indeed seem to be playable, although levels using the amoeba sometimes are unplayable, as it grows too fast.

Now it's up to you Holger to write a Boulderdash engine.

Yes, and as mentioned, I'm currently working on it (integrating the GDash engine into R'n'D, which seems to be the best open source BD engine that's currently available). I can already play the BD levels included with it (it also comes with a BDCFF loader), and it even plays the few replays (tapes in R'n'D slang) that are included with some of the levels without errors.

But it still needs a lot of fine-tuning before it can be released. But I'm optimistic that R'n'D will finally get the native BD engine this year that I promised decades ago.

[HerzAusGold]

Not all , but some of them indeed seem to be playable, although levels using the amoeba sometimes are unplayable, as it grows too fast.

Amoeba growing speed:
Do you have an example for me? Filename or GameName? Level?
Then I can check them.

WLC levels have one parameter, which is used for "magic wall time" and "amoeba delay before growing"
WL2 levels can have two parameters. Maybe the amoeba parameter is corrupt.

[Holger]

Amoeba growing speed:
Do you have an example for me? Filename or GameName? Level?
Then I can check them.

This one:

btw. BDCFF -> this levelset is original BD01 with 20*5 levels.

For example, see level 8, which has an amoeba with speed 75, which is incredibly fast.

In comparison, I use the value "4" in the corresponding level (which is level 7 there) of the R'n'D classic BD1 level set "classic_boulderdash". But I cannot remember anymore if I have adjusted this manually or not. The problem is that R'n'D's amoeba and BD's amoeba have a different interpretation of what a value of X for "amoeba speed" exactly is. :-/

However, the upcoming native BD engine will behave correctly here, and will have the exact same amoeba speed as in the original C64 game.

WLC levels have one parameter, which is used for "magic wall time" and "amoeba delay before growing"

Yes, the classic game uses one value for both game elements.

WL2 levels can have two parameters. Maybe the amoeba parameter is corrupt.

No, I think the problem is indeed the R'n'D game engine here. :-/

[HerzAusGold]

No, I think the problem is indeed the R'n'D game engine here. :-/

Yes you are right. In original BD there is no parameter for the amoeba speed! (this is hardcoded).

It's a delay, e.g:
parameter at offset 0001: 0x14 -> Magic wall/amoeba slow growth for: 20 seconds (any value between 0x00..0xFF is possible)

That means, in the first 20 seconds amoeba slow grow, then faster.

[Holger]

Yes, exactly. The upcoming native BD engine will handle this correctly.

[HerzAusGold]

Hi,
upload version 4.3.8.1 with source code again.
New Loaders for .WL2 (original C64 file format (e.g. BD02) with more Commands to draw the levels)
Like before, but now with additional parameter (colorbg1, colorbg2, colorfg) and two parameters:
one is the extra amoeba delay, with is separated from magic wall time in the WL2 files.

And upload all BD-Reader with source in one solution.

[HerzAusGold]

Hi,
upload version 4.3.8.2 with source code again.

New Loaders for .DL2 (caves extracted from DeLuxePacker file, with many new elements)
Mostly not playable because new elements not exists. But loaded to visit in game editor.
DL2 can be configured with the .BDCFF Config file (example included).

Loader for .OTO file (OneToOne file format, with many new elements)
Mostly not playable because new elements not exists. But loaded now, to visit in game editor.
OTO can be configured with the .BDCFF Config file (example included).

you can find it on http://www.arthurdent.de
-> rndTest-4.3.8.2-rc17 (release candidate, immediately playable) -> with the converted BoulderDashTosec levels.

Now there are about 45000 BD levels available, converted from TosecArchive.

-> If you have any BD game (for C64) not already included in TosecArchive, please give me a link here,

[Holger]

Mostly not playable because new elements not exists. But loaded to visit in game editor.

Finally! All those levels will be playable with all new BD game elements using the new native BD game engine in the next R'n'D version!

Two things should be sorted out now:

- Which BD games are still missing from the large GDash level package that's instantly playable with R'n'D now?
- Should there be native loaders in R'n'D, or should they better be converted to the BDCFF file format?

Then there's also the "any2gdash" program that claims to be able to convert anything that remotely looks like a BD cave set (from D64 files to C64 memory dumps etc.) to either the GDash binary cave set format (.gds) or to BDCFF files (not sure at the moment, haven't checked recently, but will do).

This might have the advantage of having only one single place to maintain native BD cave loaders. But at least for otherwise unsupported cave formats, a native cave loader as part of R'n'D would probably also be a good solutiion when compared to yet another external command line tool.

[HerzAusGold]

Which BD games are still missing from the large GDash level package that's instantly playable with R'n'D now?

I do a comparison -> result on the Boulderdash forum. But this is not complete. Comparison from myList to Gdash missing.
But I will do that.
-> Can you convert all BDCFF (.bd) set's into ".gds"? This make it easier to compare.
-> Can't create BDCFF files from my raw dump's. And even when I can, it's difficult to compare (e.g. intro, sort order of parameters, aso.)

Should there be native loaders in R'n'D, or should they better be converted to the BDCFF file format?

-> I write loaders for .CAV / .INT (Atari, C64) and for BDCFF (but this is not complete, the GDASH loader is better)
-> and Loader's for BD4, GAMEBD (Boulderdäsh), WLC (BD1 format), WL2 (BD2 format), DL2 (Deluxe Packer unpacked), OTO (OneToOne)

-> The reader's I wrote make the main job, converting raw dump's to a format like .gds (create header, create map, append (unused) commands, append parameters (WLC, WL2, DL2, OTO)

-> I think BDCFF and GDS should be enough

-> may be a native loader for C64 files which work with BD commands (BD01 + BD02 format exists) seems usefull (without a map).
But today no need to save disk space...
-> I think support the ".gds" format is a good solution. No need to change program for a new format, only write a reader for it (or use any2gdash)

I think I use "any2gdash" or rewrite my readers to create ".gds" files.
It's easy to compare ".gds" files. And then I can find out if my readers work correctly.

Conclusion: Loader for GDS and BDCFF is enough.

[Holger]

-> Can you convert all BDCFF (.bd) set's into ".gds"? This make it easier to compare.

As BDCFF is aimed to be the canonical and "final" format for BD caves, there is no function available to save in ".gds" format (although it should be relatively easy to write an already loaded cave set into this file format).

Conclusion: Loader for GDS and BDCFF is enough.

Yes, I agree.

[HerzAusGold]

Hehe,
the ".gds" file are multi format

My files WLC and WL2, DL2 or OTO are multi format too. In the header there is a format description.
I decide that this is not enough, and set the extension to the format description.

Extension for ".gds" is always the same, only the format in the header is different.

Code: Select all

GdCavefileFormat gd_caveset_imported_get_format(const byte *buf)
{
  const char *s_bd1       = "GDashBD1";
  const char *s_bd1_atari = "GDashB1A";
  const char *s_dc1       = "GDashDC1";
  const char *s_bd2       = "GDashBD2";
  const char *s_bd2_atari = "GDashB2A";
  const char *s_plc       = "GDashPLC";
  const char *s_plc_atari = "GDashPCA";
  const char *s_dlb       = "GDashDLB";
  const char *s_crl       = "GDashCRL";
  const char *s_cd7       = "GDashCD7";
  const char *s_cd9       = "GDashCD9";
  const char *s_1st       = "GDash1ST";

But this is not enough, some special hack's exists too...

It's a shame that I don't know about GDash and Any2Gdash up to now.
.GDS is the swiss knife.
And BDCFF is for all who don't want struggle with this binary formats