I think what you are missing is that the sub-pixel movement is usually coupled with time-independent movement as well.
For instance, instead of saying "object moves 4 pixels per frame", you say "object moves 240.0 pixels per second". If you unharness the framerate and just let it run as fast as possible, the movement will move as much as needed.
Example: lets say Object moves 100 pixels per second (pps). If your (uncapped) frame rate is currently 38fps, that's 26.3 milliseconds per frame (1000ms/38fps). Then your object does the calculation:
- we moved a time increment of 26 ms.
- i'm moving at 100pps (or 0.1 pixel per millisecond)
- 26ms * 0.1ppms = 2.6 pixels traveled this frame.
Now the next frame might be a different speed because of any number of computer factors. The equation will be the same and the result a little different every frame. If you are getting really rocking FPS, your movements will be in tiny little baby steps (mabey less than one pixel even, for slow objects). If your FPS is really crappy and you are playing on a 486, your objects will leap across the screen from frame to frame! However, even though the frame rate stinks, the object is always going the same speed. It never gets that "Nintendo NES slowdown" effect when there is too much action.
2D Sprite Movement
Author
Quote:Original post by OrangyTang
4 pixels per second won't be choppy unless your actual framerate is low. If you're running at 60fps then it'll look smooth as silk.
However you really *don't* want to use time based movement for a 2d game. While its great for 3d it tends to look terrible in 2d where minor glitches and hiccups can cause the movement to look irregular.
Actually my current implementation is with frame based movement. But anyway, what is the general consensus on that. Should 2D sprite movement be done in respect to frames or real time? At first I was using the real time approach, but then I realized that if my computer encountered some processing problems, I wouldn't want the rest of my game moving slow, while my sprite is rocketing across the screen unaffected. Of course the sprite would be just as slow to be rendered as anything else in the game, but if it was running dependant on time, its coordinates would change quickly and the sprite's position would change faster than the rest of the stuf on the screen.
So is the answer that everything in my code should be either frame or time dependant, but don't mix? I either answered my own question or confused myself even more... Haha... would anyone like to tell me which one it is?
Quote:So is the answer that everything in my code should be either frame or time dependant, but don't mix?
Exactly. Experiment with both to see which one you prefer and gives the better results.
Quote:Original post by OrangyTang
However you really *don't* want to use time based movement for a 2d game. While its great for 3d it tends to look terrible in 2d where minor glitches and hiccups can cause the movement to look irregular.
I understand what he's saying there, but i disagree to a point. The flexability that time-indepenedent movement gives you is worth it.
Quote:So is the answer that everything in my code should be either frame or time dependant, but don't mix? I either answered my own question or confused myself even more... Haha... would anyone like to tell me which one it is?
Don't mix them. Have everything go one way or they other, and out of my personal preference, go the way of time-independence :-) If you try to mix them, you'll get some real weird things, but mostly it will just be frustrating to callibrate and coordinate objects all moving willy-nilly at whatever pace they like.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
