Advertisement

Keeping up the precision

Started by February 19, 2001 02:30 PM
7 comments, last by d73bmh 23 years, 11 months ago
Hi, I have been developing a nice networked sports game for which the requirements stated a true physics model. So I decided to implement the system in partial 3D i.e. the physics layer in 3D and the presentation layer in isometric. However by representing player positions using floats I am introducing rounding error when plotting. This causes the players to shake slightly when the camera scrolls accross the playing area. Is there anyway I could improve this without resorting to moving the camera/sprites around in screen space? Cheers. John. Edited by - d73bmh on February 19, 2001 3:37:22 PM
it's all a matter of perseverance
Replace all floats with doubles. If this doesn''t help then u might have a conversion problem somewhere.
Advertisement
The actual unit positions of the sprites is in the order of 1000s so the precision of the position is not really the problem, it''s the rounding caused by transformation of the 3D float position into 2D integer screen co-ords that is causing the shaking. I could just ensure that the positions of each of the sprites lies on a resolved integer boundary, but this seems to be really ugly to implement. The only other way would be to only use integer co-ords for the sprites and operate on them in screen space, however all my physics routines would have a fit!
it's all a matter of perseverance
Hmmm sorry man maybe your problem is that the center of a square,pix is in the mid:

X-----X <--Have u positioned your sprites here
|--X--|
|--X--| <--Or here?
|--X--|
X-----X

There shouldn't be any rounding problems from 3D to 2D if the math fits. If this doesn't help you, then sorry man.

Edited by - Jonus on February 19, 2001 5:52:20 PM
for a second I thought that was it but the sprites are positioned at the top left. I have noticed that the problem is really the shaking between sprites, which might be due to the camera also having a floating point position. If I was to transform that first and then offset all the sprites in screen space that might fix it? I dunno, any ideas?
it's all a matter of perseverance
One issue that can develop is that float to int is not true rounding.
i.e.

1.6f = 1, but should be 2

1.2f = 1

to get true rounding, add 0.5f to the float before conversion.

Maybe this will help?





mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com
mat williamsLead Programmer, DesignerZero Sum Softwarewww.zero-sum.com
Advertisement
It seems that true rounding just changes the boundary at which the players jump on screen. When doing 3D there must be a similar positioning problem between objects (within an object the vertices will all accumulate the same error, so end up sticking closely together), how do they fix that? All the stuff I have seen relates to scanline rendering of polygons which doesn''t really count with bitmaps. hmmm..
it's all a matter of perseverance
quote:
Original post by d73bmh
how do they fix that? All the stuff I have seen relates to scanline rendering of polygons which doesn''t really count with
bitmaps. hmmm..


When you are not scrolling does this *wobbling* still occur?

Are your sprites positions using fractions?

I think the problem ,just a guess, is that you are using mixing two coordinate systems. I tend to hold all positions in integers
calculate the floating point stuff then demote it back to
the integer space. But it should not matter either way as long
as you are consistent.

If all your objects,including the map, go through the same
transformation math then they will all have the same error
accumulation and you should not see any wobbling.





I actually managed to fix it over the weekend, it was pretty simple. The wobble was caused by the camera transformation being done in world space, I just moved this to screen space and voila!

Cheers,
it's all a matter of perseverance

This topic is closed to new replies.

Advertisement