Boulder Dash Forum

[Rocky]

Hello,

I am looking for precise infos about how long it takes until the moving or falling objects do one step. I would like to know it for the daimonds an boulders also as for Rockford, the fire fly and the butterfly to give my Boulder Dash clone a original speed feeling. Can you help me?

Thanks! Markus

[Dustin]

Hi,
I don't know the very precise answer, and it's 4 months ago that you posted your question, but I still hope it helps you:

The time unit is the same for every movement: the time for a boulder falling one unit is the same as for a fly or Rockford moving one unit. What I don't exactly know is how long this time unit takes. It's, of course, level- dependant, and it must be around 180 milliseconds on level 1 and around 100 milliseconds on level 5, but the differences between the levels aren't exactly equidistant. I don't know it more exactly, unfortunately, but perhaps it helps you a bit.

Greets Dustin

[Rocky]

Thank you! :-)

[cirix]

hi rocky,

some months ago, we did exact measurements with cws to check the speed of different bd engines. if you are interested, i can send you the results and calculations, and the algorithms i use in gdash to emulate the original speed of the games.

bye
_________________
cirix

[Rocky]

The original speed and times would be helpful for me.

[LogicDeLuxe]

Why not just post them right here?
I would add those to my Dash-FAQ, if you don't mind. Credits given, of course.

[Dustin]

Yeah, post'em here, I'm interested, too!

[cirix]

hi

so here they are: http://jutas.eet.bme.hu/~cirix/gdash/ckdelay.xls

the gdash source also always contains the newest version of the table. the last column is the microseconds delay each element (for example, each firefly) induces. (src/cave.c has a big table of cave constants at its top. you can use winrar to open the .tgz file.)

boulder dash 1 and the construction kit is a different engine. the construction kit is noticeably faster! newer versions of the engine, i think starting from 1stb are even faster.


therefore, for bd1 and bd2 games, i use:
88ms + 3.66ms*delay_value + delay_by_elements + delay_by_animation.
delay_value is 12 for level 1, 6 for level 2, ...
delay_by_elements is what you can see from the table in the xls.
delay_by_animation: caves were slower, if there were more elements to animate. (for example, if the cave contained amoeba.) i add 2.6ms for each animated type (amoeba, slime, butterfly, firefly) found.

for plck and above, i use:
65ms + delay_by_elements OR 20ms*delay_value, whichever is greater.
that is, a totally empty cave has the same speed for delay values 0, 1, 2, 3, and it is only slower for delay value 4 and above.

elements were sometimes fast, sometimes slow to process. for example, a firefly which can move is processed quickly. a blocked firefly is slower to process. the xls table contains an estimated average for each element.

also, explosions were very slow. for creature explosions (3x3=9 cells), i add 1.2ms. for cross-shaped explosions (ghosts, bombs, 5 cells) i add 0.65ms. for the voodoo, i add 1ms to the delay_by_elements explained above.

bye
_________________
cirix

[cirix]

some other things i have noted:

All these values are rounded up to n*20ms during the game. The 20ms value comes from the 25fps PAL signal, which is interlaced, so 50Hz screen refresh. The processing of the cave does not always take the same time interval, so delays change frame to frame. For BD1, cave A/1, I have measured 140ms, 160ms; and also 120ms (relatively rare). The above expressions give an average to work with: for that cave, the result is 150ms.

Crazy Dream 7 is somewhat different. It has a lot of elements, so it is slower than the construction kit. For that one, I use
130ms + delay_by_elements OR 20ms*delay_value.
If the cave contains a pneumatic hammer, and the hammered-walls-reappear flag is set to true, caves become very slow. I add 60ms for that. Check the cave "Buddel" for an example, which runs at 240ms/frame.

Measuring cave speeds in the VICE emulator is very simple. Load BD in VICE, select saving sound output to a .wav file. Start the cave, step a few cells with the player. Exit VICE. Open the wav file in a sound editor; select the noise of one step and the silence after it. The wave editor tells you the length of the selection: which was exactly one frame in the game. Beware, that frame times sometimes differ from each other; see above.
_________________
cirix

[LogicDeLuxe]

I checked BD1 intermission timing. As said, it reduces the vertical size. To be exact, you can freely walk in lines 2 to 14. Walking to line 15 results in a permanent delay state, as you would get in line 22 on a normal cave.
Same delays, but faster, since less lines are processed.

[cirix]

hi

i did some measurements on bd1 intermissions:

[LogicDeLuxe]

[cirix]

[subotai]

Thanks for the informations. Your calculations seem to be very good! For the moment, I'm working a bit on the timing for my remake. I'm not sure if this was already mentioned here, but one interesting point is that a second in the C64-emulator is slower than a real time second. 50 seconds in a C64 game take about 60 seconds in real time. This seems to be valid for all engines!? The timer speed in Gdash is adjusted to the C64-Timer speed.

[LogicDeLuxe]