Scaled integer triangles?
Author
I''m working with a filled triangle algorithm, but would like to convert to scaled integers. Anyone know of good resources or examples of using scaled integer math in place of floating point?
Why on earth would you want to use fixed-point arithmetics on todays machines? The FPU can handle the fp-calcs way faster than the CPU will do the shifting and integer-calcs. The only reason i can see is that you''re making the function in assembly, and can''t be bothered to learn to code the fpu. In that case, learn it 
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
Unless your project targets 75MHz Pentium I class chips, use the FPU. You will get better accuracy, better scalability, and -- most importantly -- save yourself an arseload of problems.
That''s just silly. The FPU will never get as fast as integer math, integer math is just so much more suited for microchips. Shure, it''s getting closer, it''s not such a big cost to use floating point math instead of integer, but integer is still faster.
This doesn''t apply when using the GPU in a graphics card when doing 3d, since all math is done on the card, and the GPU''s use float for all internal calulations, but for the application he describes, integer _would_ be faster. Maybe not much, but still.
(Another important point when using floats is that all C/C++ libraries take doubles for input/output parameters, so your program better do so to, otherwise half of the execution time will be convertions between the two formats... But that''s a sidenote. And only apply if you are calling those functions, like sqrt() or something.)
As for resources on the net, all I know is that the Allegro game library uses alot of fix point math, and have a bunch of functions for it, take a look at: http://alleg.sourceforge.net/ .
This doesn''t apply when using the GPU in a graphics card when doing 3d, since all math is done on the card, and the GPU''s use float for all internal calulations, but for the application he describes, integer _would_ be faster. Maybe not much, but still.
(Another important point when using floats is that all C/C++ libraries take doubles for input/output parameters, so your program better do so to, otherwise half of the execution time will be convertions between the two formats... But that''s a sidenote. And only apply if you are calling those functions, like sqrt() or something.)
As for resources on the net, all I know is that the Allegro game library uses alot of fix point math, and have a bunch of functions for it, take a look at: http://alleg.sourceforge.net/ .
No, floats aren''t quite as fast. But the difference is not worth trying to measure. Also, like I said, floats have much better accuracy for the bit width, are much more scalable, and are far easier to understand and work with in a large body of code. When a fixed point number has to set all of the integer bits and some of the decimal bits, and then undergoes division, you have to allocate more space to shift the bits around, and in many cases to two operations. This is true whether you have very very large numbers, or very very small numbers. Either way, fixed point is only more efficient in the middle ranges.
Also, with reference to C/C++, the term "float" generally just means floating point type, not a literal single-precision float. Besides, all of the C/C++ libraries I''ve used define extra functions for floats (sqrtf, fabsf, powf, sinf, cosf, and so forth), so the point is moot. I use single-precision floats in my engine and have no casting overhead on them whatsoever.
Also, with reference to C/C++, the term "float" generally just means floating point type, not a literal single-precision float. Besides, all of the C/C++ libraries I''ve used define extra functions for floats (sqrtf, fabsf, powf, sinf, cosf, and so forth), so the point is moot. I use single-precision floats in my engine and have no casting overhead on them whatsoever.
if you guys think logical than you''ll find the sad truth - there ain''t no FPU.Since everything is converted to ASM and i don''t seem to remember any float''s there.Besides the computer do shifting anyway but it will be faster if you use fixed point math.
"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR
"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR
Mihail121> "if you guys think logical than you''ll find the sad truth - there ain''t no FPU.Since everything is converted to ASM and i don''t seem to remember any float''s there"
lol...
SinisterIllusion> using full integers you won''t be able to do subpixel accuracy, using fixed point you might, but your resolution won''t be able to go over a certain limit... using floats everything is solved...
and if you use well floats, the final code can be faster than with normal integer arithmetics...
(I mean, using the FPU pipelines, but most compilers do that when they can...)
of course if you use floating point at every stage, it will be much slower. but that doesn''t mean you can''t use it at all.
lol...
SinisterIllusion> using full integers you won''t be able to do subpixel accuracy, using fixed point you might, but your resolution won''t be able to go over a certain limit... using floats everything is solved...
and if you use well floats, the final code can be faster than with normal integer arithmetics...
(I mean, using the FPU pipelines, but most compilers do that when they can...)
of course if you use floating point at every stage, it will be much slower. but that doesn''t mean you can''t use it at all.
Using floats for vertex processing, up to the rasterizer ? Yes, definitely. Do all your matrix processing, screen space projection, etc, on floating point numbers. FPU matrix operations can easily be converted to ASM. You can also take advantage of SIMD here.
But floating point in the rasterizer is an extremely bad idea. The framebuffer is integer. Can you imagine what a per-pixel float-to-int conversion is going to do to your performance ? So, in the main rasterizer (scan conversion and span filler), use fixed point math.
SinisterIllusion: how much do you already know about fixed point math ? Its basic concept is pretty simple, but there are a few catches, if you want to fully optimize the number layout for use in tight ASM filler loops. I don't really have any fixed point math resources handy (it's been a long time since I coded my last software renderer), but I guess Google will spit out quite a few. If you have any specific questions, fell free to ask.
Mihail121: look up on the f* ASM opcode family (fadd, fmul, fld, fsin, etc).
[edited by - Yann L on July 3, 2003 7:34:10 PM]
But floating point in the rasterizer is an extremely bad idea. The framebuffer is integer. Can you imagine what a per-pixel float-to-int conversion is going to do to your performance ? So, in the main rasterizer (scan conversion and span filler), use fixed point math.
SinisterIllusion: how much do you already know about fixed point math ? Its basic concept is pretty simple, but there are a few catches, if you want to fully optimize the number layout for use in tight ASM filler loops. I don't really have any fixed point math resources handy (it's been a long time since I coded my last software renderer
), but I guess Google will spit out quite a few. If you have any specific questions, fell free to ask.Mihail121: look up on the f* ASM opcode family (fadd, fmul, fld, fsin, etc).
[edited by - Yann L on July 3, 2003 7:34:10 PM]
If it''s just scan conversion you want, check out Michael Abrash'' articles (they''re on this site too as .txt, but the pdfs are better quality). He uses only pure integer math (no fixed-point either) for precision and speed. Too bad his code is absolutely awful spaghetti, but you should be able to figure it out.
YannL > of course, using floats to handle colors in the rasterizer stage surely is one of the worst things to do...
but if he''s doing perspective correct texture mapping, using floats for the x, y and z values might be quite useful, and not necessarily slow if floats are only used here in the scanline tracer...
but if he''s doing perspective correct texture mapping, using floats for the x, y and z values might be quite useful, and not necessarily slow if floats are only used here in the scanline tracer...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
