Speeds in Boulder Dash 1
Moderator: Admin
Speeds in Boulder Dash 1
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
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
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
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
speeds
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
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
- LogicDeLuxe
- Member
- Posts: 638
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
speeds
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
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
some updates
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.
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
- Member
- Posts: 638
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
bd1 intermissions
hi
i did some measurements on bd1 intermissions:
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
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
bye
cirix
- LogicDeLuxe
- Member
- Posts: 638
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Re: some updates
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.cirix wrote:therefore, for bd1 and bd2 games, i use:
88ms + 3.66ms*delay_value + delay_by_elements + delay_by_animation.
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.
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).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.
Re: some updates
that is how i do it.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).
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
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: 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:So for BD1, i will use 88ms+delay for normal caves, 60ms+delay for intermissions.
Can somebody explain this any further please? What does "n" stand for?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.
- LogicDeLuxe
- Member
- Posts: 638
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
If playing on PAL machines, yes. Except for XDC, which is real time on any machine and much more reliable to the game mechanics.subotai wrote:50 seconds in a C64 game take about 60 seconds in real time. This seems to be valid for all engines!?
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.