For Beginners: Loops & V-sync

The first day i was playing with construct.

I expected a loop like this:

To work.

This to demonstrate how dumb i was as beginner.

But,

i can imagine more beginners have a hard time to pass on this.

And i probably still get some eyes that cant believe what they see (or more dont see) happen in this .cap

it should work, right ?

In event 3there is a loop from 1 to 10.

It displays its counter in a text box. 10 - the loop counter should show a counter gooing from 9 to zero.

There is a inner loop in event 4 counting from 1 to 999.

So for every step in the first loop, there is also the inner loop counting to 999. Displaying its counter in another text box. Its counts 10 times to 999, or it should.

This last loop should work as a "slow downer", so we should be able to see count the first loop on screen !!

Well it does not work ?

Well the good news is. It does work !. We just can not see it.

Conclusion: we can not use loops to move/change things on screen. Well thats true in most cases, but that conclusion is not 100% correct.

In this topic i will try to explain what exactly happens. So you as beginner can get along with loops.

One warning though: i will not be 100% correct. That would take a big book.

So i will simplify things. I must understand it myself, and the goal is to explain it to beginners.

So plz, you hard core constructors, dont be on my butt ! ty : )

There is more then 1 actor involved in this story.

And by now, people that followed me trough the other tutorials, know that i can not explain without naming things.

So let me introduce you to "The Big Brother Loop"

Download this, and fire it up.

It has only 1 objects.

And 1 event, moving the object by its own X + 1

Run it, and watch the object keep moving by 1 pixel to the right, each tick.

But ? we moved it only 1 pixel ? in 1 event ?

Well construct runs top down. And then starts over again at the top.

Meaning: there is a Loop already. This is the loop that keeps construct running and running.

There is not one moment in making a game that you can forget/ not take in account this loop.

So to set it in the spotlights that it deserves, i have to give it a big bombastic name. To make you see the importance.

I call it: (deep commercial voice) The Big Brother Loop !!!

The entity representing The Big Brother Loop to execute all events just once:

we call a "Tick"

Now do not imagine The Big Brother loop as a wild running animal that runs as fast as it can trough the events from top to down, to start this process as fast as it can over and over again.

The Big Brother loop is very patient. Well it has to !.

Because it is caged by the V-sync. The second actor in this story.

V-Sync = Vertical Sync

A CRT monitor draws the screen one line at a time, from top to bottom.

When it reaches the bottom, it pauses for a moment, while the electron gun is pointed up to the top again.

If you have v-sync enabled, then that is the only time at which a new frame may be presented to the monitor. Then the monitor gets the whole frame, and can render it in peace, knowing that the GPU won't give it a new frame until it's done.

With it disabled, the GPU can literally overwrite the frame data while the monitor is drawing it. So you can easily end up with the top half of the screen showing a different (older) frame than the bottom half. That can lead to tearing, and v-sync avoids that.

Of course, v-sync forces the GPU to stop and wait, so it limits your framerate. (It never gets higher than the screen's refresh rate, and if it dips below, then it has to skip a screen refresh, and wait for the next one before it can get to present the frame it's working on. Then you get a framerate of half the screen's refresh rate. And if that's not enough, then a quarter.)

The actual feature still makes sense on LCD's, but the name is derived from how CRT monitors work.

I stole that description from "the Net".

Its well explained, not 100% correct, because its messing up a bit between the places monitor and gpu take in this story.

But it will do.

Yet, lets simplify some.

First lets say V-sync stands for Video sync.

Lets forget which one exactly limits the amount of images/second we can show.

De monitor that needs time to build the image by image.

And/or the Gpu who needs time to render the image that will be presented on the monitor.

Also image by image.

Lets also forget that due those limitations in the amount of images that we can present / second,

we do something completely weird,

namely: we are displaying a continue movement (a movement by behavior by example) trough a non continue device !

Just accept that, depending on your total hardware & devices, we can only show a certain images, also called frames, /second.

OK now.

Lets say an average computer will be able to display 80 frames / second.

Or 80FPS.

But The Big Brother Loop is able to run like 2000 Ticks / second, also depending on the speed of your hardware.

Thats more then 200 times faster !!

If we give The Big Brother Loop the freedom to run uncaged, it will possible encounter 2 problems.

1/

On beam based monitors (not LCD's), it will happen that the events are in a different Tick on different places on the screen.

Since it will pass the beam in speed several times, on top of the screen we will be in tick1, in the middle we will be in tick 2, on bottom we will be in tick 3.

This will show as flicker. As horizontal moving objects to move in 2 pieces. As 1001 artifacts. As vertical moving objects to be twice on the screen.

2/

It will choke the GPU. Since it offers the GPU new material while the GPU is still rendering the last image. The GPU will not accept, and will do this in a kinda random way. Because some images take more time to render then others. Result: shaky movements.

The only solution we have with todays devices is to CAGE The Big Brother Loop so it will be exactly as fast as the Frame Rate for your computer.

We know when every device in the computer is ready to accept a new image/frame when those devices generate a Vertical Sync. A vertical sync is no more then a electric pulse identified by its form so we can read it as " The pulse that says this is the end of 1 image".

There are other electric pulses that say "this is the end of a line". They have a different form. That between the lines.

So, in reality ...

The Big Brother Loop completes 1 Tick, then waits patiently till it gets a V-pulse. When the V-pulse happens, it starts over at the top of events to complete its 2dn Tick. At the end of the 2nd Tick, it will wait again for the next V-pulse.

This process of waiting to get in step (in sync) with the displaying device we call V-Sync.

And you can forget all i said, if you see it as Video-Sync.

As The Big Brother Loop waiting for the Video to display a complete frame.

THIS MEANS ALSO THAT THE SCREEN GETS REFRESHED EVERY TICK. BUT NEVER IN THE MIDDLE OF A TICK.

Now back to where i started.

The loop. First allow me to illustrate The Big Brother Loop waiting on a V-Pulse.

Download this, and fire it up.

1 object. 3 events.

Event nr 2 moves the object 10 to the right.

Event nr 3 moves the object also 10 to the right.

Event nr 4 moves the object 20 to the left.

If you run this. The object is not moving at all. Thats because the Big Brother loop waits at the end of every tick for the video to complete a frame.

And the video will not be updated in the middle of 1 tick.

The 2 events moving the object to the right happen inside 1 tick. Since the video will refresh only After a complete Tick.

We only see the result of a complete tick !!!

Remember, and accept this. Dont be a Rebel by trowing the V-sync in the application properties to "unlimited". That is asking for big display artifacts.

And the loop ? Well the same thing is happening here.

The loop happens INSIDE 1 tick. WE WILL ONLY SEE THE RESULT OF A LOOP CONSTRUCTION. because, the video dont get refreshed at the rate the loop is running.

The video gets refreshed only once every Tick. And the loop completely happens inside 1 Tick.

So now ? How do we make objects move by loop constructions in a way that we actual see the objects move ? Well make use of The Big Brother loop. Since this Loop is already V-synced by design.

This ...

is the correct way to do what we wanted to do with the loop at start of this topic.

This time using The Big Brother loop !!!

Now what j0h ?

Are you saying that loops are useless ?

No sir !!!

Loops have there place in constructing. I would not want to miss them.

Here is an example of good use of a loop.

There is not a more simple way to create those instances of an object, then using a nice Loop.

You might think:

All this V-sync mummble and mamble is not influencing my .caps.

You might think again.

Allow me to show you something, starting out with this .cap.

Orginal it comes from this topic:

You can download it from both places. Fire it up and watch.

It will give a error about a sound not found, just click "ok" and it will run fine.

When i ran this .cap for the first time. I noticed the Ball is bouncing a little weird. And in a closer look, you can see that the ball is intruding the blocks and paddle with a few pixels. Also, sometimes the ball is jumping out the layout in closed areas, mostly in corners.

So i dived in the .cap. And i saw that patryk is using his own bouncing mechanism. And an event to bring the ball back in the layout when it escapes.

So asked him (assuming he's male): Why you do that for ?

And he answered me: If i dont do it this way, the sounds are not working.

And i slammed my own forehead, leaving a M mark. My question was rather dumb.

His solution to the problem is in fact elegant. Solution ? Ah yes, he worked around a problem.

Allow me to step back on his steps, and reproduce the problem.

download this.

unzip, and fire it up. Leaving the folder structure intact.

I modified his .cap this way.

1/ i made all the objects that are supposed to collide with the ball "Solid" in the groups/attributes properties. I deleted all actions/events from the .cap used to bounce the ball. Now all bounces are made due the build in bounce of the ball behavior.

2/ i added 2 sounds, since i dont have his original sound.

Run all, and notice that the events do not pick up any collision detection.

Not the collision detection to destroy the blocks.

Not the collision detections that should trigger the direct sound into playing a sound.

This is what he worked around.

But.

What is happening here ?

On my laptop it only runs 60 ticks / second. It runs all the events in 1/900 of a second, and in the remaining time its waiting for a V-sync.

Imagine the following situation.

You are babysitting 2 kids. You sit in the couch. And both kids sit at the other side of the table. Playing monopoly. You are supposed to monitor the kids behavior. Meaning. When one hits another (collides) you are supposed to yell "STOP IT" and punish the kid who started.

Now lets limit your eyes.

Imagine there is only one light bulb in the room. And its kinda working bad. Meaning: it burns 1 second to not work for the next 5 seconds. Light 1 second, dark for 5 seconds.

Thats is close to what happens with The Big brother Loop. While waiting for the V-pulse to happen, its blind to what happens in the events. BUT, the behaviors keep running and running, unattended.

Just like the kids behavior. After all they are kids, they tempt to fight. But, when they start fighting in a moment that the light is out, you have not seen it, you missed one hitting the other, you missed a collision.

To prove this,

download this .cap .. and fire it up

It is exactly the same .cap Only, in the application properties i disabled the V-sync.

Do NOT Be Attempted To Do this For Your Games. It brings Other Bigger Problems.

I dont know exactly what happens now. I do know that The Big Brother Loop now runs more times a second. But there is still some kind of V-sync, else i would have 10 balls on my screen, considering the speed this ball moves.

But yes i do know that it runs at more ticks / second. And at my computer now like 2/3 th of the collision detections actual get detected. That can be more or less on your computer, depending on the speed of your gpu and screen.

And i think i proved the connection between v-sync and the amount of ticks/second, and the connection between ticks/second and the cap working as expected or not working as expected.

So keep this in mind, its important.

Very Personal Conclusion on all this:

The "on bounce" condition is (i think) only recently added. patryk used it to solve this problem.

And after all, its probably the right solution today.

Although the "on bounce" condition is meant to over come the limitations with a ball behavior that only will bounce on solids.

Now you can choose witch object its bouncing from. And you can have 2 balls in the layout, each bouncing from different objects. Witch is very nice.

Do not understand me wrong, its a very useful condition.

But after all it is not solving the general problem.

Maybe, we need 2 Big Brother Loops. To solve this completely.

?

1 thats V-synced, and acting as it does now.

another 1 thats NOT v-synced, and keeps running trough the events to set flags for collision detections and triggers.

This will also make triggers finally really work as triggers.

Now i just hope that there is anyone understanding what i mean. Or anyone willing to ask questions and this way triggers me to explain till it is totally understandable, or accept that i am wrong.

Hi,

this sounds interesting, but none of the .cap files mentioned here are available ... so it kind of makes it hard to follow this tut.