What am I trying to achieve?:
I want to create launching effect. There will be two polygons, I want to keep one of them at stable position(0,0) and make other polygon come from the left side of the screen and stop at alongside of constant polygon. Then make stable polygon move towards right side of the screen to demonstrate launching effect.
What did I try to make it work?:
I put both stable and moving polygon in same routine and created a loop.Made position of moving polygon conditioned.It starts from (-1,0) and ends at (0,0). Position changes by 0.01 at every repeat. Duration of moving polygon is 0.03 therefore it looks like moving when ı did not add stable polygon in the routine.
What specifically went wrong when I tried that?:
When ı add stable polygon in routine it changes the end time of the loop…Since constant and moving polygons are in the same routine, routine and loop does not end untill stop time(3seconds) of stable polygon ends. Problem is, moving polygons moves at every 3 seconds and it looks like jumping rather then moving. Do you have any idea how ı can demonstrate launching effect?
You need to remember that your screen refreshes at a fixed rate (e.g. 60 Hz, or every 16.666 ms), so you can’t expect to use arbitrary small durations like 30 ms in a loop and hope to keep any semblance of accurate timing. A better approach is to drop the loop technique and instead provide a formula based on time to calculate the position of the stimulus on any given screen refresh. e.g. Builder maintains a variable called t which is the time in seconds in the current routine. I think you want to move one target from the left side of the screen to the centre in 3 seconds, so you could give it a duration of three seconds and put this in the position field, set to update on every screen refresh:
[-1.0 + (t/3.0), 0]
Then you could duplicate that stimulus, and set it to have an onset of 3.0 seconds and a constant position of [0, 0], to give the effect of it moving and then stopping. Do a similar thing for the other stimulus (i.e. have one be static for the first three seconds of the routine, and then another begin moving right wards at 3 seconds, with a three second duration).
Hi @Michael or anyone else reading. Any ideas how could you adjust this formula but to have the object move from the centre of the screen to the bottom of the screen?
I have used this formula to make an object move from the bottom of the screen to the centre of the screen over 300ms like so:
[0, -1 + (t/0.3)]
I’d like to now achieve the reverse by having an object (image component) move from the centre of the screen to the bottom of the screen. I’ve tried various changes to the formula that do not which makes me think I don’t understand the right bit to edit to achieve this.
Thank you for this. Unfortunately, when using this formula the image does not display (but doesn’t throw an error).
As you can see in the example attached with a couple of example images - I’m attaching the most basic version of the task. Object1_up goes up to the middle of the screen over 300ms. Object1 then stays on the screen for 1 sec (by using a second image component). A Object2 then appears for 1 sec and then Object2_down is meant to go down from the middle of the screen to the bottom over 300ms. All the first 3 stages work but not the final stage.
I even tried using the original formula of [0, -1 + (t/0.3)] to see if I could get it to at least display going up and it doesn’t. I’m not sure why the image doesn’t display as there isn’t any error.
Okay after playing around with it a bit, it does seem to work if the formula is adjusted so that the position is time divided by a larger value (e.g., [0, (t/-6)]). Whilst this does successfully show object2 lowering down at the end of the trial, I need the speed at which the objects rise and lower to be the same. I’m not sure why dividing time by 0.3 doesn’t work.
Interestingly, if I place this component early on in the trial, it displays as intended. So why might having this component late on in the trial stop it from displaying correctly or why does dividing time by a larger number help? Is this possibly a processing issue?
Ahh, well that is why - my suggestion assumed that the motion was starting at t == 0 s, as implied by your existing equation. If you need the movement to start at a later time, then you need to take that starting offset into account.
e.g. if you want the motion to begin at, say 2.0 seconds, then something like this:
[0, (t - 2.0)/-0.3]
Then at 2.0 seconds, the y position will be 0, and will shift to -1.0 over the next 0.3 seconds.
This is assuming you have the stimulus set to only appear at 2.0 seconds - otherwise it would be seen moving on the screen before it gets to position 0.
