[quote="Arcticus":2qc1rykr]I don't know if this is any help, but if i'm ever in the situation where i need a little more accuracy in my movement engines, i make a little 'for' loop
Make a global varible called like, 'MovementAccuracy'
change the sampling to linear
And then at the start of layout (or change initial value) set it to the amount of accuracy you want
I usually set it to around 50, the higher it is, the more accurate you will get, although i'm not sure the cpu load it would have if you made it too high
Then do something like this
when right arrow is down
--for "Move" from 0 to global('MovementAccuracy')
== Set Player.X to Player.X + 200 * (timedelta / global('MovementAccuracy')
(the -- indicates a subevent)
(the == indicates an action)
Basically, the 'logic' runs 50 times per tick (or however many you set your global to) as opposed to once per tick, but you still get to use timedelta and use all your cool motion blur and timescaling stuff!
Apply that to your jumping code or moving code or whatever and it's pretty much pixel perfect
I had an example running at 1 fps that only went one pixel out
Or another method i suppose would be having variables like: "JumpStart" and "JumpMaxHeight" and make it so when the player jumps, the jumpstart records the Y value at 'ground level' and set jumpmaxheight to the jumpstart minus however high you want him to jump.
Then if the difference between the player's Y and jumpstart goes beyond jumpmaxheight, manually set the distance and code in the falling. Although i suppose this method would be a little harder if you weren't using a custom movement, and for REALLY low frame rates it might still require the use of that 'For' loop i just mentioned
I hope i made myself clear[/quote:2qc1rykr]
This... actually seems like a potentially good idea. Granted what you said is not far off from how my engine already works, but it makes me think of things a little differently. The implementation I'm now thinking would be say.. use time delta to figure out how many times to run accuracy essential logic and run it X amount of times. I used to figure this wasn't reasonably possible, but if I'm looping the essential logic say 5-10 times normally, adding or subtracting a few reps should keep things in speed.
The problem for me though is still keeping animation properly in since (which operates with delta-time in mind). It's essential for me that animations line up exactly when they should. Any way to get around this would either involve... making my own animation engine from scratch or........ Bugging Ashley to implement a feature only I'll ever use (Something like telling an animation to advance a 'tick frame' instead of a whole frame of animation). Which is a waste of time. Alas. But for our opening poster, maybe this would work!
Nothing professional here and I'm sure a lot of stuff you already know. Still, it talks about the whole logic vs update thing I talk about. So at least my thoughts are somewhere on base and not some unique fabrication. Again for professional examples, I think they'll be hard to find simply because, well.. Again, theres not a lot of professional level 2d computer games these days. Though as I read around, I see a lot of this stuff mentioned, though nothing solid enough to further waste your time with.
I also saw some stuff mentioned somewhere about netplay like I said earlier about FPSs and how relying on delta time for a networked game could be a bit weird. I don't know how accurate that statement is, it's just what I read from some random internet person.
Edit: Actually now that I think of it, adding a feature like the one I'd need wouldn't be that hard I don't think and might be more generally useful. Just a command like "Random Object: Advance Animation X ticks". all the user would have to do to do what I want is set animation speed to 0 for whatever objects they want to control. Not saying you should do this, but I think it might be a valid option. I'm just brain storm thought.
Also: I'm curious how collision detection works. If I were to manually run logic several times a frame, would collisions work properly on the 'inbetween' updates, or do collisions only take into account the final or previous displayed state?