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.