Pause vs Go to frame

Date:    Wed, 12 Jul 1995 19:55:39 +0000
From:    Peter Small <peter@GENPS.DEMON.CO.UK>
Subject: Pause or go the frame?

What exactly are the philosophical/practical reasons for choosing between:

Single frame with a pause in the exitFrame handler
Single frame with a go frame the frame in the exitFrame handler
Cycling between two identical frames (go frame the frame -1 in second frame exitHandler).

Is preference just a matter of mind set or are there any real practical differences?

In the paused state everything remains static on the screen unless you specifically instruct something to go, change or move.

In the other two cases everything disappears unless you specifically instruct something to stay , change or move.

Apart from the stepFrame message to the actorList, what advantages are there to using on enterFrame or on exitFrame, as opposed to an on idle?

I personally prefer a pause, but, so many people prefer the other options I think I must be missing something highly significant.

BTW, while on this subject what practical use is enterFrame? It seems to work as an extra exitFrame. If I put one beep in enterFrame and a pause and two beeps in exit frame, I get three beeps when I go to that frame. If I put the pause in the enterFrame I get one beep when I go to that frame and nothing at all when I leave the frame. None of this makes sense to me, not like the useful and intuitive openCard and closeCard of HyperCard.

Can anyone shed any light?

Thanks
Peter Small

Date:    Thu, 13 Jul 1995 10:50:30 +1000
From:    Grant Young <gyoung10@ALSVID.SCU.EDU.AU>
Subject: Re: Pause or go the frame?

Peter, the main difference that I know of between these different techniques is that pause stops everything, inc. video and sound (in certain instances). Also, any user interaction is halted (ie. mouseDowns aren't accepted). The 'go frame the frame' (or 'go the frame') keeps the playback head moving so that any events are caught, and sound and movies play.

As for the difference between the two latter methods, the only real advantage I can see is if you have specific handlers in each frame that need to be carried out.

Another technique that I use is to have two identical frames and loop in the second frame. I place any initialisation scripts (such as puppetSprites and resetMovieTime handlers) in the first frame, and then loop with the standard scripts (such as rollOvers, checkMovieTime, yourSpecificNeed) in the second. This way the movie isn't constantly setting puppetsprites and reseting the movie every time the playback head loops.

Although it is possible to scripts these initialisation handlers into a button script etc, I find that the frame method is easier to use when tracking down bugs.

This may sound confusing, but I haope it at least answers some of your questions.

The 'enterFrame' handler is usefule in initialisation scripts as the handler takes place as soon as you enter the frame, rahter than after moving through the first frame in the sequence.

You can also then use the 'exitFrame' handler to look after other things that are required before moving on.

Date:    Wed, 12 Jul 1995 17:21:34 -0800
From:    "k. camille nims" <camille@HEADBONE.COM>
Subject: Re: Pause or go the frame?

When you use "pause", you cannot have any looping sound playing. Pausing cuts off all sound. Also, you can't have any animation happening.

With "go to the frame", you can have both. If you use option #2 above, your animation must be programmatic. If you use option #3, you can animate using the score.

>BTW, while on this subject what practical use is enterFrame? ...
>None of this makes sense to me...

There are a lot of things that don't make sense in Director and this is one of them. I don't really understand how it works and haven't found anything helpful about enterFrame yet.

Date:    Thu, 13 Jul 1995 11:19:38 GMT
From:    "Glenn M. Picher" <gplists@IBM.NET>
Subject: Suspicious about "Pause or go the frame" answers

Grant Young wrote in response to Peter Small's philosophical question about how best to construct frames using Lingo:

>Peter, the main difference that I know of between these different
>techniques is that pause stops everything, inc. video and sound (in certain
>instances).  Also, any user interaction is halted (ie. mouseDowns aren't
>accepted). The 'go frame the frame' (or 'go the frame') keeps the playback
>head moving so that any events are caught, and sound and movies play.

I don't think any of the above is correct.

Pause stops the motion of the playback head. It does not prevent the proper delivery of mouse and keyboard events. In fact, pause usually depends on mouse and keyboard events being used to continue playback.

In fact, it is "go the frame" that can prevent proper delivery of mouse and keyboard events, if issued from an enterFrame handler. I think that Lingo can only exeucte one script at a time; enterFrame is the first thing that runs when going to a frame. If you go to the frame from enterFrame, there's no chance for *any* other handlers to run. User interaction events are only sent and received after enterFrame finishes, I think (during the idle time while the tempo channel's per-frame setting is being clocked out).

I play sound and video in paused frames all the time. Using an on idle or timeoutscript handler, I think you can give QuickTime more CPU cycles without burning cycles in Director from needless churning.

Also, "k. camille nims" posted similar information: >When you use "pause", you cannot have any looping sound playing. Pausing >cuts off all sound.

Perhaps imported (unlinked) sound cast members don't respond as expected when their cast info loop box is checked. However, doesn't the first time through still work without "pause" cutting the sound off? Also, you can loop sounds with repeat/sound playfile/soundbusy() logic.

>Also, (with pause) you can't have any animation happening.

Not true: on idle and timeoutscript handlers can create animation.

-  Glenn M. Picher   gpicher@ibm.net   gmpicher@pilot.njin.net
-  Roving multimedia programmer/artist; voice mail 502/745-0365
-  Replies go to gplists@ibm.net     Use gpicher@ibm.net for personal mail

Date:    Thu, 13 Jul 1995 11:19:07 GMT
From:    "Glenn M. Picher" <gplists@IBM.NET>
Subject: Re: Pause or go the frame?

>What exactly are the philosophical/practical reasons for choosing between:
>
>1) Single frame with a   pause   in the exitFrame handler
>2) Single frame with a     go frame the frame   in the exitFrame handler
>3) Cycling between two identical frames (go frame the frame -1 in second
>   frame exitHandler).

I usually prefer the pause. If you don't need to be constantly updating and redrawing sprites, why have the system churn? You can even put that kind of stuff in an on idle handler or timeoutscript handler. Especially on slow machines or movies with MIAWs...

There are certain exceptions. The "open" command doesn't actually seem to open an application until you go to a frame, apparently because the Mac toolbox only loads apps when Director tells the toolbox to WaitNextEvent()... which apparently only happens when going to a frame.

>BTW, while on this subject what practical use is enterFrame? It seems to
>work as an extra exitFrame. If I put one beep in enterFrame and a pause and
>two beeps in exit frame, I get three beeps when I go to that frame.

Pause is another one of those misleading Lingo commands that you would think takes effect right away, but in fact doesn't take effect until the current handler finishes. That's why you hear the 2nd and 3rd beeps immediately even when the pause is before the beeps in the exitFrame handler. Pause means "keep the playback head from moving any further when you're done with the current handler".

Incidentally, in the above case, if you had a very slow tempo, you'd hear a distinct silence between the 1st and 2nd beeps; enterFrame runs before any tempo waits and exitFrame runs after any tempo waits.

For this reason, I often use enterFrame to set up any lists or variables used by buttons on that frame; I can be sure it will execute before Lingo will let any buttons' scripts be executed. Not true if you put set up code in exitFrame; the tempo waits can be interrupted by button presses, so the setup code might not have run yet.

>If I
>put the pause in the enterFrame I get one beep when I go to that frame and
>nothing at all when I leave the frame.

As you pointed out, if you leave the frame with "go to the frame + 1", the exitFrame handler never executes.

However, I think your confusion comes about because you're testing out your concept in frame 1. For some totally unclear reason, frame 1 behaves uniquely. Continue doesn't continue in frame 1. Suppose this is your frame 1 script:

on enterFrame
  beep
  pause
end

on exitFrame
  beep
  beep
end

Also, you have a "continue" button in frame 1:

on mouseUp
  continue
end

Also, put some text into the message window and then stop in the next frame:

on enterframe
  put "I'm here"
  halt
end

Start the movie; you'll hear one beep. Press the continue button: nothing.

Move all of this one frame to the right: voila. You'll hear one beep; press continue, two beeps!

For this reason, the only thing I ever do in frame 1 is put up a background cast member, and maybe do some setup of variables, etc. Superstition seems to be the safest response to the unexplainable. :)

-  Glenn M. Picher   gpicher@ibm.net   gmpicher@pilot.njin.net
-  Roving multimedia programmer/artist; voice mail 502/745-0365
-  Replies go to gplists@ibm.net     Use gpicher@ibm.net for personal mail