visitors since September 17, 1996.
April 13, 1999
If you think you've found a bug, please let me know. I don't think there are any bugs at present in the VideoToolbox code, though there are a few limitations mentioned in the files. We use the VideoToolbox code every day in our work, so we take bug reports very seriously. - Denis Pelli
***THE VIDEO TOOLBOX IS NOW COMPATIBLE WITH CODEWARRIOR PRO 4.1***
KillEveryoneButMe.c doesn't work.
Celeste (Hao) Sun writes, "I am a graduate student at University of Chicago, working in the lab of Joel Pokorny and Vivianne Smith. KillEveryoneButMe worked well in Mac OS 7.5, but doesn't seem to work in Mac OS 8. The program didn't show any error message, but it didn't kill other programs."
Reply: I've never used that code. I think Apple distributes a C program with a similar name on their Developer CDs, so it ought to be easy to find something by a web search. I'd be happy to replace my defunct code with working code, or a link to working code.
7300/7500/7600/8500/8600 GRAPHICS DRIVER:
Frans Cornelissen writes "I've been trying to get the 7500/7600/8500 graphics driver to work on a 8600/200 (System 7.5.5) but it doesn't seem to work. I don't get the extra resolutions in the monitor & sounds control panel. Do you know of anyone who got it to work?"
CODEWARRIOR OPTIMIZER BUGS:
My advice is to never enable optimization. I've never found any improvement of my code with automatic optimization, and the vast majority of the C-code-generation bugs reported by Metrowerks (when they list improvements in new releases) are due to the optimizer. Thus, unless you have some compelling reason to enable optimization, I strongly suggest turning it off. Without optimization, their C compiler seems to be essentially bug-free.
Tilman Vogel (7/18/97) discovered that the while loop in GDFrameRate() in GDTime.c becomes endless if the CodeWarrior Pro 1 optimizer is enabled. That loop waits for a flag to be modified by an interrupt service routine. The wait becomes endless if the compiler "optimizes" the code to monitor a register copy instead of the actual flag. In Standard C, declaring a variable "volatile" forces the compiler to always access the actual variable. Unfortunately the CW optimizer fails to notice our "volatile" declaration. Metrowerks (8/14/97) agrees with our analysis, and has assigned it Bug No. MW01503.
On 2/23/98 & 3/2/98, Ben Singer wrote: "I know you don't recommend optimizing, and optimization bugs are Metrowerks' fault, but, for what it's worth, I can't compile Luminance.c under CodeWarrior Pro2 after changing the Global Optimization from Level 2 to Level 3 (Level 3 adds "loop-invariant code motion", "strength reduction", and "loop transformations", whatever those are). With Level 3 on, the compiler crashes, dropping me into MacsBug. To crash, two other conditions must hold: 1) RAMDoubler loaded (latest version 2.0.2 tested). (Apple's VM has no effect.) 2) In the PPC Processor control panel, uncheck "Use FMADD & FMSUB". There doesn't seem to be an interaction with any other optimization settings (peephole, Speed or Size, instruction scheduling), but I haven't tested all the combinations. (Mac OS 8.1, 7500 with a 604e/200 daughtercard in 3.5:1 mode, 57.14MHz bus) I'll send the relevant info to Metrowerks."
USING <math.h> INSTEAD OF <fp.h>
Just #include <math.h> before including VideoToolbox.h. VideoToolbox.h won't #include <fp.h> if you've already #included <math.h>.
THINK C:
Q: Michel Pinard writes (8/18/97), "I am using THINK C version 7.0.4. I recently downloaded the VideoToolbox. The first thing I tried to do was to precompile the VideoToolbox.h file, but the compiler stops at the following line:"
#error "Need Apple's Universal Headers"
A: Download the latest version of Apple's Universal Headers. It's free from Apple. I no longer recommend THINK C, which has been stagnant for many years. Symantec has announced that they are no longer developing their C/C++ development environment. Nearly everyone now uses Metrowerks CodeWarrior Pro. I suggest you switch to CodeWarrior.