#22128 - LOst? - Sun Jun 13, 2004 7:48 pm
This is illegal:
float fU;
fU %= 1.0f
And using AND is impossible >.<
How do I wrap a float value between 0.0 and 1.0 depending on what the value was from the beginning?
#22131 - tepples - Sun Jun 13, 2004 8:31 pm
First of all, consider learning fixed-point math very soon.
Second, look up frac().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22134 - LOst? - Sun Jun 13, 2004 8:35 pm
| tepples wrote: |
First of all, consider learning fixed-point math very soon.
Second, look up frac(). |
What is frac() ?
I can't find any info on it...
#22135 - tepples - Sun Jun 13, 2004 8:38 pm
oops, my bad. It was part of a library I use. Try x - floor(x).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22137 - LOst? - Sun Jun 13, 2004 8:42 pm
| tepples wrote: |
| oops, my bad. It was part of a library I use. Try x - floor(x). |
Yea thanks!!!! That helped!
#22138 - f(DarkAngel) - Sun Jun 13, 2004 8:48 pm
You can also use fU-(int)fu (compiler should convert 2nd value to float, explictly, it should be (float)(int)fu), which should be faster than floor() version.
_________________
death scream...
#22139 - LOst? - Sun Jun 13, 2004 8:56 pm
| f(DarkAngel) wrote: |
| You can also use fU-(int)fu (compiler should convert 2nd value to float, explictly, it should be (float)(int)fu), which should be faster than floor() version. |
Yea, but floor is better since it is designed to do floor. INT will convert it, and that's maybe not working on different systems (with different float sizes)?
#22145 - tepples - Sun Jun 13, 2004 9:26 pm
Casting to int will also depend on the rounding mode you have set.
Is this for a PC-side tool?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22146 - poslundc - Sun Jun 13, 2004 9:27 pm
| LOst? wrote: |
| Yea, but floor is better since it is designed to do floor. |
That's a naive way of looking at it...
| Quote: |
| INT will convert it, and that's maybe not working on different systems (with different float sizes)? |
IEEE floats are all 32 bits, all using the same representation.
Truthfully I don't know whether the floor() algorithm is faster than a float->int->float conversion when done purely in software, as would be the case on the GBA. On FPU-based hardware I expect the typecasting technique (notwithstanding any rounding mode, which isn't something I've had to deal with) would be faster since it involves two primitive instructions to the FPU.
Dan.
#22147 - LOst? - Sun Jun 13, 2004 9:33 pm
| poslundc wrote: |
| LOst? wrote: | | Yea, but floor is better since it is designed to do floor. |
That's a naive way of looking at it...
| Quote: | | INT will convert it, and that's maybe not working on different systems (with different float sizes)? |
IEEE floats are all 32 bits, all using the same representation.
Truthfully I don't know whether the floor() algorithm is faster than a float->int->float conversion when done purely in software, as would be the case on the GBA. On FPU-based hardware I expect the typecasting technique (notwithstanding any rounding mode, which isn't something I've had to deal with) would be faster since it involves two primitive instructions to the FPU.
Dan. |
So you say that casting to INT is better than using floor?
#22152 - poslundc - Sun Jun 13, 2004 10:22 pm
| LOst? wrote: |
| So you say that casting to INT is better than using floor? |
On a machine that has an FPU? I'd expect it to be at least the same speed or faster, depending on the implementation of floor().
On the GBA? Harder to say. Either way will be bad, and you shouldn't be using floats on the GBA to begin with.
Dan.
#22159 - FPChris - Mon Jun 14, 2004 12:30 am
I'm new to the GBA. I known fixed math and why floats would be
bad on the GBA.
However, do you guys use floats on the GBA to build your fixed lookups
or do you build your tables externally then bring them in?
What would be the harm of useing floats on the GBA if they are not in 'gametime' code areas only in intializations etc.?
#22165 - sgeos - Mon Jun 14, 2004 1:35 am
| FPChris wrote: |
| However, do you guys use floats on the GBA to build your fixed lookups or do you build your tables externally then bring them in? |
Generally one uses a PC side tool to calcute all the need floats. It then spits out a list of corresponding fixed point versions of those numbers.
| Quote: |
| What would be the harm of useing floats on the GBA if they are not in 'gametime' code areas only in intializations etc.? |
Longer initialization time. If your tables are large, you will be trading execution time to get some extra space on the cart. I'm not sure, but I suspect that a calculating a single value will result in longer initialization and *less* space on the cart.
If one uses a float, does that import a whole bunch of code to handle floats in software?
-Brendan
#22167 - poslundc - Mon Jun 14, 2004 2:05 am
| FPChris wrote: |
However, do you guys use floats on the GBA to build your fixed lookups
or do you build your tables externally then bring them in? |
I concur with sgeos: I build all of my tables natively on my development machine and then load the tables directly into my program.
| Quote: |
| What would be the harm of useing floats on the GBA if they are not in 'gametime' code areas only in intializations etc.? |
Probably no great harm would come of it. But there is an awful lot of extra work the compiler does to afford you the convenience of floating-point numbers, so it may make your program much larger (speed isn't the only thing to optimize) and it makes your code higher-level and more abstracted from what is actually generated by the compiler, which is generally something to be wary of when you are working on an embedded system such as the GBA.
I am normally the first to discourage premature optimization, but it's important to realize that fixed-point math isn't an optimization in the conventional sense. I see fixed-point math as being more of a programming reality or necessity for the GBA. Once you've mastered it - which isn't very difficult to do - it is even easier than using floating-point math, and it makes it simpler for you to write and debug code. I know I can estimate the value of a 32-bit fixed-point number much easier than I can an IEEE float.
Dan.
#22171 - FPChris - Mon Jun 14, 2004 3:04 am
Sounds good. I probably use float during development then
import tables once I'm happy with the code and I settle in a bit more.
Thanks for the advice.
#29277 - Jau - Mon Nov 15, 2004 9:24 pm
Where can I learn fixed-point math?
#29278 - poslundc - Mon Nov 15, 2004 9:44 pm
#29675 - _pluto9 - Tue Nov 23, 2004 7:17 pm
Your trying to isolate the decimal portion right?, well you might want to learn all that IEEE stuff, but I'd just do this (PRECISION being some power of ten, 10 meaning 1 decimal place, 100 meaning 2, etc..):
| Code: |
| f = float(int(f * PRECISION.0f) % PRECISION) / PRECISION.0f; |
unless your using it for some low level graphics routine or something... then yeah, learn the IEEE stuff