I see that sometimes people have great timing on the software, but when they upload it to the website the timing is like off. Sometimes it's minor, but other times it's MAJOR. Reply if you support.
Offline
The problem is the wait blocks.
I'll show a better way below.
The "wait until" blocks do just that, wait for so many seconds...
However, the actions you put between wait blocks take time... even if just a tiny bit of time.
These actions (move, change costume, effects..) work faster or slower depending on the speed of the computer and if it's online or in scratch...
How we usually write this:
<play sound[ talking
<switch to costume[ closed mouth (this may take a little more time online)
<wait( 2 )secsc>
<switch to costume[ open mouth (just a little time)
<wait( .5 )secsc>
<switch to costume[ closed mouth (but it's adding up)
<wait( 5 )secsc>
<switch to costume[ open mouth (and the action starts to get out of sync with the sound.)
<wait( .5 )secsc>
<switch to costume[ closed mouth
After a bunch of this, it's going to get out of sync. Each action takes time, so the total time is going up... and becomes more noticeable as time goes by.
--------------------------------
So instead of using wait blocks, consider using the timer. <timer>
The timer always counts the same rate. it's a number that goes up by the second. and it's the same in scratch as it is online...
Here's how you would do the above with the timer.
<reset timer> (this makes the timer block start at 0)
<play sound[ talking
<switch to costume[ closed mouth
<wait until> <( <timer> <>> 2 )>
<switch to costume[ open mouth
<wait until> <( <timer> <>> 2.5 )>
<switch to costume[ closed mouth
<wait until> <( <timer> <>> 7.5 )>
<switch to costume[ open mouth
<wait until> <( <timer> <>> 8 )>
<switch to costume[ closed mouth (this happens at 8 seconds into the audio)
This way, the actions will always happen exactly at the second you tell it to, no mater if you're online or off, or the computer is fast or slow.
So that's the solution, use the timer instead of wait blocks if you want to keep a ton of actions in sync.
(otherwise, I think the solution for the scratch team would be to make actions take no time at all: make the wait blocks compensate and treat actions between waits, as if they took no time at all.)
Last edited by JTxt (2010-06-17 23:49:03)
Offline
JTxt, I like your idea. I have also noticed that sometimes changing:
<when green flag clicked>
<wait( )secs>
to a <when I receive[
that it fixes up the timing slightly. It might be a coincidence though.
Last edited by markyiscool (2010-06-19 04:20:02)
Offline
Yes, timing has been a little off in the past. Unfortunately, we're just going to have to go with the flow for now
You can always keep your timing in check by using broadcasts, like Markyiscool mentioned, but it's still some work that you shouldn't have to put in. I support!
Also, another thing I'd like to see with relation to timing is atomic timing. Right now, there's something of a 0.01 second wait between blocks; I'd like the option to have that disabled.
Offline
JTxt wrote:
coolstuff wrote:
Yes, timing has been a little off in the past. Unfortunately, we're just going to have to go with the flow for now
Or follow my suggestion above, and use the timer.
Which would be a bit of a detour, which is sort of going with the flow, instead of just normal timing
Offline
coolstuff wrote:
Which would be a bit of a detour, which is sort of going with the flow, instead of just normal timing
How is using the timer block a detour? It's not quite as obvious as using the wait blocks, but it's a valid solution to the problem.
The "wait so many seconds" blocks just do that, wait,
but the actions between them take time... those actions take more or less time online or off... and on faster or slower computers... so they get out of sync after a while.
(If actions took no time, with wait for blocks would stay in sync forever, but they don't.)
The timer is increasing at the same speed, on everybody's computer.
By using the timer block to wait until a certain second, you're always going to be in sync.
It is how I made the beats on my guitar hero clone, stay in sync with the music. that would not have worked well with the wait for blocks.
(I also used this method on my midi to scratch project.)
I can make a simpler example if there is interest.
Last edited by JTxt (2010-06-19 17:50:03)
Offline