Quote:Original post by EasilyConfused
So this decouple the physics from the render rate doesn't work so good. You get a really annoying jitter.

So I give up.

Aaah! No! Don't give up! [sad]

I can empathize with your pain, trust me. I dealt with timing/framerate issues like these through a huge part of Skirmish Online's development, which was sheer anguish. However, it was the act of not giving up that eventually led me to solve the issue.

I stay stick to it, and keep on trying things until it works. You'll thank yourself in the end when you have a solid framerate-independant solution on which to base all future projects on. [smile]

I appreciate the sentiment, but I don't know how else to approach it.

Problem is as follows:

Independant frame-rate physics - no feasible way to ensure that the character will jump to the same height regardless of frame rate

Fixed rate physics and independant rendering - annoying jitter every other second

Fixed rate physics and rendering - less jittery but will not cope with undersampling

The only option is to go back to option one, but try to find a system that will ensure that you get a fixed jump height and horizontal distance, but I'm all out of ideas in this respect.

Surely to god you can write a 2D platformer on a modern PC without having all these problems? How did you handle it for Skirmish in the end? Any ideas would be appreciated at the moment.

[EDIT]

Okay. You're right. I can't just give up on this.

So, what are the issues in a Mario style game that actually require pixel precise movement?

The maximum height of a jump and the maximum horizontal distance covered by a jump.

I think that's it. I think if I could think of a way to get that right, I could go back to physics and rendering independant of frame rate and have a really solid solution I could be really comfortable with.

It's a thinker.

[EDIT]

So it looks like I've found a solution with the help of the forums and that physics Gaffer guy.

Fixed rate physics and variable rate rendering, but with a twist.

Store the old position OP, and compute the new position, NP, based on the fixed physics delta.

Then, pass the remainder of the accumulator into the render function and do:

float Alpha=AccumulatorRemainder/PhysicsDelta;

TempP=NP*Alpha+OP*(1.0f-Alpha);

DrawAt(TempP);

Apparently this "alpha-blends" between the old and new position based on a weighted average weighted by the remainder of time in the accumulator.

Don't pretend to understand a word of all that but it does appear to work. My bouncing block is now moving a lot more smoothly.

So I just need to find a way to wrap all that up in a way that will scale well up to loads of objects. I guess I just need to have a "previous" position stored in each object as well as its current position (easy enough) and a function to do the above math on the objects two position members before each object is rendered (again, fairly straightforward).

Then I just need to come up with a grand theory of unification to reconcile quantum physics with gravity, and I should be ready to write Super Mario.

Those Nintendo guys are cleverer than I thought.

I'm sure that what you're doing is close (I think?) to what I used for Skirmish (and virtually all subsequent games :P), but here's the gist:



So now you're updating at a fixed rate (like before), but any 'overtime' per frame is preserved, which should remove the jittering you describe (unless it's a product of something else).

Hopefully that was helpful!

Quote:Original post by HopeDagger
I'm sure that what you're doing is close (I think?) to what I used for Skirmish (and virtually all subsequent games :P), but here's the gist:

*** Source Snippet Removed ***

So now you're updating at a fixed rate (like before), but any 'overtime' per frame is preserved, which should remove the jittering you describe (unless it's a product of something else).

Hopefully that was helpful!

Cheers, but that looks like pretty much exactly what I was doing and that was what was causing the jitter.

See the edit above for my current solution. It is going to involve me installing a particle accelerator in my shed to help with the maths, and I think I'll need some kind of license to practice advanced physics in a residential area, but otherwise it seems to be moving forward.

That bubbling noise is my brain pouring out of my ears, by the way.

Thanks muchly for posting telling me not to give up. I'd be working on a fixed frame rate game now if you hadn't done that. As a result of your post, I've been back to the forums and had another look at the article and I think I'm finally struggling towards a solution.

Maybe I didn't fully understand your problem, but I never noticed this "lack of precision" and I always just store everything (position, velocity, time...) as floating-point values. I mean, the accumulated error there must be neglectable, how can it affect your game?

If you're doing a 2d game (particularly a platformer) you need to do both fixed rate logic and rendering. I did variable rate for ages but I tried fixed rate and it makes the scrolling *so* much smoother. Fixed rate logic and variable rendering is a reasonable compromise (especially if you're doing an online game where slowdown isn't really an option), but the scrolling still doesn't look as good. The brain is strangely good at picking up on slight variations in framerate, so a fluctuating framerate is actually worse than a slightly less frequent but fixed rate render.

If you're offline, then just fix the logic and framerate, and give the player some graphics options so they can hit your target framerate.

Old school Nintendo games look so spot on precicely because they're doing fixed rate logic and rendering.

Yeah, but you can't really fix the frame rate, can you? I mean, assuming you have vsync on (which you have to really and can't control anyway) and assuming that your 2D game will render a scene far faster than the interval between a vertical retrace, your frame rate is entirely fixed by your user's monitor refresh rate.

So if I lock my frame rate in the main loop to, say, 60fps, and the user has a refresh of 80fps, the rate you are drawing will be slightly out of synch with the monitor, so every few frames will stall while it waits for the next refresh. At least, that is what it appears to do as I've tried just locking the main loop and it is almost as jittery as fixed-physics-variable-rendering without the interpolation.

My current solution seems best for me, using the simple interpolation. I have a fixed physics time step which keeps the simulation stable and pixel-predictable, the rendering can run at whatever speed the native hardware wants it to and it looks smoother than any other technique I've tried.

The other problem, of course, with fixing a frame rate is that it does not deal well with undersampling. I agree with your comment that any machine should run a 2D platformer at at least 60fps, but you never know.

Quote:Original post by Jotaf
Maybe I didn't fully understand your problem, but I never noticed this "lack of precision" and I always just store everything (position, velocity, time...) as floating-point values. I mean, the accumulated error there must be neglectable, how can it affect your game?

Well, my game on the showcase just does all that and I agree you'd never notice.

However, I want to write a Mario style platformer now and I need the main character to jump the same number of pixels up and across as a maximum, regardless of the frame rate.

By using the normal Pos+=Velocity*TimeDelta style of equations in a truly frame-rate independant physics model (like my last game), I found that even just a variance of 10 fps could alter the maximum jump height by three or four pixels.

Clearly a Mario game is no good if your jump distance varies depending on the frame rate, hence my search for a better solution.

The way I handle the refresh is if fullscreen I switch the refresh to 60Hz, and lock to vsync. If windowed then I leave vsync alone and lock to 60fps using a vsync-esque sleep loop.

Quote:Original post by OrangyTang
The way I handle the refresh is if fullscreen I switch the refresh to 60Hz, and lock to vsync. If windowed then I leave vsync alone and lock to 60fps using a vsync-esque sleep loop.

Interesting. I didn't actually know you could alter the refresh rate of a monitor like that.

I guess it is safe to assume that any monitor will handle 60Hz. I just don't remember ever seeing a way to set the refresh through the DirectDraw or Direct3D set up API calls.

I'll have to have a look at the docs. I suppose it is no different to expecting the user to be able to support a minimum screen resolution really.