How to Increase tick Accuracy

Lets assume the game runs V-synced with a graphics card that's refresching at a 60 F/sec rate.

Every tick wil then take place every 1/60 of a second. Wich is to slow for accurate collission detection. A normal CPU is able to run like 1000 ticks every frame refresch. Or that would be every 1/60.0000 of a second.

I could use an in-tick loop to improve the accuracy. In the download there is a Cap that makes an attempt to do this.

I know that the basics are there. But its not working as i expect it would work.

Would someone be so nice to direct me to a better way to accomplish this.

Thx.

I'm not sure exactly what it's supposed to do, but I can tell you that checking for collisions 10000 times per frame isn't necessary since your sprites aren't moving anywhere in those loops.

I think for most things 60 FPS is good enough for collision detection, but if you really need more than that I made an example a while ago that provides a method for highly accurate collision checks.

Accurate High Speed Collision Checks

Keep in mind that you have to make your own event based movement engines for this to work properly. While writing this post I thought of some ideas where you could apply this to the built in behaviors, so I'll see if I can work something out there.

The file is not online. But, based on the comments poeple that gave you, i think your example was pixel-driven. When pixel driven you always have 100% control, and indeed objects do not move if you dont move them. Behaviours do move objects in the huge time between the end of a tick and a frame refresh.

Yeah, sorry about that. Here's an updated link:

Accurate High Speed Collision Checks

I also changed the link in the uploads forum in case anybody stumbles upon that again.

Also, I just thought of a way to turn the ideas I had concerning this into a behavior. We'll see what comes of that.

checking for collisions 10000 times per frame isn't necessary

You are also using a loop. Your loop is checking max 156 times / frame (by 60 fr a sec).

With a TimeDelta of 16 miliseconds you check in that timeframe (TimeDelta is the time between 2 ticks) a full 7 miliseconds for collission. Meaning, there are still 9 miliseconds left without any collision checking. And that is to much for any bouncing events.

Here is a Cap (test2) illustrating how your solution fails.

Also. There is no break into your loop. Your solution will restrict the frames/second to 142. Faster is impossible because the refresh rate will wait for completion of your tick. Your tick will exceed the TimeDelta.

Further, that is not a collission dedection. You check for overlaps. In pixel based games de moving object will be randomly 1 pixel off. Especialy on the left side. Your objects will go stuck.

Ty 4 the help though.

Maybe I just don't understand what you're trying to get at. Do you want there to be multiple ticks per frame? What exactly is so inaccurate about 60 ticks per second unless you have incredibly fast moving objects?

Maybe I just don't understand what you're trying to get at. Do you want there to be multiple ticks per frame?

That would implie that i drop V-synced. And that is a no-no-situation.

[quote:1vwdpoaf]What exactly is so inaccurate about 60 ticks per second unless you have incredibly fast moving objects?

I would say: try it yourself. A few behavior based bouncing balls and try to catch EVERY collission. Its not the speed of the balls thats the problem. Its the event of the collission thats very short. When i give u a tick on the shoulder, its not the speed of my arm that needs dedection. Its the very small time frame in wich i touch you that needs dedection. A bounce happens in 1/400 of a second.

Look at this:

I run it at 60 frames/second. I can optimize the dedection loops with my Cpu and Graphics card. Now build it so it auto-adjust for other CPU's and faster graphic cards.

Is the CPU faster, it can handle a bigger loop.

Is the Graphics card faster, it dont have to handle a bigger loop.

okay.

so what is it that you wish to accomplish?

TheInstance, I just reduced your whole event sheet down to two simple "On collision" events and it behaves in exactly the same way as your .cap... so I don't know what all those crazy variables and loops are for.

http://dl.dropbox.com/u/529356/noloops.zip

v0.99.82

You say that the speed of the object is not an issue, but the collision itself... well, okay then. Collisions work fine. I've never had a problem detecting a collision. So I guess I don't know what it is you're on about.

Perhaps you could explain in plainer detail exactly what it is you are trying to accomplish here?

For perfect collision checks, check for collisions every time the object is moved. If you check more often then that (which is what you're trying to do) you'll check in the exact same position multiple times, and it won't make any difference.

I guess the issues he's having is you can only check for collision once a tick and the behavior is still moving between that time, so you never get 100% perfect calculations that way. I guess he needs 100% accuracy for some reason. I would suggest using event sheet movement, but I'm assuming the reason is the pixel offset randomly? I did not know that - not that there would be any chance of my none CPU-like brain to notice such a thing at runtime. But could explain some wierdness I may or may not have experienced in the past with overlapping but strugged off.