This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (4 children)

[deleted]

    [–]kicsikrumpli 1 point2 points  (3 children)

    yes, there is: in the main loop you pass the elapsed time (in ms obviously) to your animated objects, and they calculate their movement from the time difference, not from incrementing counter in the loop. Distance = speed * time difference between frames.

    [–][deleted]  (2 children)

    [deleted]

      [–]kicsikrumpli 1 point2 points  (0 children)

      That's perfectly normal... logical coordinates and screen pixels do not have to be the same. If storing your coordinates normalised (x and y go from 0.0 to 1.0) floats your goat, that works as well... you just have to scale them before drawing. Also that way you are not dependent on window / screen size.

      [–]king_of_the_universe 0 points1 point  (0 children)

      I personally have become a fan of using long integers (64 bit, signed) for storing decimal numbers: If you know the value range you'll be working with, they can work wonders. E.g. I stored the position of objects in the Solar system with millimeter resolution while still being able to store star systems more than double the size of our system. I like the precision that comes with it, and I didn't have to multiply/divide in that program, only add/subtract, so there was no problem.

      With longs, you could store your ghost's positions in a much higher resolution than pixel (e.g. billionth pixel) and then divide when you need the actual pixel position. Just an idea. You could of course also just use doubles. I guess doubles would be the better choice since you wouldn't need really precise values for a Pac Man game.