Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-092

Text File | 1995-06-07 | 37.1 KB | 1,015 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 10 Apr 95       Volume 3 : Issue 92

Today's Topics:

        AI & New music option from Apple Computer
        Flicker-Free animation
        OpenResFile() doesn't follow aliases?
        QUICKTIME: codecNothingToBlitErr - what it is it ?
        Question about UPP's
        QuickTime VR Info needed
        TCL classes
        Tool for examining Mac memory usage



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Lawson English)
Subject: AI & New music option from Apple Computer
Date: 17 Mar 1995 22:54:04 GMT
Organization: Primenet

[ Article crossposted from comp.ai,comp.ai.edu,comp.ai.fuzzy,comp.ai.genetic,comp.ai.neural-nets ]
[ Author was Lawson English ]
[ Posted on 17 Mar 1995 22:48:59 GMT ]


I've just received the programming manual for Apple's new QuickTime
Musical Architecture (QMA) and it looks tailor-made for AI music research.

(Please note that QMA will work with both dedicated MIDI hardware AND
with the built-in sound that comes with the Mac).

For anyone who isn't familiar with it, the new QuickTime 2.0 video
software from Apple includes a special musical instruments option on the
Mac (not Windows). In addition to using the standard MIDI (hardware or
software synthesizer) files format, which freebie software from Apple will
automatically convert into paste-able and save-able QuickTime music
sound-tracks, the QMA format also provides some dramatic extensions over
the MIDI format.

For instance, instead of allowing 64 half-step pitches, the extended QMA
format allows fixed point pitches of the form:

00.00-00.ff for 127 half-step pitches

and

01.00-7f.00 for 127 half-steps with 256 microtonal increments between
each semitone.


As well, "control knobs" for each instrument sythesizer are available for
software control and both hardware and software sythesizers are supported
using the same programmatic and graphical user interfaces for both methods.

The maximum possible control knobs per instrument is a ludicrous 16,000
(2^14) with a possible +/- 32,000 values per knob.

All of these controls can be used via software-based synthesizers or
transparently routed to hardware-based MIDI, althouth MIDI only supports a
subset of what the software does. As well, the QMA architecture allows
unlimited polyphony (voices) per musical track, whereas MIDI only
supports 16.

Due to political manuevering with Microsoft, QuickTime 2.0 is available
for free distribution for both Macintosh and Windows platforms. However,
the QMA option is only available on the Macintosh. Currently, Apple ships
a file with several dozen musical instrument-patches that are available
for use within any Macintosh program or QuickTime movie. These patches
generate the basic MIDI tones for pianos, guitars, sitars, violins, flutes,
pan-pipes, etc. Apple plans to allow users to create their own
instrument-patches with a subsequent version of QuickTime.


Obviously, such powerful musical synthesizing software will have great
potential for anyone doing research on music and AI.  Since a QMA music
file is merely a stream of numbers that is presented to the OS, a neural
network could be used to generate the pitches, the instrument-choices,
the control-knob settings, etc, on-the-fly, and then pass this on to the
QMA portion of the Mac operating system for playback in real-time.

The possibilities seem limitless.

E-mail me for more info or if you have any citations for AI and music
that I might find interesting -especially the use of neural-networks for
composing music.


Thanks.

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Alan J. Weger)
Date: 19 Mar 1995 23:45:19 -0500
Organization: The Pipeline

On Fri, Mar 17, 1995 10:54:04 PM  at Lawson English wrote:

>
>I've just received the programming manual for Apple's new QuickTime
>Musical Architecture (QMA) and it looks tailor-made for AI music research.

>

Can you tell me how to obtain this manual? Can it be downloaded?   I just
bought the Inside Mac CD ROM and QMA appears to be excluded.

If you have any email addresses within Apple and APDA, they would also be
appreciated.

Thanks,
Alan J. Weger

+++++++++++++++++++++++++++

>From [e-mail] (Alan J. Weger)
Date: 19 Mar 1995 23:45:24 -0500
Organization: The Pipeline

On Fri, Mar 17, 1995 10:54:04 PM  at Lawson English wrote:

>
>I've just received the programming manual for Apple's new QuickTime
>Musical Architecture (QMA) and it looks tailor-made for AI music research.

>

Can you tell me how to obtain this manual? Can it be downloaded?   I just
bought the Inside Mac CD ROM and QMA appears to be excluded.

If you have any email addresses within Apple and APDA, they would also be
appreciated.

Thanks,
Alan J. Weger

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 25 Mar 1995 18:10:12 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3kj194$[e-mail]>, [e-mail] (Alan J.
Weger) wrote:

> On Fri, Mar 17, 1995 10:54:04 PM  at Lawson English wrote:
>
> >
> >I've just received the programming manual for Apple's new QuickTime
> >Musical Architecture (QMA) and it looks tailor-made for AI music research.
>
> >
>
> Can you tell me how to obtain this manual? Can it be downloaded?   I just
> bought the Inside Mac CD ROM and QMA appears to be excluded.
>
> If you have any email addresses within Apple and APDA, they would also be
> appreciated.

This manual (actually chapter) is part of the Quicktime 2.0 for Mac
document, and this all is part of the QT 2.0 SDK kit from APDA.

APDA info:
APDA (formerely the Apple Programmers and Developers Association) is
Apple's way of providing mail
order access to a variety of developer products. Among the products you
can purchase are the Macintosh
Programmers Workshop (MPW), Developer University self paced courses, and
many third-party development
tools.

APDA
P.O. Box 319
Buffalo, NY 14207-0319
1-800-282-2732    U.S.
1-800-637-0029    Canada
[phone]    International
[phone]    Fax
AppleLink         APDA
America Online    APDA
CompuServe        76666,2405
Internet          [e-mail]



--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From Josh Brown <[e-mail]>
Subject: Flicker-Free animation
Date: Tue, 7 Mar 1995 12:18:49 -0700
Organization: University of Utah Computer Science Department


  I have been designing some animation routines for small blocks of 8 bit
graphics on my mac. Using BitCopy results in a flicker when things are
drawn and erased. I have looked at some source code for other people's
aanimation routines, and it seems that many people use speed optimized
copy routines. HOWEVER, I don't think that this is the problem. It has
something to to with synch on the screen, I am sure. I am only drawing a
feew shapes, and they are small. They draw very fast--in MUCH less than
1/60th of a second. The flicker is intermittent.

  I know that the screen synch exists, but I don't really know how to
deal with it to make the graphics look smoothe. Is speed really the main
consideration? If so, would an optimized drawing routine solve my flicker
problem?

Thanks in advance for your ideas...
please reply to me as well as the newsgroup

Josh Brown

/-------------------------------------------------\
!                                                 !
!     *   "Monday burn Millay, Wednesday Whitman, !
!   O/     Friday Faulkner, burn 'em to ashes,    !
!  /J      then burn the ashes."                  !
!  / \                                            !
!          [e-mail]           !
!                                                 !
\-------------------------------------------------/


+++++++++++++++++++++++++++

>From [e-mail] (Yves Dufournaud)
Date: 8 Mar 1995 13:17:26 GMT
Organization: ufrima

>  I know that the screen synch exists, but I don't really know how to
>deal with it to make the graphics look smoothe. Is speed really the main
>consideration? If so, would an optimized drawing routine solve my flicker
>problem?

About animation in general, I recently download the mac related doc :
I've found it at ftp.info.apple.com in the apple.support.area
I'don't remenber where exactly but it's something like IM games or whatever.
It has a lot of stuff about animation.

--
                       -----------------------
 Yves Dufournaud ( [e-mail])
 2nd year Magistere of Computer Science, University of Grenoble France

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Wed,  8 Mar 1995 09:42:01 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer.help: 7-Mar-95
Flicker-Free animation Josh [e-mail].u (1353*)

>   I have been designing some animation routines for small blocks of 8 bit
> graphics on my mac. Using BitCopy results in a flicker when things are
> drawn and erased. I have looked at some source code for other people's
> aanimation routines, and it seems that many people use speed optimized
> copy routines. HOWEVER, I don't think that this is the problem. It has
> something to to with synch on the screen, I am sure. I am only drawing a
> feew shapes, and they are small. They draw very fast--in MUCH less than
> 1/60th of a second. The flicker is intermittent.

Most likely, the flicker is there because you're doing something
flickery. For example, if you move a sprite by erasing it to the
background color (or image) and then redrawing it in a slightly
different location, you'll get flicker -- no surprise, it's just that
there background color is *there* for a brief time, so it shows up on
the screen sometimes.

Faster blitting routines will reduce this flicker but will never
eliminate it. Screen synchronization may work, but is a pain to write.

What you probably want to do is use an off-screen image to do the work.
For the example above, you might do the following:
- compute the rectangle which is the union of the old position and new position
- copy that rectangle to an off-screen work area
- erase the sprite on the work area
- redraw the sprite in the new position in the work area
- copy the whole rectangle back to the screen.

If you have several objects moving, it may be more efficient to work on
a bunch of them at once. Some sprite toolkits keep the entire image
off-screen, do all the work there, and copy the entire thing to the
display every tick. However, that gets slow for large displays. If you
only have a few objects, using the method above for each of them may
work.

Alternatively, grab Ingemar's SAT toolkit from Info-Mac and let it worry
about it all.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From Gordon Graber <[e-mail]>
Date: 8 Mar 1995 16:42:34 GMT
Organization: Drake University

In article
<[e-mail]> Josh
Brown, [e-mail] writes:
>  I know that the screen synch exists, but I don't really know how to
deal with it to make the graphics look smoothe. Is speed really the main
consideration? If so, would an optimized drawing routine solve my flicker
problem?
>...

Josh,
  Your best bet is to make sure you are not erasing directly on the
screen.  Do all of your drawing and erasing in an off screen graphics
world, GWorld and then copy the final image from the off screen world to
the main screen.  This will produce the smoothest looking graphics
possible( without resorting to some sort of assembly language booster).
  Yes, make sure your drawing routines are as tight and as efficient,
processor time wise, as they can be.
  Using the Vertical BLanking interrupt is not necessarily going to gain
you what you need.  It would depend on exactly how much drawing you are
doing.  About the only thing you can accomplish, in regard to your
problem, at VBL interrupt time is to set a flag allowing your program to
determine that an interrupt has occurred.
Because of the restrictions on what can take place in an interrupt
routine, you cannot "perfectly" sync your graphics to the monitors
retrace. Your program would need to check this flag to see if it was time
to draw, i.e. an interrupt occurred, after the fact.
  If you construct your code properly, and have little drawing to
actually do, using this method to sync to the VBL may actually work for
you.
  There are many other issues pertaining to the speed of graphics and
flicker free animation.  You could look for the archives of this group or
comp.sys.mac.programmer for more info.
"I want my flicker free MTV!"
Gordon Graber: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ernie Soffronoff)
Date: 9 Mar 1995 20:53:36 GMT
Organization: StarNet Communications, Inc

I have a question about all this... when computing the rectangle to be
redrawn, I understand that you want to try to keep your rectangle a
multiple of n {bits | pixels}.  What's n, and is it bits or pixels, or
does it matter since bpp is a power of 2?

I also vaguely remember that the above didn't matter, if you set
something to zero (the bit depth of the GWorld?).

Help.  My memory is weak on this.

--Ernie
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: 13 Mar 1995 08:05:56 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

[e-mail] (Ken Long) writes:

>Josh Brown ([e-mail]) wrote:

>:   I know that the screen synch exists, but I don't really know how to
>: deal with it to make the graphics look smoothe. Is speed really the main
>: consideration? If so, would an optimized drawing routine solve my flicker
>: problem?

>You can eliminate all flicker except that in the cursor when it's over
>your drawing without using a VBL task, by simply drawing to offscreen RAM
>and shifting that RAM into your screen RAM.  This is called offscreen
>drawing or "GWorld drawing."

You can actually kill the cursor flickering as well, though this seems
to be a more arcane art. I have a scrolling image in my current project,
and it is copied to the screen from a GWorld as soon as soon as I get the
ok from the VBL task.  The cursor can be moved over the (large) animation
*perfectly* smoothly, with absolutely no trace of flicker. This has
something to do with the animation being in the bottom half of the
screen. If the animation is moved up the screen, then cursor
flickering gradually appears until the cursor is at the top of
the screen, where the flickering is very bad. I haven't worked
out the mechanics of why this is so yet, but it's an interesting
thing to keep in mind.

[lots of useful code by Mark Hanrek via Ken Long deleted]

--
David Wareing                     [e-mail]
Adelaide, South Australia
Macintosh Games & Multimedia Programming
- ------------------------------------------------------------
May you live in interesting times

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 18 Mar 1995 12:20:12 GMT
Organization: Helsinki University of Technology

>[e-mail] (Ken Long) writes:
>>You can eliminate all flicker except that in the cursor when it's over
>>your drawing without using a VBL task, by simply drawing to offscreen RAM
>>and shifting that RAM into your screen RAM.  This is called offscreen
>>drawing or "GWorld drawing."

In article <3k0ud4$[e-mail]> [e-mail] (David Wareing) writes:
>You can actually kill the cursor flickering as well, though this seems
>to be a more arcane art. I have a scrolling image in my current project,
>and it is copied to the screen from a GWorld as soon as soon as I get the
>ok from the VBL task.  The cursor can be moved over the (large) animation

CopyBits calls ShieldCursor. ShieldCursor hides the cursor if it is in or
enters the rectangle that is affected. To minimize cursor flicker, you can
call copybits in smaller segments so that the time that the cursor is
shielded is minimized. Of course this will increase overhead.

I do not recommend using VBL tasks to reduce flicker, because the task
becomes much more complicated when you are dealing with more than one
monitor. The reason you didn't get cursor flicker when you had the copybits
in the lower area of the screen was that you synchronized with the blanking
and did all of your copying fast enough so that by the time the area where
the cursor was located was shown on the screen, the cursor was no longer
shielded by the CopyBits.

When talking about Macs, you can (almost) never say "the screen". Always
assume that there are more than one.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

---------------------------

>From [e-mail] (Steve Chamberlin)
Subject: OpenResFile() doesn't follow aliases?
Date: 24 Mar 1995 15:31:12 -0500
Organization: MaK Technologies, Inc.

While doing some playing around with my code last night, I discovered
that if I replaced a needed data file with an alias to the file, the
program ceased to work. My program opens this file with OpenResFile()
and reads certain resources out of it that it needs in order to run.
Why didn't the alias work? I can't imagine that I should have to
change my code; I thought aliases were supposed to be handled by the
file system and therefore be transparent to programs and users.

I tried using HOpenResFile() and OpenRFPerm(), but these both had the
same problem. It seems that all of these functions actually open the
resource fork of the alias file itself, rather than the file that the
alias is pointing to. How can I change this behavior?

--Steve

--
Steve Chamberlin | [e-mail]
MaK Technologies | http://www.mak.com/~slc/home.html

+++++++++++++++++++++++++++

>From David A Lyons <[e-mail]>
Date: Sat, 25 Mar 1995 03:03:05 GMT
Organization: Apple Computer, Inc.

In article <3kva6h$[e-mail]> Steve Chamberlin,
[e-mail] writes:
> While doing some playing around with my code last night, I discovered
> that if I replaced a needed data file with an alias to the file, the
> program ceased to work. My program opens this file with OpenResFile()
> and reads certain resources out of it that it needs in order to run.
> Why didn't the alias work? I can't imagine that I should have to
> change my code; I thought aliases were supposed to be handled by the
> file system and therefore be transparent to programs and users.

Aliases are supposed to be fairly transparent to users, but not so
much to programmers.  The file system knows nothing about aliases.

You need the ResolveAliasFile function, on page 7-52 of IM: Macintosh
Toolbox Essentials (chapter 7, Finder Interface).

Dave Lyons
Mr Tangent

+++++++++++++++++++++++++++

>From [e-mail] (Shopsin)
Date: Sat, 25 Mar 1995 11:35:03 -0500
Organization: Quill Program

OpenResFile is fairly dumb command.  It was designed to work on the
original Mac when no one ever had though of using aliases or even running
multiple apps yet.  In general Apple advises that you call FSOpen first to
find a resource file before calling OpenResFile of FSpOpenResFile to avoid
problems.

--
Michael Shopsin
[e-mail]

"If it's not on fire then it's a software problem."

+++++++++++++++++++++++++++

>From Alex Rosen <[e-mail]>
Date: 27 Mar 1995 16:39:22 GMT
Organization: Pro CD, Inc.

In article <3kva6h$[e-mail]> Steve Chamberlin,
[e-mail] writes:
> Why didn't the alias work? I can't imagine that I should have to
> change my code; I thought aliases were supposed to be handled by the
> file system and therefore be transparent to programs and users.

I believe the only time aliases get translated for you are when the user
selects a file from any GetFile variation, or when they double-click on
an alias to one of your files.

It is kind of surprising that aliases aren't automatically translated. In
some cases this prevents major problems though, at least with aliases to
folders or disks. Say, for example, that you have hierarchical Apple
menus, so you put an alias of your hard drive in your Apple Menu Items
folder to be able to access anything on your disk. Now an anti-virus
program which hasn't been updated to deal with aliases might get stuck in
a recursive loop when scanning the hard drive.

--Alex

---------------------------

>From [e-mail] (Chris Orgill)
Subject: QUICKTIME: codecNothingToBlitErr - what it is it ?
Date: Sun, 12 Mar 1995 21:12:44 +0000
Organization: (none)

Hi,

I'm using ::DrawTrimmedPicture() on a QT-compressed picHandle
created by ::MakeThumbnailFromPictureFile() on a file compressed
using the Photo JPEG codec. The second time it gets called - with
the same arguments - in an update event - the call returns -8976.
(QT 2.0)

This is codecNothingToBlitErr according to the latest Errors.h.
This is not documented as a return code for ::DrawTrimmedPicture()
in NIM:QuickTime  and neither is the verb 'to blit', so I am
a bit mystified as to how to handle this error. I don't have
NIM: QT Components, but I shouldn't have to, should I ? :-|

Does it mean that nothing had changed, so the codec didn't need
to do any work ? Can I ignore this special case ?

Any pointers to where this is documented gratefully accepted.

Best,

Chris Orgill



+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 25 Mar 1995 17:32:59 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <v01510100ab89113d2be6@[158.152.31.162]>,
[e-mail] (Chris Orgill) wrote:

> Hi,
>
> I'm using ::DrawTrimmedPicture() on a QT-compressed picHandle
> created by ::MakeThumbnailFromPictureFile() on a file compressed
> using the Photo JPEG codec. The second time it gets called - with
> the same arguments - in an update event - the call returns -8976.
> (QT 2.0)

It's a bug, fixed when you install the Apple MM tuner, the QD low mem
error is not fully cleared in all instances.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From David Shortt <[e-mail]>
Subject: Question about UPP's
Date: 26 Mar 1995 03:55:58 GMT
Organization: RAIN Public Access Internet (805) 967-RAIN

I have a question regarding procedure pointers and UPP's.  I
understand the basic use of UPP's for PPC and 68K code -- my
question is a bit more esoteric.  I have several often-used
call-back functions, so I have declared global UPP variables
for them which I set at program start-up, and I pass those
variables to the appropriate routines (like ModalDialog, for
example). My question is this:  am I guaranteed that my global
UPP's will remain valid throughout the program's execution, even
if, in the case of 68K code, the OS loads and unloads segments?
Do I need to take any special precautions?  To my knowledge
I've never experienced a problem, but I'd like to know.

Thanks in advance.

Dave Shortt
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Richard Wesley)
Date: 27 Mar 1995 03:03:40 GMT
Organization: Punch Deck Consulting

In article <3l2oke$[e-mail]>
David Shortt <[e-mail]> writes:

> I have a question regarding procedure pointers and UPP's.  I
> understand the basic use of UPP's for PPC and 68K code -- my
> question is a bit more esoteric.  I have several often-used
> call-back functions, so I have declared global UPP variables
> for them which I set at program start-up, and I pass those
> variables to the appropriate routines (like ModalDialog, for
> example). My question is this:  am I guaranteed that my global
> UPP's will remain valid throughout the program's execution, even
> if, in the case of 68K code, the OS loads and unloads segments?
> Do I need to take any special precautions?  To my knowledge
> I've never experienced a problem, but I'd like to know.
>

Procedure pointers under 68K are generally jump table references, so if the
segment is unloaded then it will get reloaded.  The only real problem would be
interrupt service routines (e.g. sound callbacks, completion routines and their
ilk).  These need to be locked in memory so that the segment loader will not
get called at interrupt time.  This goes for both emulated 68K on a PPC and
native 68K.

I don't believe that PPC has these problems.

> Thanks in advance.
>
> Dave Shortt
> [e-mail]
>
>


- rmgw

- ------------------------------------------------------------------------------

Richard Wesley     [e-mail] | "Oh boy!  Did you forget the plot
Punch Deck Consulting  [e-mail] |  _again_?"
     Macintosh Software Development     |    - Rocket J. Squirrel
- ------------------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 28 Mar 1995 08:45:30 -0800
Organization: Internet for the Olympic Peninsula

In article <3l2oke$[e-mail]>, David Shortt <[e-mail]> wrote:

> I have a question regarding procedure pointers and UPP's.  I
> understand the basic use of UPP's for PPC and 68K code -- my
> question is a bit more esoteric.  I have several often-used
> call-back functions, so I have declared global UPP variables
> for them which I set at program start-up, and I pass those
> variables to the appropriate routines (like ModalDialog, for
> example). My question is this:  am I guaranteed that my global
> UPP's will remain valid throughout the program's execution, even
> if, in the case of 68K code, the OS loads and unloads segments?
> Do I need to take any special precautions?  To my knowledge
> I've never experienced a problem, but I'd like to know.

Re:  the 68K machines.  For now, the NewxxxProcPtr () "functions" are--on
68K--macros which reduce to a simple cast.  CFM 68K will change that, but
then the situation will be as for PPC now.

Re:  the PPC machines.  The structure pointed to by the result of
NewxxxProcPtr () is allocated via NewPtr ().  It better not move or
disappear (if they start doing that, your code won't get far enough for
your question to matter).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Mon, 27 Mar 1995 09:24:44 -0700
Organization: Skunkworks

In article <3l2oke$[e-mail]>, David Shortt <[e-mail]> wrote:

>My question is this:  am I guaranteed that my global
>UPP's will remain valid throughout the program's execution, even
>if, in the case of 68K code, the OS loads and unloads segments?

Yes, they will remain valid, because 68K Mac software uses jump table
entries rather than actual procedure addresses when creating pointers to
routines, and the jump table never moves. See chapter 7 of Inside Mac:
Processes.

Grobbins.                            [e-mail]

---------------------------

>From [e-mail] (Brian Quinlan)
Subject: QuickTime VR Info needed
Date: 13 Mar 95 00:54:19 GMT
Organization: Simon Fraser University

I would like some information about QuickTime VR. I have an programming idea
using this technology but Apple hasn't release it to the masses. I would
like to know what the API is like, when it will be available, what will the
license cost and, more importantly, how can I get hold of it NOW. I heard
that you can get it buy buying the developer CD for $250, is that true?

--

Brian Quinlan
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (GeoffClapp)
Date: 15 Mar 1995 11:08:55 -0500
Organization: America Online, Inc. (1-800-827-6364)

The developer CD is actually $2500. I have some info/demos if you are
interested.

+++++++++++++++++++++++++++

>From [e-mail] (GeoffClapp)
Date: 15 Mar 1995 11:08:55 -0500
Organization: America Online, Inc. (1-800-827-6364)

The developer CD is actually $2500. I have some info/demos if you are
interested.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 25 Mar 1995 18:20:19 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail] (Brian Quinlan)
wrote:

> I would like some information about QuickTime VR. I have an programming idea
> using this technology but Apple hasn't release it to the masses. I would
> like to know what the API is like, when it will be available, what will the
> license cost and, more importantly, how can I get hold of it NOW. I heard
> that you can get it buy buying the developer CD for $250, is that true?

What I know the tools should be available from APDA shortly, but I've
given up on predicting the exact dates as releasing something might always
get postposed (as I found out when we tried to release the QT 2.0 SDK).
Same is true of pricing, I would wait and see, and something will shortly
be announced. If you have a cool concept, send email to
[e-mail], you are then also registered in a
database so Apple could forward you more VR related information.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From [e-mail] (Sterling)
Subject: TCL classes
Date: 23 Mar 1995 16:32:10 GMT
Organization: Clark Internet Services, Inc., Ellicott City, MD USA

Can someone point me towards a repository for TCL classes that
was once stored at ftp.brown.edu?

Thanks.

--
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Thu, 23 Mar 1995 13:36:28 -0600
Organization: metrowerks, inc.

In article <3ks7qa$[e-mail]>, [e-mail] (Sterling) wrote:

> Can someone point me towards a repository for TCL classes that
> was once stored at ftp.brown.edu?

It moved to daemon.ncsa.uiuc.edu.

-es

__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come.
   -Nietzsche (Groening)

+++++++++++++++++++++++++++

>From Dan Crevier <[e-mail]>
Date: 23 Mar 1995 21:09:26 -0500
Organization: Harvard University

[e-mail] (Eric Scouten) writes:

>In article <3ks7qa$[e-mail]>, [e-mail] (Sterling) wrote:

>> Can someone point me towards a repository for TCL classes that
>> was once stored at ftp.brown.edu?

>It moved to daemon.ncsa.uiuc.edu.

        And there's now a WWW index at:

http://rhino.harvard.edu/dan/TCLArchive.html

        I tried posting something about it earlier today, but it doesn't
seem to show up.  Maybe I'll try again.

Dan


---------------------------

>From [e-mail] (Jeff Horton)
Subject: Tool for examining Mac memory usage
Date: Tue, 21 Mar 1995 08:37:51 -0600
Organization: UT Memphis Computing and Telecommunications

We are experiencing a problem with an extension that eats up available
memory.  I am trying to find a program that will display detailed memory
allocation information to try and determine the exact problem. Shareware
is preferred, but commercial packages would be OK.

Any response helps-

Jeff S. Horton
User Support
University of Tennessee, Memphis

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (BRANDAUER CARL M)
Date: 21 Mar 95 18:46:40 GMT
Organization: University of Colorado at Boulder

I found "Memory Mapper" by R. Fronaberger ither on AOL or Compu$erve.

Cheers - Carl

+++++++++++++++++++++++++++

>From [e-mail] (Greg Ferguson)
Date: Wed, 22 Mar 1995 21:23:17 -0700
Organization: Primenet

In article <[e-mail]>,
[e-mail] (Jeff Horton) wrote:

> We are experiencing a problem with an extension that eats up available
> memory.  I am trying to find a program that will display detailed memory
> allocation information to try and determine the exact problem. Shareware
> is preferred, but commercial packages would be OK.

There are a couple of things that might help.

Try turning on the heap scrambling in MacsBug. That might point out where
the extension is doing dumb things.

QC by Onyx will put any code through a wringer for memory use and
allocation. We've found some pretty subtle errors in minutes using it.
Actually, it's pretty irritating how quickly it finds errors some times.
:-)

Metrowerks has ZoneRanger that can tell a bit about the contents of RAM too.

Greg

--
Greg Ferguson
[e-mail]

* Answer hazy, ask again later *

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 23 Mar 1995 22:18:45 -0600
Organization: OuterNet Connections, Inc.

In article <[e-mail]>,
[e-mail] (Jeff Horton) wrote:

< We are experiencing a problem with an extension that eats up available
< memory.  I am trying to find a program that will display detailed memory
< allocation information to try and determine the exact problem. Shareware
< is preferred, but commercial packages would be OK.
<
< Any response helps-
<
< Jeff S. Horton
< User Support
< University of Tennessee, Memphis
<
< [e-mail]

A Macsbug hd (heap display) will give just about as detailed a memory
summary as you might want.

____________________________________________________________________
Brian  Stern  :-{)}                           [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Francois Roy)
Date: Thu, 23 Mar 1995 13:00:53 GMT
Organization: Statistics Canada

Jeff Horton ([e-mail]) wrote:
: We are experiencing a problem with an extension that eats up available
: memory.  I am trying to find a program that will display detailed memory
: allocation information to try and determine the exact problem. Shareware
: is preferred, but commercial packages would be OK.

 I have something called "Memory Mapper 1.1.1" by R. Fronabarger, which
draws a map of all the active APPLs and INITs.  It is freeeware.  I got
it on a free diskette as part of a Mac troubleshooting course, but it
should be possible to find it on the net.

---------------------------

End of C.S.M.P. Digest
**********************