Low speed logic (e.g. 10-20fps) could certainly make a fast moving bullet pass through a wall if you are just using tweening for the graphics, so you'd need some special path tracing code to resolve that. Also low speed logic could result in a feeling of input lag I guess (I've heard this mentioned before by people like Mike Boeh Source: http://www.indiegamer.com/archives/t-738.html ) although I've never tested it myself. Dmaz has it right which is why I like a fast logic rate.
Somewhere along the line, as Gabriel points out, I got confused that you may end up drawing something inside another object by tweening an object between it's current position and it's projected position instead of between it's last position and current position. This was because I assumed the lag was undesirable and to be avoided and when I read the fix your time step article source: http://gafferongames.wordpress.com/game-physics/fix-your-timestep/ , I interpreted it as suggesting that, but it doesn't do that. Although it's probably possible to do. Basically you know that say half a logic iteration (physics step) has accumulated but you are not processing it yet, however you could decide to render it by tweening between the current position and the projected position based on objects' dx and dy and other changing states. Probably not worth it though just to remove the lag.
Probably render tweening is easy but it would require a big rethink for me because I'm so used to doing my tweening equivalent using fractional delta values as part of my logic iterations. It's pretty easy, stuff like x:+Speed*Delta or Counter:+Delta or ParticleAlpha:-AlphaSpeed*Delta etc. In fact can someone show me how you'd do the same via tweening please?
Also I read someone post about how if say you made a ball go off one side of the screen and enter on the other that the tweening may show it at an incorrect position until the next frame is reached. The explanation made sense to me and I was thinking it could apply to all things where you reverse an object's state somehow. Like say you made something change direction, so that in logic iteration 1 it's heading right and after logic iteration 2 it's heading left (imagine something bouncing off something). If your render tweening doesn't know about the change, just the two different positions, it'll render halfway between the two positions instead of taking into account the whole path including the change and rendering at the appropriate point on that path. For example:
object starts at x=0 in logic iteration 1 and bounces off a wall at x=100 and is at x=50 in logic iteration 2 but the render tweening state is at 50%, it'll tween halway between 0 and 50 = 25 instead of realising that the whole path is actually 150 pixel long and rendering at x=75 instead.
Hope that makes sense. Same thing for reversing alphas, and what about things following a special curved path? If the logic is too slow then the render tweening would render the object on a straight line between two points instead of at its true curved position. Or am I totally wrong here and you have special render code for each object that doesn't pick a straight line to interpolate between two coords but takes into account all other factors so it can accurately interpolate. But then surely it would be repeating part of the logic code? (or maybe the logic doesn't even work out the x and y it just moves a counter on and the rendering works out the position, but then how would you handle collisions?)
As you can see I'm pretty confused about this so if anyone is experienced with it, please post some examples, explanations. Thanks! :-)
Somewhere along the line, as Gabriel points out, I got confused that you may end up drawing something inside another object by tweening an object between it's current position and it's projected position instead of between it's last position and current position. This was because I assumed the lag was undesirable and to be avoided and when I read the fix your time step article source: http://gafferongames.wordpress.com/game-physics/fix-your-timestep/ , I interpreted it as suggesting that, but it doesn't do that. Although it's probably possible to do. Basically you know that say half a logic iteration (physics step) has accumulated but you are not processing it yet, however you could decide to render it by tweening between the current position and the projected position based on objects' dx and dy and other changing states. Probably not worth it though just to remove the lag.
Probably render tweening is easy but it would require a big rethink for me because I'm so used to doing my tweening equivalent using fractional delta values as part of my logic iterations. It's pretty easy, stuff like x:+Speed*Delta or Counter:+Delta or ParticleAlpha:-AlphaSpeed*Delta etc. In fact can someone show me how you'd do the same via tweening please?
Also I read someone post about how if say you made a ball go off one side of the screen and enter on the other that the tweening may show it at an incorrect position until the next frame is reached. The explanation made sense to me and I was thinking it could apply to all things where you reverse an object's state somehow. Like say you made something change direction, so that in logic iteration 1 it's heading right and after logic iteration 2 it's heading left (imagine something bouncing off something). If your render tweening doesn't know about the change, just the two different positions, it'll render halfway between the two positions instead of taking into account the whole path including the change and rendering at the appropriate point on that path. For example:
object starts at x=0 in logic iteration 1 and bounces off a wall at x=100 and is at x=50 in logic iteration 2 but the render tweening state is at 50%, it'll tween halway between 0 and 50 = 25 instead of realising that the whole path is actually 150 pixel long and rendering at x=75 instead.
Hope that makes sense. Same thing for reversing alphas, and what about things following a special curved path? If the logic is too slow then the render tweening would render the object on a straight line between two points instead of at its true curved position. Or am I totally wrong here and you have special render code for each object that doesn't pick a straight line to interpolate between two coords but takes into account all other factors so it can accurately interpolate. But then surely it would be repeating part of the logic code? (or maybe the logic doesn't even work out the x and y it just moves a counter on and the rendering works out the position, but then how would you handle collisions?)
As you can see I'm pretty confused about this so if anyone is experienced with it, please post some examples, explanations. Thanks! :-)