dds3769@ultb.UUCP (D.D. Simmons) (11/09/89)
Last year I down loaded a file called bloom.arc. It's suppose to be a Bloom County animation. I've tried most of the available players and they all choke on it. The first few bytes of the file read: 0000: 464F524D 0002B3EC 5644454F 5644454F FORM....VDEOVDEO 0010: 0002B3E4 00000000 00000000 00000000 ................ I'd appreciate the help with this and if you could send me the player uuencoded I'd be a happy camper. To the person who posted the ftp address for uRay. Thanks. And do you have any suggestions on which libraries I should compile it with for shortest rendering time? I'm running with a stock Amiga 2000 and have plenty of ram to spare. _ Derek Simmons _
prem@geomag.fsu.edu (Prem Subrahmanyam) (11/10/89)
In article <1585@ultb.UUCP> dds3769@ultb.UUCP (D.D. Simmons) writes: > I'd appreciate the help with this and if you could send > me the player uuencoded I'd be a happy camper. To the person > who posted the ftp address for uRay. Thanks. And do you > have any suggestions on which libraries I should compile > it with for shortest rendering time? I'm running with a > stock Amiga 2000 and have plenty of ram to spare. > > _ Derek Simmons _ As always, for the fastest results (running minus a coprocessor), use the lcmffp.lib (Motorola Fast Floating Point library). Compile the program with a -ff in the "lc" command, and you're all set. This library sacrifices a little accuracy for the sake of speed (unnoticeable in Amiga-based ray-tracers). The standard lcm library included is an IEEE-based library and is quite a bit slower, but more accurate. In general, it seems that unless you're doing something chaotic (Mandelbrot /Julia sets, other fractals, etc.) that the extra accuracy given by the standard library is not useful....the fast floating point seems to do better. If you have a coprocessor, this would change--use the specific libaries for your FPU. ---Prem Subrahmanyam (prem@geomag.gly.fsu.edu)