Little Float Problem

[n2liquid]

Hello, I'm new here... just started programming my gp2x, but I've already ran in trouble

I'm coding a pacman game, just for fun, using EdgeLib. Everything okay, the engine is nice, stuff is compiling and running fine. But I got some problems with floats:

In order for me to know the grid-snapped coordinates of the player, I need to divide the actual pixel-perfect coordinate by 16, which is the grid size:

CODE
unsigned int x,y; // Current real coordinates
unsigned int sx,sy; // Snapped coordinates
[...]
sx = x/16;
sy = y/16;


Well,.. The problem is that this division is always rounded down("floor()'ed"), that is, Even though the division resulted in,.. say 3,98, the unsigned int variable got a value of 3, while if it was properly rounded, that would result in 4.
Anyway, when I declared sx as float, the result was the same: It was still getting floored. I wonder if this happens because of the lack of a FPU in a gp2x?

Thx!

 

[Blah]

I think all variables must be floats. (you could also try double or long)

 

[Parkydr]

Just do

sx = x / 16.0

to force floating point division

If you're trying to round to the nearest tile

sx = (x + 8) / 16;

is better as floating point is slow

 

[n2liquid]

Just do

sx = x / 16.0

to force floating point division

If you're trying to round to the nearest tile

sx = (x + 8) / 16;

is better as floating point is slow

well, I tried 'forcing' a floating point division, but it still didn't work. The other approach also failed...
Btw, I've done some pretty ugly hacks for it to work, and...it works! =) Still, it's ugly... Anyway, this was just a game for testing.. You know, I wanted something that I could code fast just to "see a game of mine running in a console". :rolleyes: I did some things for PS2, but they couldn't be called "games".

What I did was checking for collision only when the coordinates were perfectly snapped on the grid(checking wheter x%16 was 0). But now I'm out of battery, so I'm going sleep... I went all night long joking with this white F-200 thingy, and I think 'he' is also tired :lol:

Have a nice day, thanks for helping.

 

[gmiller1018]

Well if you are looking for x%16 then do (x & 15) which will give you x % 16 and x /16 is (x >> 4) since you are using unsigned values. Both of the bit operation do not use divide so they are MUCH faster than '%' or '/'. The ARM does not have a hardware divide instruction.

 

[fawny]

Add 0.5 before doing the division.

 

[sparr]

gcc already knows to replace A/(constant 2^B) with A>>B on processors with bad divide operations. ditto multiplication.

 

[A_SN]

gcc already knows to replace A/(constant 2^B) with A>>B on processors with bad divide operations. ditto multiplication.

Oh that's cool, I didn't know that!

 

[gmiller1018]

gcc already knows to replace A/(constant 2^B) with A>>B on processors with bad divide operations. ditto multiplication.

Oh that's cool, I didn't know that!

It will do that for unsigned operations with divide only for signed it will not. The signed divide it will always use the runtime divide code regardless. Shifting negative numbers does not give the correct answer since the answer tends towards negative infinity (-3 >> 1 ) = -2 and (3 >> 1) = 1. If you take the absolute value do the shift and then put the sign back you can use shift. The divide runtime loops subtracting till the remainder is less that the divisor.

Of course all of the floating point is done in software because there is no hardware floating point available.

Since you seem to want the divide rounded up to the next multiple of 16 you could do as was suggested (x + 8) >> 4 or if you want any thing that is not a multiple of 16 rounded up to the next (x + 15) >> 4