|
|
|
Junior Member
 
Group: Forum Members
Last Login: 11/18/2008 2:12:05 PM
Posts: 10,
Visits: 44
|
|
Can someone write a simple inline script that does the following
-Moves a text box(period "."(looks like a dot), 150 fonts, transparent background, White foreground) on a slide with a background image
-The starting position is is x = 320, y = 348
-The text box moves each time "4" on the keyboard is pressed to x = 80, y = 60
-If the "6" Key is pushed, the text box moves towards x = 560, y = 60
-If the opposing key is pressed in the middle of the trial, the text box will change its path to the new destination
-Once the Text Box reaches the final destination, the program goes to the thank you Text Screen
And please do not refer me to the sprite or animation canvas cause i have spent a lot of time playing with those and have gotten nowhere. Thank you greatly for your help...
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: Yesterday @ 1:49:23 PM
Posts: 288,
Visits: 738
|
|
kfevre (8/11/2008)
Can someone write a simple inline script that does the following
I am afraid that any solution that does this would not be "simple"  .
-Moves a text box(period "."(looks like a dot), 150 fonts, transparent background, White foreground) on a slide with a background image
I cannot give a full solution, but basically, I do things like this by putting a text box on a slide, put a "." in the text box (and maybe make the background transparent), then (here's the key), in the frame tab of the text sub-object's property page, enter attribute references for the Position X & Y properties (e.g., [BoxX], [BoxY]). Then I use the c.SetAttrib method in inline script to set BoxX and BoxY any way I like. If I do this in a loop (using Do...Loop, or as I prefer, using a List to construct the loop) with some small time for each iteration (perhaps set by the Duration property of the slide, although I have done this with slide duration of 0 and let the screen refresh rate do the work) and increment BoxX and BoxY appropriately each time then I can get a pretty good animation.
I know that description is fairly dense, and leaves your other questions unanswered, but that's all I have.
Regards,
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 10/9/2008 4:26:59 PM
Posts: 33,
Visits: 149
|
|
| On the topic of "letting the screen refresh rate do the work", Is there a way to be sure that the loop will run once per screen refresh? I am having a problem with this and I think that it is due to having too much code in the loop, so there is not enough time to execute it before the next screen refresh, and a frame gets skipped.
|
|
|
|
|
Forum MVP
Group: Administrators
Last Login: Yesterday @ 5:00:06 PM
Posts: 569,
Visits: 1,238
|
|
| You can determine how long your script routine is running by assinging to Long values to x = Clock.Read and then doing a delta/diff to verify the duration of the operation. To sync with the top of screen before drawing, use Display.WaitForVerticalBlank. Hope this helps and if you have a scriptlet to review, feel free to post it and sure someone will be happy to take a look.
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: Yesterday @ 1:49:23 PM
Posts: 288,
Visits: 738
|
|
RedTurtle (8/15/2008)
On the topic of "letting the screen refresh rate do the work", Is there a way to be sure that the loop will run once per screen refresh?
Here's what I did in one case: My loop had one slide object, let's call it LoopSlide (I used a List to run the loop, though you could use Do...Loop or whatever if you prefer). LoopSlide had a Duration of 0, no data logging, Cumulative timing mode, 0 PreRelease, and Onset Sync vertical blank. Inline script before LoopSlide made incremental changes to the slide each time through the loop. I also set the procedure's LogData property to No so that it spent less time logging to disk during the loop.
Now of course, a Duration of 0 does not really mean the object will not appear, since it cannot appear for less than one screen refresh. In fact, "Duration" is only a suggestion to E-Prime. By poking around with the code, I discovered that what Duration really does is to determine the TargetOffsetTime of the current object, and the TargetOnsetTime for the next object based on the TargetOnset time of the current object (at least in Cumulative timing mode, things work a little differently in Event mode) (see GetNextTargetOnsetTime and SetNextTargetOnsetTime in the online E-Basic Help for a few hints on this). So, with a Duration of 0, EP just displays the object (optionally after a vertical refresh), then immediately goes on to any following code, and when it gets back to the display object, since its TargetOnsetTime is some time in the past it just immediately displays again and repeats the loop. By contrast, if you enter any postive Duration, then some of the time in your critical display loop is spent just waiting for the object to reach its TargetOffsetTime and then its next TargetOnsetTime, which is just wasted time. (I do wish PST would document all these technical details somewhere for us experts!)
After all that, the first object after the loop (let's call it PostLoopSlide) would still see its TargetOnsetTime as the same as the TargetOnsetTime of all the objects in the loop. E.g., if PostLoopSlide had a Duration of 5000 ms, and the display loop took 1234 ms, then PostLoopSlide would actually last for 5000 - 1234 = 3766 ms, which in my case was the desired behavior. If that's not what you want, then you can correct things in script using SetNextTargetOnsetTime.
I am having a problem with this and I think that it is due to having too much code in the loop, so there is not enough time to execute it before the next screen refresh, and a frame gets skipped.
Well yes, if your loop code needs more than one refresh to finish, then you will miss a frame, nothing you can do about that except make the loop code faster, maybe using some of the tricks above.
-- David McFarlane, Professional Faultfinder
|
|
|
|
