Different engine versions and little bugs in them

Everything about the old and new Boulder Dash games for C64, Atari, ...

Moderator: Admin

Post Reply
User avatar
Simon
Member
Posts: 37
Joined: Sun Jul 01, 2007 10:29 pm
Location: Germany

Different engine versions and little bugs in them

Post by Simon »

Hello,
I'm a great fan of Arno's website and finally I decided to join the forum. The first time I played Boulderdash I think I was eleven or twelve and that was about 22 or 23 years ago.

I'm very interested in the different game engines used in BD1, BD2 and the fan made BD-games. I've read somewhere that the BD1 engine wasn't as perfect as it could be and that there are some improvements in the BD2 engine, for example. Can someone point me to a list of differences? Also, are there further differences between the BD1 and BD2 engines compared to the engines used in fan made BD games?

What bugs in the different engines are you aware of?

Are there fan made BD game engies capable of playing caves larger than 40x25?

PS: I'm currently interested in C64 engines only.
User avatar
Sendy
Member
Posts: 186
Joined: Sun Jun 17, 2007 10:33 pm
Location: Square Wave Heaven
Contact:

Post by Sendy »

The bugs I know of in BD1 are:

- Triggering the magic wall causes any amoeba present to turn into diamonds.

- The magic wall seems to slow the items down as they fall through it, meaning that if you tip a lot of boulders through at once, to convert them to diamonds, many will be wasted (because they are converting while the bottom of the wall is blocked). In later versions of the engine you can dump many rocks through the wall without fear of losing any (provided you have enough space underneath).

- BD1 seems to suffer from slowdown much more readily than the later engines do.

The fan games seem to come in two main flavours. Those running the BD1 engine and those running the Construction Kit engine (which seems to be an expanded version of the BD2 engine with extra elements - hidden exits and the rockford dolls). The BD1 engine uses a list of instructions to build the caves whilst the CK version has explicitly mapped caves.

But there were different builds of this engine depending on which packer was used to compile the game - some have dirt which is the same colour as the titanium walls (ugly) and some have a different sound for rockford's movement.

None of the modern remakes support larger caves, but there is the Crazy Light engine which features new objects and a lot of extra parameters in cave designing.

I'm sure Arno or RTA dash will be able to fill in the details and nuances I've missed and mistakes I've made :)
Watcher Kitty is always watching...
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Post by Arno »

Wow, a new member again - Welcome to the forum, Simon! :D Nice avatar also!

Indeed, what Sendy is saying. About the magic wall causing the amoeba to turn into diamonds, this trick only works if the amoeba is beneath (or possibly on equal height of) the magic wall.

BTW - have you already discovered the Boulder Dash Inside FAQ at Marek's site?
http://www.gratissaugen.de/erbsen/ (direct link here).

This document contains a lot of information about all the engines and the differences between them, and it's available in both English and German.
User avatar
Simon
Member
Posts: 37
Joined: Sun Jul 01, 2007 10:29 pm
Location: Germany

Post by Simon »

Hey, thank you for your answers. It's cool how much you all know about the things I'd like to know. There's plenty of information on Marek's site, too.

Isn't it funny that there are several fan made engine modifications but nobody ever tried to support caves larger than 40x25?

About my avatar image: The brick wall border is of course from the BD2 title screen, and inside there's the 6502 assembler listing of the inner part of BD1's cave scan loop.
John
Member
Posts: 14
Joined: Tue Jul 03, 2007 8:18 am
Location: Sydney

Post by John »

Sendy wrote:The bugs I know of in BD1 are:

- Triggering the magic wall causes any amoeba present to turn into diamonds.
Are you sure that this is really considered a bug?

I have a vague memory of a cave - most likely in one of the clones - where the only way to gather enough diamonds was to convert the amoeba by triggering a magic wall. In this cave it was impossible to enclose the amoeba, and impossible to create the required amount of diamonds by using the magic wall alone.

Does anyone know if such a cave exists, and in that case, where? :)
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Post by Arno »

John wrote:Are you sure that this is really considered a bug?
According to the BD Inside FAQ, this is a side effect of the restarting cavescan when a boulder falls into a magic wall. Given that this effect was removed in the BD2 engine, I think it should (historically) be considered a bug.

Boulder Dash 3 is probably the first game in which the bug is needed to complete some caves:

Int1:
Image

Cave O:
Image

But there are much more games deploying this effect. For instance, in Don Pedro's games it is also used a few times.
Last edited by Arno on Sun Jul 29, 2007 6:44 pm, edited 1 time in total.
John
Member
Posts: 14
Joined: Tue Jul 03, 2007 8:18 am
Location: Sydney

Post by John »

Thanks for the info! Interesting to know that it was removed in BD2.

I stumbled upon two levels while playing Boulder Rush that are impossible to win in that engine, "Game 17 Cave 15" and "Game 20 Cave 18". Does anyone know which games these come from? The first is an intermission similar to BD3 Int1, the second contains one magic wall and lots of amoeba all over the cave, 60 sec time limit and 99 diamonds required.
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Simon wrote:Isn't it funny that there are several fan made engine modifications but nobody ever tried to support caves larger than 40x25?
40x22 actually. It is mainly due to the scroll routine. It is emulating a virtual screen, probably because it's ported from the Atari version. This actually eats up about half of the raster time and uses a lot of memory (for a C64). Nobody tried to change the scroll routine, probably because, it works so well, especially in comparision to other games of that time.
Another 3rd of the raster time goes for the character animations.

Thus, there is merely one 6th of the CPU time for the actual game physic. Increasing the size of the map would not only occupy memory, which is barely left due to the demanding scroll routine, but this would also result in massive slow downs, which is the main reason. You can already notice a slowdown when there are a lot of diamonds or fireflies for example. No one wanted to make the situation worse.
Well, about the memory usage, actually no BD engine uses the RAM under the Kernel ROM, because it is somewhat cumbersome to make use of it. I used it in some of my tools, though.

The C64DTV could handle sigificantly bigger caves. It has more RAM, faster CPU and virtual screen support. A factor of 10 should be a realistic goal there. I might do this one day, I won't promise anything, though. In any case, there will be a CLCK 3.0 final first.
User avatar
RTADash
Member
Posts: 414
Joined: Sat May 26, 2007 3:21 am
Location: USA (in Ohio)

Post by RTADash »

LogicDeluxe wrote:but this would also result in massive slow downs
Plus some caves already experience slowdowns with the size as it is (Like BD4-O with all those F-flies - the delay is still 8 or whatever), so making the max size larger probably wouldn't be a good thing even if there was enough memory.
Boulders are round.
Fireflies are square.
I need to find
a'way out of here.
User avatar
Simon
Member
Posts: 37
Joined: Sun Jul 01, 2007 10:29 pm
Location: Germany

Post by Simon »

Wow, LogicDeLuxe, thank you for sharing all that percise internal knowledge about the BD engine with me, or with us.
LogicDeLuxe wrote:Well, about the memory usage, actually no BD engine uses the RAM under the Kernel ROM, because it is somewhat cumbersome to make use of it.
Maybe the original BD1 and BD2 engines didn't use any RAM above $C000 because the Atari had only 48K. By the way, I never quite understood why people think that using the RAM under the Kernal ROM is cumbersome. Permanently disabling the Kernal ROM would have even sped up the Raster IRQs a little bit. :)
LogicDeLuxe wrote:The C64DTV could handle sigificantly bigger caves. It has more RAM, faster CPU and virtual screen support. A factor of 10 should be a realistic goal there. I might do this one day, I won't promise anything, though. In any case, there will be a CLCK 3.0 final first.
I wonder how much sense it would make to built an engine that only works on a C64DTV...
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Simon wrote:Maybe the original BD1 and BD2 engines didn't use any RAM above $C000 because the Atari had only 48K.
The PLCK game modul does.
By the way, I never quite understood why people think that using the RAM under the Kernal ROM is cumbersome. Permanently disabling the Kernal ROM would have even sped up the Raster IRQs a little bit. :)
Right, it's actually the I/O, not the kernal adress space. Coders tend to stop there. BD actually could be modified to use the RAM under the kernal. Should be not that much work for someone building games with a hexeditor, like many of the early games were done. Though it's somewhat harder (but certainly not impossible) to have a levelpacker using all the RAM, since it has to be somewhere resident in RAM itself as well.
As my CrLi engine grew and the graphics with it, and most important the cave format, I started to use simple compression on the caves and increased the usable space to $CC00. That way, you can still use up to 48 caves. At least close to it in most cases. Uncompressed, there would be still space for 24 caves, which is more than the hardcoded 20 caves of the Knibble and early No One Packers.
I wonder how much sense it would make to built an engine that only works on a C64DTV...
I know, the board is badly designd, ie. bad luminance DAC rendering some things almost invisible (which can be corrected with a soldering rod) and weak color carrier which don't work on many TV sets (which requires a redesign of the circuit to fix it, much like as printed in the DTV's data sheets). And it's a shame that not all keyboard lines are accessible either (which is not required for the internal games, thus we probably never see that improved). The missing SID filters are the least concern as BD never used them anyways.
Post Reply