GP2X Integer Based Maths

[icurafu]

I’ve had a bit of experience with 3D engines and game development, but to be honest I am more comfortable with floats when dealing with 3D.

I’m sure this is the same for the most of us. Look at modern day 3D and all of it is based on massive matrices packed full of floats.

So, if we want to make integers work, we need to collect and have a community understanding of how to code this way.

So I’d like to use this thread to collect a list of the following:
- 3D engines that use integer bases maths only.
- Tutorials that teach how to optimize float based games by using integer maths.
- Coding examples.
- Examples of games that use integer maths.

I’ll update this post, to include all links and pics. Then when we are finished I’ll try to summaries it all and put it in the wiki.

I'll appriciate any help. This is something I really want to learn. Until now, I've jsut been googleing for tutorials.

 

[skeezix]

I've got some simple #define macro based fixed-pointer conversions and operations libs around here that I wrote years ago; there are some good fixed point libs around.

Essentially its easy.. you can work in fixed-point integer math just like floats, but its less precise of course.. so sometimes oyu get 'holes' showing where things don't line up, unless you're very careful.

Quake 1 ports derived from Pocket Quake are mostly integermath converted, which should be prove amusing.

Anyway, look up fixed-point; its easy enoug to do.

ie:

Givne a 32bit int, you can shift an int into it; ie: Say 24bits of whole number, and 8bits for fraction; then just shift 8bitds over to make a intnumber into your fixed-point number.

Then for MULT, you just multiple the two fixed points, then downshift by 8 again. (ie: Rememer then multiplkying two values adds the mantissa, so it'd go to 8+8 shifted, so you then downshift to get back to 8 fixed point.)

So I use macros to turn int's into fixed-ints and back, and then macros to multi, add, divide etc.

Not too hard, and pretty fast.

But yes, we all miss having FPU's

jeff

 

[fragment]

Some useful macros:

http://members.aol.com/form1/fixed.htm

 

[icurafu]

Thanks, this is very interesting.

 

[fragment]

I also suggest reading 3DICA. Probably not the best tutorial around but contains all the basic info you need.

 

[BattleCattle]

OpenGL ES is the embeded systems version of OpenGL which uses fixed-point, as most embeded systems dont have FPUs. an OpenGL ES implementation might just be ported to the GP2X (once I can get this pesky schoolwork out of the way) which should give 3D games on the GP2X a big head start.

This already appears to include pretty much whatever you need as far as dealing with fixed point math, etc, so if you're planning on using OpenGL already, then you can just use OpenGL's built-in fixed point functions. This should help those who are unfamiliar with how to do the fixed point math to get started.


Now on to the coursework so that I can get on to the port so that I can give people a library so that its easier for them to create 3D games for the GP2X so that we can have a variety of cool 3D games on our shiny new systems.

 

[pea]

See the alegro game libraries for some nice fixed point math routines...

 

[sand_man]

OpenGL ES is the embeded systems version of OpenGL which uses fixed-point, as most embeded systems dont have FPUs. an OpenGL ES implementation might just be ported to the GP2X (once I can get this pesky schoolwork out of the way) which should give 3D games on the GP2X a big head start.

This already appears to include pretty much whatever you need as far as dealing with fixed point math, etc, so if you're planning on using OpenGL already, then you can just use OpenGL's built-in fixed point functions. This should help those who are unfamiliar with how to do the fixed point math to get started.


Now on to the coursework so that I can get on to the port so that I can give people a library so that its easier for them to create 3D games for the GP2X so that we can have a variety of cool 3D games on our shiny new systems.

​

It makes me feel better knowing that 3D is a possibility even without a hardware renderer. OpenGL ES would drastically improve the performace of the Quakes. The possibilities of this wonderful machine are huge I can only imagine what is accomplished in the next 12 months

 

[Optimus]

>http://members.aol.com/form1/fixed.htm

That's a cool site, thanks!

Actually, the first time I used fixed point in GP32 for a rotozoomer, I just used fixed point number addition. The second time for my Juhlia fractal code I've just finished, I had to multiply two fixed point numbers together. I tried to do it alone, but didn't thought at that time that you have to shift back after multiplication. It puzzled me for hours till enlightment came
And I haven't used Macros yet, all fixed point stuff are inside the specific demoeffects I am coding. I've just seen that website and I think it's easy to make them in macros too..

>It makes me feel better knowing that 3D is a possibility even without a hardware renderer.

It always feels nicer by knowing that a hardware can do "impossible stuff". Just check the impressive demos from C64, Amiga, older PCs, etc. There is not always the need of a new gfx hardware to do 3d and stuff. And GP32 is quite powerfull for fast software 3d engines I think..

I've seen impressive software 3d demos in 486/Pentiums, with more 3d and smoothness than the current demos I've seen on GP32 (Sad that there is not much of a demoscene here, but I said that before and wrote an article about it that is yet to be released). Personally, by coding the GP32, I see it's >= than a powerfull 486 (but with no FPU ), if I am not mistaken, and that's in pure C. I can't imagine what happens if someone codes demos in assembly for this handheld! Prolly I won't try it, cause I am too lazy =), but C democoding is still quite fast most of the times here!

 

[mrsnature]

Then for MULT, you just multiple the two fixed points, then downshift by 8 again. (ie: Rememer then multiplkying two values adds the mantissa, so it'd go to 8+8 shifted, so you then downshift to get back to 8 fixed point.)

the problem i discrovered when i started writing basic 3d functions for gp32 in fixed point, was the limitation when you only have a max 32 bits to play with...

i.e when you multiply you really need 64bits to store the intermediate answer in, becasue when you multiply two numbers greater than 2^12 (in the 24.8 case) you loose up to the highest 12bits, before you shift this result. If you do the shift before you loose accuracy.

anyway i found there are ways around this, but the challenge is to be able to do it in the least amount of operations possible of course..

BTW i never really did get my fixed point library working properly...there was always some wierd accuaracy problems that didn't seem logical given up for now..too much work at uni this year!

 

[skeezix]

yeh, accuracy is always a huge pain; if you're worried abou carry-over being lost, you could shift over to another var for temp keeping, though that does suck badly for runtime performance

jeff