Is it possible to do 3d math with only integers?

Discuss whatever you want here--both QB and non-QB related. Anything from the DEF INT command to the meaning of life!

Moderators: Pete, Mods

Post Reply
User avatar
Codemss
Veteran
Posts: 124
Joined: Sun Jun 24, 2007 6:49 am
Location: Utrecht, The Netherlands
Contact:

Is it possible to do 3d math with only integers?

Post by Codemss » Mon Dec 03, 2007 1:53 pm

Since I'm very into optimizing my code, I want to use as much integers as much (only instead of other types of variables of course :P). I looked in Mono & Disco's code, and there it uses single variables to calculate the screen coordinates for 3d models. Is it also possible to get a 3d model running at good performance (I mean that it runs smooth, the speed will be okay I think, integers are usally faster then singles)?

I think you need floating point math to prevent that the model is moving(rotating) weird, but I doubt if it's possible because Relsoft didn't use it in his code.
(most of Relsoft's code is optmized well).

Codemss
Check out my site: <a href="http://members.lycos.nl/rubynl">Click here</a>
Hope you like it. Send some feedback if you want: <a href="mailto:basicallybest@live.nl">Mail me</a>
Codemss, before known as RubyNL

User avatar
Mentat
Veteran
Posts: 409
Joined: Tue Aug 07, 2007 3:39 pm
Location: NC, US

Post by Mentat » Mon Dec 03, 2007 5:20 pm

The only way I can think of is using large numbers and hoping they're large enough so that truncating is negligible. Or using UDTs, but that takes more memory. :?

I did manage to use only integers for rotation, but that was becuase of simplicity and eventually rounding errors did pop up after time (10 seconds of continual motion in certian directions :oops: ).
For any grievances posted above, I blame whoever is in charge . . .

Nemesis
Coder
Posts: 36
Joined: Mon Aug 16, 2004 12:54 pm
Location: Colorado Springs, Colorado

Post by Nemesis » Tue Dec 04, 2007 6:40 am

You can eliminate floating point calculations by creating sin/cos LUT's, and other types of precalculating methods. If you're using QB, then optimizing your graphical routines for speed is vital. One major speed optimization is keeping calculations, especially precisioned math out of nested loops.
I'm actually working on creating my own fast 2D and 3D rotating routines,
for my ever-growing QB graphics library. After already implementing
the zooming/scaling routines earlier yesterday, I happened to read your
post today and I decided to do some bench-marks on my new routine.
Since I eliminated the floating point calculation by creating a matrix of precalculated variables I was a little curious if this approach would
actually be faster or not. Much to my suprise, after comparing the
routine using my optimizations, to the same routine using the floating
point calculation, there was a 400% speed increase. Even when I used
the FFix patch on the floating point routine, there was only about a 140% speed increase. (That's a big difference in speed for just removing one floating point operation! :-)

Cya,

Nemesis

User avatar
Mentat
Veteran
Posts: 409
Joined: Tue Aug 07, 2007 3:39 pm
Location: NC, US

Post by Mentat » Tue Dec 04, 2007 7:25 am

Nemesis wrote:I was a little curious if this approach would
actually be faster or not. Much to my suprise, after comparing the
routine using my optimizations, to the same routine using the floating
point calculation, there was a 400% speed increase. Even when I used
the FFix patch on the floating point routine, there was only about a 140% speed increase. (That's a big difference in speed for just removing one floating point operation! :-)

Cya,

Nemesis
:cry: I've been using Doubles the entire time!
For any grievances posted above, I blame whoever is in charge . . .

User avatar
Codemss
Veteran
Posts: 124
Joined: Sun Jun 24, 2007 6:49 am
Location: Utrecht, The Netherlands
Contact:

Post by Codemss » Tue Dec 04, 2007 12:35 pm

Nemesis wrote:Since I eliminated the floating point calculation by creating a matrix of precalculated variables I was a little curious if this approach would
actually be faster or not. Much to my suprise, after comparing the
routine using my optimizations, to the same routine using the floating
point calculation, there was a 400% speed increase. Even when I used
the FFix patch on the floating point routine, there was only about a 140% speed increase. (That's a big difference in speed for just removing one floating point operation! Smile
Very nice! This was exactly what I was looking for! So did you whipe out all the floating point math or what? (I don't know much about matrices, except how to spell them :P)

BTW, your graphics library sounds interesting. Have you got some demo's of it?
Check out my site: <a href="http://members.lycos.nl/rubynl">Click here</a>
Hope you like it. Send some feedback if you want: <a href="mailto:basicallybest@live.nl">Mail me</a>
Codemss, before known as RubyNL

Post Reply