Boulder Dash Forum Forum Index Boulder Dash Forum
The only Boulder Dash discussion board in English language!
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Speeds in Boulder Dash 1
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Boulder Dash Forum Forum Index -> Games: Remakes
View previous topic :: View next topic  
Author Message
Rocky
Member


Joined: 19 Mar 2008
Posts: 40

PostPosted: Tue Apr 15, 2008 5:59 am    Post subject: Speeds in Boulder Dash 1 Reply with quote

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
View user's profile Send private message
Dustin
Member


Joined: 23 Sep 2007
Posts: 334
Location: Erlangen, Germany

PostPosted: Sun Aug 24, 2008 1:08 am    Post subject: Reply with quote

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
View user's profile Send private message
Rocky
Member


Joined: 19 Mar 2008
Posts: 40

PostPosted: Sun Aug 24, 2008 1:10 am    Post subject: Reply with quote

Thank you! :-)
Back to top
View user's profile Send private message
cirix
Member


Joined: 01 Feb 2008
Posts: 284

PostPosted: Sun Aug 24, 2008 7:35 pm    Post subject: speeds Reply with quote

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
View user's profile Send private message Visit poster's website
Rocky
Member


Joined: 19 Mar 2008
Posts: 40

PostPosted: Sun Aug 24, 2008 8:05 pm    Post subject: Reply with quote

The original speed and times would be helpful for me. Smile
Back to top
View user's profile Send private message
LogicDeLuxe
Member


Joined: 15 Jul 2007
Posts: 596

PostPosted: Sun Aug 24, 2008 8:43 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Dustin
Member


Joined: 23 Sep 2007
Posts: 334
Location: Erlangen, Germany

PostPosted: Mon Aug 25, 2008 2:54 am    Post subject: Reply with quote

Yeah, post'em here, I'm interested, too!
Back to top
View user's profile Send private message
cirix
Member


Joined: 01 Feb 2008
Posts: 284

PostPosted: Wed Aug 27, 2008 8:32 pm    Post subject: speeds Reply with quote

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
View user's profile Send private message Visit poster's website
cirix
Member


Joined: 01 Feb 2008
Posts: 284

PostPosted: Sat Aug 30, 2008 10:59 pm    Post subject: some updates Reply with quote

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
View user's profile Send private message Visit poster's website
LogicDeLuxe
Member


Joined: 15 Jul 2007
Posts: 596

PostPosted: Sat Sep 13, 2008 11:57 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
cirix
Member


Joined: 01 Feb 2008
Posts: 284

PostPosted: Tue Sep 23, 2008 7:04 pm    Post subject: bd1 intermissions Reply with quote

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
View user's profile Send private message Visit poster's website
LogicDeLuxe
Member


Joined: 15 Jul 2007
Posts: 596

PostPosted: Tue Oct 21, 2008 7:37 pm    Post subject: Re: some updates Reply with quote

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
View user's profile Send private message Visit poster's website
cirix
Member


Joined: 01 Feb 2008
Posts: 284

PostPosted: Wed Oct 22, 2008 6:57 am    Post subject: Re: some updates Reply with quote

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 Smile full of stones, but the speed is still determined by the delay setting.
_________________
cirix
Back to top
View user's profile Send private message Visit poster's website
subotai
Member


Joined: 25 Jan 2009
Posts: 251

PostPosted: Fri Sep 21, 2012 11:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
LogicDeLuxe
Member


Joined: 15 Jul 2007
Posts: 596

PostPosted: Sat Sep 22, 2012 4:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Boulder Dash Forum Forum Index -> Games: Remakes All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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