GAME OUT OF CONTROL
When running the code from Philip McBride's article "Game Controls for QuickDraw 3D" in Issue 27 of
develop, I noticed in MySetCameraData that the call to Q3Camera_SetPlacement gets fouled up after a
while. The fix shown below was needed.
void MyGetCameraData(
DocumentPtr theDocument,
TQ3CameraObject theCamera)
{
TQ3CameraPlacement cameraPlacement;
...
Q3Vector3D_Cross(
&theDocument->zVector,
&theDocument->yVector,
&theDocument->zVector);
// I added this:
Q3Vector3D_Normalize(
&theDocument->xVector,
&theDocument->xVector);
}
-- Flip Phillips
You made the right call. QuickDraw 3D requires all vectors to be of unit length (normalized). So any
changes to vectors that could make them not normalized should be followed by a call to normalize those
vectors (using Q3Vector3D_Normalize as you've done). If QuickDraw 3D didn' t have this requirement, it
would have to normalize vectors itself internally, which would take away from its efficiency.
-- Philip McBride
A SIDE ISSUE
In Steve Falkenburg's article "Planning for Mac OS 8 Compatibility" in develop Issue 26, I read the following:
After some poking around, we figured out that it was assuming that InitWindows called InitMenus as a side effect. The completely new Mac OS 8 implementations of windows and menus no longer have this behavior.
However, Inside Macintosh Volume V states, under the heading "InitWindows" on page 208:
Since the menu bar definition procedure ('MBDF') actually performs these calculations, InitWindows now calls InitMenus directly. InitMenus has been modified so that it can be called twice in a program without ill effect.
I advise the Mac OS 8 engineers to read the "You're never too smart to read the manual" section of the
Veteran Neophyte column in the same issue of develop ;-).
-- Reinder Verlinde
Your point is well taken. However, it's
worth mentioning that Inside Macintosh: Macintosh Toolbox Essentials (the more current documentation)
says no such thing, and in fact says explicitly that InitMenus should always be called after InitWindows. As
always, depending on a side effect, even
a documented one, is dangerous.
-- Dave Johnson
THINK THESE LETTERS ARE BORING?T hen why not write one of your own? We welcome your letters to the editor, especially regarding articles published in develop. Write to Caroline Rose at crose@apple.com or, if technical develop-related questions, to Dave Johnson at dkj@apple.com. All letters should include your name and company name as well as your address and phone number. Letters may be excerpted or edited for clarity (or to make them say what we wish they did). Address subscription- related queries to order.adc@applelink.apple.com. *
