Quote:Original post by icecubeflower
You only had half of your last post written when I wrote that last response.

Yeah sorry, I have an edit-addiction.

Quote:Original post by icecubeflower
When I say cycle I'm not talking about the main loop. I meant every time this evaluated to true:

if(SDL_GetTicks()-primo.elticko>=1)
{
primo.elticko=SDL_GetTicks();
//then update everything
}

Sorry if my lingo is wrong. My "cycle" would be totally independent of framerate if I had a number bigger than 1 in that if statement. Maybe that will turn off an alarm bell.

That may be evaluated to true at different timings, sometimes it might be true after X seconds pass by, sometimes it might not be true until after X*2 seconds have passed, etc...

The alarm bells don't go off until you're using this variable timing information to perform the update. See the last edits ;)

[EDIT] (sorry :P)

Quote:Original post by icecubeflower
In my game I liked being able to run across the screen in 1 second and have it scroll real smooth. I don't see how I can do that with 60fps. It looks like my only options are to have choppy graphics or slow my guy down. :( Please tell me I'm missing the point.

SNES Zelda was rendered at 50hz, so of course it's possible.
To make it smooth, you want to be able to move things at a resolution higher than a pixel - that is, you want to be able to move things by increments smaller than one pixel.
If you're moving at 1px per 1ms (or 1000px/cycle @ 1000hz), that's equivalent to 16.666px/cycle @ 60hz. To get the animation smooth you need to be able to allow for that extra 0.666 pixel!

You can't do that while measuring distance in (integer-based) pixels and speed in pixels/cycle or pixels/second, etc...

Quote:Original post by icecubeflower
I don't really see what's wrong with pixels per cycle.

1) 'cycles' are variable in length - they aren't always going to be the same length of actual real life time, causing choppy animations.
2) 'pixels' are inherently integer-based. Meaning that if you really should move a character 16.6 pixels, you will be forced to either move them 16 or 17 pixels, again causing choppy animations.

Quote:My way it never goes faster if you run it on a super fast machine, the speed is capped. If your frame rate and stuff gets really slow then the whole game slows down and all the characters move like sloths.

With units/second it never goes faster or slower.
Pix/cycle does go in slow-motion if you run it on a slow machine though (as you've discovered on Windows - the graphics driver is artificially slowing down your program).

Quote:Your way everything always moves the same distance per second no matter what.

That's a good thing! Using units/second you get consistent movement no matter what speed the machine runs it at.

Quote:But everything will look choppy if I keep moving may character at a speed of one screen per second.

Why? Because you're forcing movement to be measured in whole pixels (not fractional pixels)?

You're missing the point. Perceived choppiness comes from having inconsistent movements, not large movements.

E.g. Take, Call of Duty 4. It renders at 30hz on my computer, If I rotate my player's camera at 90º per second, it may cause a building off in the distance to pan across the screen at 1000 pixels per second (which is 33 pixels per frame), but it still looks smooth.

Quote:Original post by icecubeflower
That means my guy moves 17.06 pixels between frames. That means the map moves 17.06 pixels between frames. That means it's still choppy. Right?

No, why is that choppy?

Under your current system, lets say your guy moves 1px every 1ms. However, the LCD only refreshes at 60hz. That means that by the time the LCD decides to refresh, your guy will have moved about 17 pixels, but it doesn't look choppy. Right?

[EDIT] sorry there were some typos.

Let me back up a bit.
Forget about units per second for a minute, lets go back to pixels per cycle.

We want our guy to go at 1000px per second. So if a cycle is 1ms, that's 1px per cycle.

On a 60Hz LCD he will move ~17px per frame.

Now, lets change a cycle to 0.01ms. If we want the same speed, that's 0.01px per cycle.
Or, lets change a cycle to 16.66ms. If we want the same speed, that's 16.66px per cycle.
Now this is the problem! Speed has become fractional!

Pixels are measured in whole numbers (integers), but to get the movement correct (not choppy) with a cycle-time of 100ms, we need to be able to move our guy by a fraction of a pixel.

If 16.66ms have passed, but we only move the guy 16 pixels, then things will start to look choppy when all of those missing 0.66's start to add up.

So to fix this, we invent a new term "units", which are exactly the same as pixels, but instead of using integers to store them we use floats.

Now everything works and you can stick with pixels per cycle, but we'll call it units per cycle instead and measure it with floating point numbers.
You'll also have to convert all of your position variables from pixels (int) to units (float), and whenever you want to draw anything you'll have to convert it back to an integer.

[EDIT]
Earlier I said you had 2 problems, one was 'pixels' and one was 'cycles'.
The above only fixes the 'pixels' problem.

Quote:Maybe sometimes it's 1/113th of a second, sometimes 1/107th of a second. Is that right? So when my motion is more than ten pixels per turn and set at exactly a certain number of pixels it will look choppy unless the frames are draw at exact intervals... which they aren't.

Yes this fixes your other problem - your measure of 'cycles' isn't necessarily accurate! If you could detect that this cycle is 13ms longer than you expected and sped up the game to compensate it would fix the perceived choppiness. This is what the delta_time multiplier is for.