I originally wrote my 3d engine to use fixed point math instead of float. it is much faster on my p166. however, after reading many posts that people here recommend floating point over fixed, i have begun to rethink this strategy. (after all i know this thing won''t be finished for some time and this computer is well outdated already). i could just leave it fixed, but that poses some POTENTIAL problems (even though i haven''t encountered them yet)... ie if a light was very far away or two objects were far away the fixed math could fall out of range.. and the same is true of points really close together, the decimals could get lost in calculations and just become 0 (specifically in vector calculations and normalizations). so say i switch all my math to float i would not have to worry about how far or how close things might be. i see people arguing not to use lookup tables for sin & cos what about the sqrt() required to normalize? i perform my own vertex lighting so this could get called alot. i''m anxious to see what everyone''s opinion on this topic is. thanks.

Wow, wish I was expericened enugh to have a opinion, it sounds real contoversial. >:/ Well, this was useless, I know

When you say "fixed point" do you mean integers?

E:cb woof!

When i say fixed point i mean integers shifted left 8 bits

If you''re already using fixed point, you might as well stay with it. True, you have potential overflow problems, but you''ve also gotten improved precision inside your number range.

Lookup tables, IMO, for sin and cos are fine.
For sqrt, it''s not that bad, four or so iterations of fixed point iteration should get you a sqrt value within the precision of your fixed point numbers, which is about the same overhead as the library sqrt function.

Read this code written by the nVidia devgroup:

Fast Math Routines

It will give you a lot of input on floating point math and how to make it really fast.

I''m sure this has been said before but...

Yes, floating point is getting faster every day but..when you are done doing all of your math and you need to rasterize the image you have to convert the floating point to integers. This is where you get killed with floating point.

You could do what I''ve done (though it may not be the best way to do it but..) setup a MATH class that contains all of your math in two versions, one thats floating point and one thats fixed point - then use function pointers to make everything called the same - you could overload everything as well.

That way you can switch modes whenever you want to - on a slower/older computer use fixed point - on a newer one use floating point

Hope that kinda helps - if only a little

Cheers,
JKaneBaggett

On newer computers, all the floating point math is done on a seperate part of the chip then the integer math. I''d guess that it''s a lot faster.

What you should do is write a quick program that takes a number, like 11, and loops 100,000 times dividing it by 10, then multiplying it by 10 using the 2 methods. Record how many ticks it takes for each method. At least then you''ll get some idea of how much time you''ll save.
(if it''s like 300 ticks vs. 305 ticks, forget it!)

E:cb woof!

The "Fast Math Routines" I mentioned previously shows how to convert from float to integer in a much faster way than with (int)fValue, where fValue is a float variable.

thanks for the link Spellbound. i found a routine to convert float to integers at flipcode.com a while back, but the link you sent seems to have alot of additional tricks.

SiCrane, i appreciate your advice, but the reason i''m leaning toward just leaving fixed point behind is I''ve already had a small glitch with overflow calculating normals on really small faces. it was easy to solve, but it raised some concerns because this program is gonna run on a very large world with a distant light that acts as a sun and moves dynamically. i''m pretty certain that somewhere the opportunity is going to arize that allows a number to exceed 64k after several squares and additions.

KaneThp, I''m using opengl for the rasterization and eventually a version will be ported to d3d, so using all floating point math actually will reduce the number of
conversions between the two types of variables.