Animation Speed

For questions about using Classic.

Post » Tue Aug 19, 2008 3:53 pm

[quote="Jeswen":iqmyc4nx][quote="Ashley":iqmyc4nx]We're talking a difference of maybe 10 pixels here. Do you really have areas you can't jump to if you fall 10 pixels short? Or areas you can reach if you jump another 10 pixels high? Really?[/quote:iqmyc4nx]

This is the only thing that caught my attention. What if someone is making a retro game, low resolution and all, I think every pixel is important.[/quote:iqmyc4nx]

True. I wasn't thinking of retro games, I was thinking of the kind of game I (want to) make, hi-resolution displays and detailed graphics and all. I can see this is a problem for retro games (sorry I didn't check out IWBTG sooner to arrive to this conclusion :P) so it becomes a problem for this special case. Still, I'm sure the error would be smaller for decent framerates, and retro-games are usually so low resolution you'd never have any drop in framerate. And the error would be further less assuming small, pixelly games would generally have things moving at lower speeds.

Running the display and logic asynchronously isn't the right solution for games which fiddle on the pixel level, but I can think of something similar. There could be a mode where the display is V-synced, but the runtime returns a constant value for TimeDelta. For example, if TimeDelta always returns 0.01 regardless of the real value, the built in behaviors and any custom timedelta-based movements would be absolutely exact and work the same way every time.

Then you have a high-quality display which is exact, but it will still run at different speeds depending on the refresh rate of your monitor. I still don't like that, it makes me think of the DOS games on the old 486 computers decades ago, which ran depending on the speed of your processor. Buy a new CPU and the whole game speeds up... some computer manufacturers even put a "slow" mode on their cases to stop games running ridiculously fast :P

Digressions aside, I could (somewhat reluctantly) do the same thing for fixed framerate so the display tears and it plays out the same way every time, and would only ever slow down if the processor couldn't keep up, which is unlikely for retro-style games. I guess this would also silence people who want the physics to play out the same way every time too!

So I'm proposing a kind of 'Override TimeDelta' option. I think this would solve everything that's been brought up. And if you have a change of heart, you could then easily switch your game to using real TimeDelta values ;)

Sound good?
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,528

Post » Tue Aug 19, 2008 6:00 pm

That sounds excellent, but some more things to consider. I think the reason I'm getting bigger numbers when it comes to test is because, unlike say, using constant 15 fps, my 15 fps environment is 'real'(as in the computer is set to not be able to catch up)In situations around 15-30 FPS, frame rate is very unstable, causing, I think, further innaccuracies are caused through this, such as the big '32' pixel leap with that one test.

So what I would recommend is a way to get the real time delta, even in this mode, and further a way to SET the artificial time delta. so in this situation I could 'update' the artificial time delta to match the display to get proper speeds and, even if it does cause some differences, these differences will be consistent and more predictable/testable. Heck, I could even have it 'forbid' certain exact time delta values that would allow a timer to overrun for one tick. I could even have it update periodically in 'safe' situations, such as when the player grounded. I could even give the players an option on how slow down effects them (instead of doing two builds, IWBTG style).

I like this solution a lot. While it's not as precise still in that different delta times may act slightly differently (which I can potentially solve!) it gives a lot of useability options I like and a lot more control over how frame loss is handled (if you like my idea of course). I think you'll like it too, though, as it gets rid of the factor of variable speeds.

Thank you Ashely, I'm glad this thread reached a comprise that is in everyone's benefit.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Wed Aug 20, 2008 12:33 am

[quote="Ashley":2adhhw11]There could be a mode where the display is V-synced, but the runtime returns a constant value for TimeDelta. For example, if TimeDelta always returns 0.01 regardless of the real value, the built in behaviors and any custom timedelta-based movements would be absolutely exact and work the same way every time.[/quote:2adhhw11]

Actually that makes some good sense. I'd been planning a platform game with movement similar to Flashback or Prince of Persia. Since this debate over pixel precision started, I was getting a little worried about how my engine might behave, as the movement of the player sprite is largely dependent on what animation frame is playing.

For instance, to jump and pull yourself up on a ledge, you have to be pixel-perfectly lined up with it underneath. In the original games this isn't too much of a problem because the tile width and the length of the player's walking animation are designed to complement each other, so you won't ever have to make tiny little taps to get lined up just right. The player sprite just naturally stops on the exact spot where they need to jump.

With Timedelta as it is now, and these arguments suggesting that the movement could cause the player sprite to be off by as much as ten pixels would make for a bit of a headache in workarounds. (Even though PoP is designed to line you up automatically, it's not 100% perfect. Sometimes he does get off-line with the edge of the tile and "teleports" slightly to the left or right when you jump. It looks a little funny.) Doable, to be sure, but if your fixed Timedelta solution works the way I think you're describing it, then that should make things a bit easier.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Wed Aug 20, 2008 8:34 pm

Well, there's a lot of theoretical talk here. I put it to the test with a little .cap file that moves a sprite at 100 pixels per second for 1 second using TimeDelta, and measures the maximum and minimum distance it travels in that period.

I struggle to get it to have an error (difference between max and min) of more than 2 pixels. It's usually at most 1.5 pixels. Maybe these fears it could be off by 10 pixels are overblown?

Also, it performs surprisingly well at low framerates. Even if you fix the framerate at two frames per second, it still lands with nearly perfect accuracy every time.

I guess I should implement the timedelta override for its various uses, but I really think people's worries about timedelta are still exaggerated. It is remarkably accurate from what I can see. And where pixel precision matters - low res games with generally slower moving objects - it still seems accurate to within pixels. You can also get around any inaccuracy with various tweening methods, such as using a while loop to move the player until they are exactly in the right place, eliminating any error at all. I would still prefer to code it this way for uniform speed of execution, even if it's more events.

Don't worry - I'll still implement the timedelta override. But I don't think many people will ever need to use it!
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,528

Post » Wed Aug 20, 2008 10:29 pm

If I set it to +200 instead of +100, it misses by 4 pixels instead of 2, and then goes back to 1-2 pixels at +300.

One run of +400 missed by 7 pixels.
B
2
S
2
G
5
Posts: 391
Reputation: 2,432

Post » Wed Aug 20, 2008 10:36 pm

My point was, though, isn't it unlikely that the games and movements where this kind of accuracy matters would use speeds as high as 400? That's a high speed for a platform movement, for example.

Maybe someone with experience making pixel games could shed some light on this for me.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,528

Post » Wed Aug 20, 2008 10:42 pm

I work with mobile phones but not on games, so I won't comment on that. One thing I can think of that could use over 100 is bullets or something.
B
2
S
2
G
5
Posts: 391
Reputation: 2,432

Post » Wed Aug 20, 2008 11:35 pm

Okay, as I suspected, real FPS loss is a factor here. In for example, when running a game around 20-30 FPS, it's not unusual for there to be large, quick dips in the FPS. When running the game at 1-5 FPS, there can be skips as large as 30 pixels.

When setting to fixed rate 30, the frame rate isn't likely to drop like this, since you probably have more than enough power to maintain a consistent frame rate. But in the real world, dips like this can cause huge discrepancies.

So with a 'fixed' delta time, this isn't an issue and you can set a the frame rate and set minimal speeds and ignore sudden dips.

As for high speed objects, I doubt that'll be a problem, as long as the frame rate/delta time stays consistence.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Thu Aug 21, 2008 12:57 am

In the example file I posted previously I can't reproduce any increasing inaccuracy with low framerates. As I mentioned in the post, even at 2 FPS it usually lands within a pixel of its target.

Going back to my point about pixel precision of fast moving objects as Jeswen mentioned - I don't think it matters that much if a bullet is a few pixels out. You'd never be able to spot the difference. I understand it's a problem if you need pixel perfect platform movements, but I was suggesting that platform movements would tend to be at low speeds, so still having a high accuracy.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,528

Post » Thu Aug 21, 2008 2:21 am

I tested it on 4 computers and 2 fixed frames. Two out a range of 100, the other two were more reluctent to make large jumps and put out about 50 eventually. 2 laptops, and 2 desktops. So it seems to vary between systems to an extent but most will probably be capable of producing these anomolies when struck with low FPS.

Granted with the time delta override this is all a moot point.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Previous

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 5 guests