 |
Boulder Dash Forum The only Boulder Dash discussion board in English language!
|
View previous topic :: View next topic |
Author |
Message |
Rocky Member
Joined: 19 Mar 2008 Posts: 40
|
Posted: Tue Apr 15, 2008 5:59 am Post subject: 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 |
|
Back to top |
|
 |
Dustin Member

Joined: 23 Sep 2007 Posts: 336 Location: Erlangen, Germany
|
Posted: Sun Aug 24, 2008 1:08 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
Rocky Member
Joined: 19 Mar 2008 Posts: 40
|
Posted: Sun Aug 24, 2008 1:10 am Post subject: |
|
|
Thank you! :-) |
|
Back to top |
|
 |
cirix Member

Joined: 01 Feb 2008 Posts: 284
|
Posted: Sun Aug 24, 2008 7:35 pm Post subject: 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 _________________ cirix |
|
Back to top |
|
 |
Rocky Member
Joined: 19 Mar 2008 Posts: 40
|
Posted: Sun Aug 24, 2008 8:05 pm Post subject: |
|
|
The original speed and times would be helpful for me.  |
|
Back to top |
|
 |
LogicDeLuxe Member

Joined: 15 Jul 2007 Posts: 598
|
Posted: Sun Aug 24, 2008 8:43 pm Post subject: |
|
|
Why not just post them right here?
I would add those to my Dash-FAQ, if you don't mind. Credits given, of course. |
|
Back to top |
|
 |
Dustin Member

Joined: 23 Sep 2007 Posts: 336 Location: Erlangen, Germany
|
Posted: Mon Aug 25, 2008 2:54 am Post subject: |
|
|
Yeah, post'em here, I'm interested, too! |
|
Back to top |
|
 |
cirix Member

Joined: 01 Feb 2008 Posts: 284
|
Posted: Wed Aug 27, 2008 8:32 pm Post subject: 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 _________________ cirix |
|
Back to top |
|
 |
cirix Member

Joined: 01 Feb 2008 Posts: 284
|
Posted: Sat Aug 30, 2008 10:59 pm Post subject: 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. _________________ cirix |
|
Back to top |
|
 |
LogicDeLuxe Member

Joined: 15 Jul 2007 Posts: 598
|
Posted: Sat Sep 13, 2008 11:57 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
cirix Member

Joined: 01 Feb 2008 Posts: 284
|
Posted: Tue Sep 23, 2008 7:04 pm Post subject: bd1 intermissions |
|
|
hi
i did some measurements on bd1 intermissions:
Code: | 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 |
|
Back to top |
|
 |
LogicDeLuxe Member

Joined: 15 Jul 2007 Posts: 598
|
Posted: Tue Oct 21, 2008 7:37 pm Post subject: Re: some updates |
|
|
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). |
|
Back to top |
|
 |
cirix Member

Joined: 01 Feb 2008 Posts: 284
|
Posted: Wed Oct 22, 2008 6:57 am Post subject: Re: some updates |
|
|
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 |
|
Back to top |
|
 |
subotai Member
Joined: 25 Jan 2009 Posts: 251
|
Posted: Fri Sep 21, 2012 11:26 pm Post subject: |
|
|
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? |
|
Back to top |
|
 |
LogicDeLuxe Member

Joined: 15 Jul 2007 Posts: 598
|
Posted: Sat Sep 22, 2012 4:14 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|