I like to work in units of (current_refresh_rate)/common_refresh_rate so that if the user happened to get that refresh rate then dt would usually be 1 for each frame.

This way if you choose speeds for some of you game elements of dt * 1 or dt * 2 etc then for some users those game elements will be moving in whole pixels per frame which is as smooth as you can hope for.

(ed: assuming that you are vsync locked)
(ed2: changed 1 to (common_refresh_rate) duh!)

so if a thousand bullets move aagainsta target at 1000pixels per second and the logic rate is at 100 they will move 10 pixels per loop? something tells me i'll meet this kind of problem often(and i'll have to write alot of code to fix it, i can think of a few situations that i could fix thought), so i don't want to try it out :S.. but i can think of some situations where using deltatime is the right thing to do. How do you get over by like this?

I don't really understand the other posts..

Now that i think about it.. i use delta time for my logic loops
This is how i do it:
i store the time between frames and then use the value to run the "logic loop"*"delay between the frames" , and a separate logic loop that runs only one time per frame.

Approved?

There's a great possibility that they would phase through an oponent causing no harm - considering you would check only if they're inside him.

Hehe .. well, i think it's necessary for bullets to be able to acheave such speeds, it's about feeling.. i don't like when you have this awesome machinegun and a million aliens moving thowards you, and you bullets move in slowmotion(with a booring sound effect)... it should be like BAM BAM BAM just spitting out a shit load of bullets at a really high speed slaughtering everything. . also, i like small targets :/(i like targets of all sizes too - -)..

yeah. and to me, that's a very big problem.

4 pixel is to much . 2 pixels is to much.. bullets should be able to hit bullets - -. i'm fine with one pixel right now... but i might change my mind and go with 1/4 pixels. hehe, it would be approximately 1.56 screen widths per second... i guess thats enought .

I had nothing to do this lunch break so i thought i'd make this picture. It explains why having a bullet move speed of 1000 px is a bad idea. Best to have big heavy alien smashing bullets travelling at 5 px per update than a stealth bullet thats too quick for its own good. Enjoy!

{"name":"591251","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68.jpg","w":846,"h":745,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68"}

But that's what is delta time about. Since you can't be sure that the time between frames is the same, you aply delta time. You just meassure the time between two frames and multiply by it all movement done between theese two. Just like in real world.

ad c) like checking whether there's something in the path of the bullet, or if there's possibily, that something will get in there considering the velocities.

Again, having a 1px bullet moving at 1000px/s is just pointless. No one will be able to see that. If you want "realistic" (read fast) bullets, just check for collisions along the trajectory rather than against an actual projectile. There's no way this can get screwed up.

FuriousOrange, I really like your sketch! do you have more of them?

Well at first you must know if something collides. Ussually as a side effect you know what and where it collided. For instace, if you check those two vectors from my previous example whether they collide and the output will be yes, there will be also somewhere information where did they collided - it's in the nature of vector intersection checking.

So if you know that the the vector a and b collides, you'll be also provided with [x][y][z] coordinates. Which is exactly what you're seeking for.

OICW: It's a bit harder than that. For checking 2 moving objects against each other, you need to take their radii into account. The formula goes something like this:

dist(dt) = hypot(x1 - x2 + (v1x - v2x) * dt, y1 - y2 + (v1y - v2y) * dt) - (r1+r2);

and you have to solve the equation for dt where dist == 0; this will give you 0, 1 or 2 solutions. If there are no solutions, there is no collision. If there is one, then the objects hit each other only tangentially, and you can probably consider it a non-collision as well. If there are 2 solutions, then you need to use the smallest non-negative solution. If the solution is larger than your desired maximum dt, then you can ignore it. If both solutions are negative, there is not collision.

If more than 2 objects are involved, you need to check each object pair, and start with the first collision you detect. Forward the simulation to that point, handle the collision, and run all checks against these two objects again. Keep doing this until dt has reached its desired maximum for that frame.

I haven't read all of the replies since but it sounds like there is confusion between the stated 1000 pixel moves per second and pixel moves per update. 4 @ 250hz = 1000 per sec

Still in delta-time,
Collision is not the only issue, you have to take the whole logic speed/frequency into account:
For exemple, if you have an auto-cannon shooting 1 bullet every 500ms, starting at t0:
If're processing t1 = t0 + 620 ms, you have to spawn one bullet and immediately apply 620ms worth of movement to it, then spawn another and give it only 120ms worth of movement.

If you don't, it will be VERY visible that the shooting frequency is affected by system load : the distance between the projectiles will not be constant.
Somebody knows one open-source game that successfully addresses theses issues ?
I can imagine one system, but it's multi-pass algorithm.. horrible performance hit, at the worst possible moment (when you need to catch up)