In article <001e01c74314$ac56b900$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I guess it depends on what we are trying to achieve. I like the idea of having all the FRACTINT functionality in operating system independent code to link into our own programs like a JPEG library.
I agree, but I'm not an x86 assembly expert and I'm always worried I'm missing some subtlety when transliterating the asm code into C. If someone who is more familiar with the assembly converts it to C, that would be great, but I'd also take a conversion of the asm code to 32-bit. Mostly its just when reading or writing external variables that were declared 'int' -- in the existing assembly these are treated as 2-byte quantities, but the existing code is 4-byte ints, so at the very least the use of the globals has to be changed.
[...] Do we need it in modern PCs with math coprocessors?
Its good to keep it for architectures that have screaming integer performance but not so good floating-point performance, like lots of unix architectures.
The attraction in FRACTINT is the richness of features. The speed is less of an issue now. Just my thoughts anyhow.
The existing fractint code has some features that you don't get unless you get the integer math stuff working. This is some of the stuff that was left out by xfractint that we talked about earlier. Currently this version of FractInt for Windows has more features than xfractint or winfract, if the #ifdefs are any guide. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>