Speeds in Boulder Dash 1

Everything about the modern clones and remakes.

Moderator: Admin

Rocky
Member
Posts: 40
Joined: Wed Mar 19, 2008 6:16 pm

Speeds in Boulder Dash 1

Post by 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
User avatar
Dustin
Member
Posts: 590
Joined: Sun Sep 23, 2007 1:15 am
Location: Erlangen, Germany

Post by 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
Member
Posts: 40
Joined: Wed Mar 19, 2008 6:16 pm

Post by Rocky »

Thank you! :-)
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

speeds

Post by 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
Member
Posts: 40
Joined: Wed Mar 19, 2008 6:16 pm

Post by Rocky »

The original speed and times would be helpful for me. :-)
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by 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.
User avatar
Dustin
Member
Posts: 590
Joined: Sun Sep 23, 2007 1:15 am
Location: Erlangen, Germany

Post by Dustin »

Yeah, post'em here, I'm interested, too!
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

speeds

Post by 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
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

some updates

Post by 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
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by 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.
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

bd1 intermissions

Post by cirix »

hi

i did some measurements on bd1 intermissions:

Code: Select all

LEVEL1:	steps	time (ms)	time/step	average	minus minimum (E67)	div by 3.66
	12	1060	88,33	88,30	27,59	7,54
	14	1240	88,57			
	15	1320	88,00			
LEVEL2:						
	15	1140	76,00	75,94	15,22	4,16
	15	1120	74,67			
	14	1080	77,14			
LEVEL3:						
	12	840	70,00	70,00	9,29	2,54
LEVEL4:						
	16	1020	63,75	64,38	3,66	1,00
	16	1040	65,00			
LEVEL5:						
	14	860	61,43	60,71	0,00	0,00
	16	960	60,00			
So for BD1, i will use 88ms+delay for normal caves, 60ms+delay for intermissions. the delay cycles seem not to be following the 12x - 6x - 3x - 1x - 0x scheme... but cannot measure that exactly.

bye
cirix
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Re: some updates

Post by LogicDeLuxe »

cirix wrote:therefore, for bd1 and bd2 games, i use:
88ms + 3.66ms*delay_value + delay_by_elements + delay_by_animation.
Seems okay for BD1, but BD2 seems different. I measured a walk from right to left in one go and measured the time from the beginning of the first noise to the beginning of the last noise, which is 36 steps. While you'll get indeed those numbers with no apparent relation to TV timing in BD1, the results I get for BD2 are perfect matches to multiple TV fields.
This is what I measure for levels 1 through 5 in BD2 cave A: 180, 160, 140, 120, 120.
Therefor, I assume that the timing is more similar to the PLCK than to BD1. Probably 9, 8, 7, 6, 6 in PLCK delay.
cirix wrote: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.
Actually, only the sound is "rounded" to 20ms, because the sound is processed in the interrupt. The cave timing itself is more steady, but not measurable by judging the sound. So taking a complete walk over the cave gives you a good idea of the actual time, ie. the average (which I did above).
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Re: some updates

Post by cirix »

LogicDeLuxe wrote:Actually, only the sound is "rounded" to 20ms, because the sound is processed in the interrupt. The cave timing itself is more steady, but not measurable by judging the sound. So taking a complete walk over the cave gives you a good idea of the actual time, ie. the average (which I did above).
that is how i do it.
some formulas are updated; you can see them in the src/caveengine.c of the gdash source tree. the atari formulas are already included. look for "GD_SCHEDULING_BD1".
i tested only bd2 atari thoroughly, it has exactly the same timing as you show above. it is more like the construction kit than bd1; the n*20 rule applies. cave p was a good cave to test :) full of stones, but the speed is still determined by the delay setting.
cirix
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by 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.
cirix wrote:So for BD1, i will use 88ms+delay for normal caves, 60ms+delay for intermissions.
@cirix: I don't know if you are still developing your great clone Gdash. However, I have the intention that 41ms+delay for intermissions is better (this seems to work good in my remake. But maybe my implementation differs a bit from yours). I remarked that Inbox-hatching in BD1-Intermissions is always a bit too early in Gdash concerning the game speed. That means that the delay value might be too big. Unfortunately, I don't know how to compile Gdash on Windows for testing. You can check Intermission 1 and 3 of Bd1 for example. It's also interesting to check the postition of the butterfly in Intermission 1 when the time runs out.
cirix wrote: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.
Can somebody explain this any further please? What does "n" stand for?
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

subotai wrote:50 seconds in a C64 game take about 60 seconds in real time. This seems to be valid for all engines!?
If playing on PAL machines, yes. Except for XDC, which is real time on any machine and much more reliable to the game mechanics.
On NTSC machines, it usually is real time, ie. 60 seconds for a real minute, since BD was designed for NTSC.
The only exception is the CrLi engine, which also slows down the timer to 50 seconds for a real minute on NTSC.
Post Reply