Closed GoogleCodeExporter closed 9 years ago
double is used because of sprite velocity is based on time, for example:
elapsedTime = time taken since last update
position += velocity x elapsedTime;
Velocity can be 0.05 for slow speed, and thus need double for slow increment.
Original comment by pau...@yahoo.com
on 6 Apr 2008 at 7:01
I apologize that my last post was unclear. My wording did not match my
intention.
Please allow me to clarify.
I'm not suggesting changing double for velocity. It *is* needed for that (even
if
you can't move 2/3 of a pixel, the next iteration needs to have 1 and 1/3, or
1,
pixel movement). For instance, it should still be allowed to move half a pixel
per
x seconds (which translates, in reality, to 1 pixel every 2x seconds).
Velocity is
pixels/time, and some velocities do play nice with that respect (such as 0.5,
and
0.25, etc).
But sprite positioning needs to be based on integers for true collision
handling.
Otherwise you can and will get errors because of double storage. You also
cannot
render a sprite (or even a string of text via GameFont, which DOES use ints)
with
doubles...you must use ints. Which means Sprites keep bigger values than they
need,
and must constantly downcast them anyways (the same goes for collision
handling, as
again, you cannot occupy a fraction of a pixel, you are either there or you are
not).
The logic of using doubles for velocity is sound. You will get minor errors
over
time, but they should not be too great (and in fact there may be some point
where a
user discovers that they need greater precision, and a delta would then be
added to
velocity calculations, or BigDecimal can be used instead). But for
"pixel-perfect"
collisions, double is impossible to accurately describe "pixel-perfect".
Doubles
take more space and cause more errors and don't make sense for graphic
positioning,
as graphics are really just a big index-based matrix anyways.
So, basically, I propose altering positioning functions such as moveTo(x, y)
and
getX(), getOldX(), etc. to ints. Those dealing with velocity should still take
doubles for speed, but integers for position values.
Original comment by MetroidF...@gmail.com
on 6 Apr 2008 at 8:39
But if you take integers for position values there is no possibility to save the
precise movement updates as described above. This:
position += velocity x elapsedTime;
Will not work is position is saved as integers. Because if velocity and elapsed
time
together give a value smaller then one and position is integer the sprite will
not
move at all. As you see there values have to be of floating point type.
I'm not sure if a float would be enough on this point anyway, but that doesn't
changes the problems you described.
Original comment by jan.brac...@googlemail.com
on 8 Apr 2008 at 5:13
[deleted comment]
Crud...unless the number of times the velocity has been accounted for is
stored,
you're right. Guess this should be rejected. Still, though, being able to
"move a
sprite one-half pixel" doesn't make any sense. I wonder if there is a way to
resolve this, somehow save double values internally but only allow access via
integers?
Original comment by MetroidF...@gmail.com
on 21 Apr 2008 at 12:32
But the double is not very accurated, like the 3,00000001.
The BigDecimal is not primitive data type, and I don't know is it efficient or
not,
perhaps using delta like you said is better, but how to implement it nicely,
that
need to be think.
Original comment by pau...@gmail.com
on 21 Apr 2008 at 2:48
> Still, though, being able to "move a sprite one-half pixel" doesn't make any
sense.
> I wonder if there is a way to resolve this, somehow save double values
internally
> but only allow access via integers?
Oh it makes sence, if you want to create smooth, precise and accurate movement
you
have to save carry, otherwise the unit won't move at all (The moved distance
per move
is smaller then 1) or it will be faster/slower then it really is in some places.
> But the double is not very accurated, like the 3,00000001.
Well i don't see the problem at that point.
> The BigDecimal is not primitive data type, and I don't know is it efficient
or not,
> perhaps using delta like you said is better, but how to implement it nicely,
that
> need to be think.
Ohh, that way more inefficient. When using one sprite you probably won't nitice
but
when when using a large number it will slow down.
Anyway why not just cast the double/float position when needed?
(int)sprite.x // Ultra precise :P
sprite.x // Ultra correct :D
Original comment by jan.brac...@googlemail.com
on 21 Apr 2008 at 5:16
Original issue reported on code.google.com by
MetroidF...@gmail.com
on 6 Apr 2008 at 5:34