Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-158.txt

Text File | 1994-12-08 | 42.1 KB | 1,113 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 03 Aug 92       Volume 1 : Issue 158

Today's Topics:

    Displaying PICT all at once?
    Macs cost too much
    "True" Multitasking -- a quick summary
    QuickDraw (was re: XWindows)
    Tech Notes Stack
    appe application
    MacApp I<Classname> and ViewEdit
    Vertical Text in QuickDraw



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

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.  (This means you can't post questions to the
digest.)

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
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month 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 entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


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

From: [e-mail] (Paul Robichaux)
Subject: Displaying PICT all at once?
Organization: Fairgate Technologies
Date: Sun, 21 Jun 92 21:35:30 -0600

I have a requirement to display a 32-bit PICT "all at once"- that is,
when I show it, I need to blast it to the screen as fast as possible.

On a IIci with an EMachines accelerated graphics card, I can see the
picture being drawn. At present, my app is using the sample GetPICTData
code as presented in IM vol 5. I've looked at Steven Ritter's Museum
application, but my C skills are too weak to fully grasp it as yet.

Can anyone suggest a _fast_ way to get that image onscreen? I've
considered loading the picture into an offscreen bitmap and using
CopyBits, and will probably try that tomorrow.

Any suggestions from you Color QD gurus (you listening, Jamie?) would
be most very welcome.

Skaal,
- -Paul
- ---
                             Paul Robichaux, KD4JZG
         [e-mail] -or- ...uunet!{sci34hub,xavax}!fairgate!paul

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

From: [e-mail] (E.J. Draper)
Date: 22 Jun 1992 17:59:15 GMT
Organization: U.T.M.D. Anderson Cancer Center




Copybits.

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

From: Steve Kohlmeyer
Date: 22 Jun 92 18:31:45 GMT
Organization: University of Minnesota

In article <[e-mail]> [e-mail] (Paul Robichaux) writes:
>I have a requirement to display a 32-bit PICT "all at once"- that is,
>when I show it, I need to blast it to the screen as fast as possible.
>
>On a IIci with an EMachines accelerated graphics card, I can see the
>picture being drawn. At present, my app is using the sample GetPICTData
>code as presented in IM vol 5. I've looked at Steven Ritter's Museum
>application, but my C skills are too weak to fully grasp it as yet.
>
>Can anyone suggest a _fast_ way to get that image onscreen? I've
>considered loading the picture into an offscreen bitmap and using
>CopyBits, and will probably try that tomorrow.
>

Drawing offscreen and using CopyBits will make the image "appear"
on the screen faster.  However, if your image is large and deep
enough you will still see some scrolling with CopyBits.

The best way to make your image appear on the screen "instantly" is
to use the color look-up tables to turn your image on.  This type
of proceedure is described lightly in Vol 6 of inside Mac.

Steve Kohlmeyer
U of Minnesota

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

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 22 Jun 1992 20:00:43 GMT

[e-mail] writes:
>[e-mail] (Paul Robichaux) writes:
>>
>>I have a requirement to display a 32-bit PICT "all at once"- that is,
>>when I show it, I need to blast it to the screen as fast as possible.
>>
>>On a IIci with an EMachines accelerated graphics card, I can see the
>>picture being drawn.
>>
>>Can anyone suggest a _fast_ way to get that image onscreen? I've
>>considered loading the picture into an offscreen bitmap and using
>>CopyBits, and will probably try that tomorrow.
>
>Drawing offscreen and using CopyBits will make the image "appear"
>on the screen faster.  However, if your image is large and deep
>enough you will still see some scrolling with CopyBits.

If you're doing CopyBits right, an 8-bit full-screen image will appear
in under two ticks.  If you're doing continuous animation, this is
unacceptable, but if you're only doing the one picture, it's fast enough
that it'll appear instantaneous.  Get up to four or five ticks and it
looks less than perfect;  only when you get to ten ticks or so does it
have a "wipe" effect.

Anyway, you're right--you do need to do an offscreen pixel map.  Read
Tech Note 120 if you haven't already, and schmooze off its routines.
You're lucky you're doing a true-color image;  you don't have to
worry about color tables.  (The pmTable field should point to a
dummy color table with zero entries, if you were wondering.)

Once you've got the pixmap, make a CGrafPort that points to it,
SetGDevice() to the appropriate screen, and DrawPicture() into the port.
Then SetGDevice() back, dispose of the port, and CopyBits() the pixmap
onto the screen.

>The best way to make your image appear on the screen "instantly" is
>to use the color look-up tables to turn your image on.  This type
>of proceedure is described lightly in Vol 6 of inside Mac.

I strongly recommend using the palette manager to do this.  And if you
absolutely positively have to have it onscreen in one tick, yes, you
must do palette animation.  But that's not an option here, is it?

Though I'm nowhere near a guru (yet :-), I'll be happy to try to clarify
or elaborate on any of that stuff.  Too bad Ben Haller gave up reading
the group...
- --
 Never piss off a computer.

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

From: [e-mail] (Ray Fischer)
Date: Mon, 22 Jun 92 22:18:26 GMT
Organization: Netcom - Online Communication Services

[e-mail] (Jamie R. McCarthy) writes ...
>[e-mail] writes:
>>[e-mail] (Paul Robichaux) writes:
>>>I have a requirement to display a 32-bit PICT "all at once"- that is,
>>>when I show it, I need to blast it to the screen as fast as possible.
>>>
>>>Can anyone suggest a _fast_ way to get that image onscreen? I've
>>>considered loading the picture into an offscreen bitmap and using
>>>CopyBits, and will probably try that tomorrow.
>>
>>Drawing offscreen and using CopyBits will make the image "appear"
>>on the screen faster.  However, if your image is large and deep
>>enough you will still see some scrolling with CopyBits.
>
>If you're doing CopyBits right, an 8-bit full-screen image will appear
>in under two ticks.  If you're doing continuous animation, this is
>unacceptable, but if you're only doing the one picture, it's fast enough
>that it'll appear instantaneous.  Get up to four or five ticks and it
>looks less than perfect;  only when you get to ten ticks or so does it
>have a "wipe" effect.

CopyBits is fastest when copying between PixMaps that are the same depth.
You'll do much better copying an 8-bit image to the 8-bit screen.  One
way to do this is to make sure your offscreen pixmap is 8 bits deep.
Either draw the PICT into an 8-bit PixMap, or copy the 32-bit PixMap to
an offscreen 8-bit PixMap before copying it to the screen.

- --
Ray Fischer
[e-mail]
[e-mail]

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

From: [e-mail] (Robert J. Hall)
Date: 24 Jun 92 16:27:03 GMT
Organization: Boeing Computer Services, Seattle


 > Can anyone suggest a _fast_ way to get that image onscreen? I've
 > considered loading the picture into an offscreen bitmap and using
 > CopyBits, and will probably try that tomorrow.

While doing multiple, repeated CopyBits to the display, I find that the
srcCpy mode with the cursor hidden seems to work the quickest.
- --

  Bob Hall - Systems Analyst, Boeing Computer Services

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

From: [e-mail] (Thomas Busey)
Organization: University of Washington
Date: Thu, 25 Jun 1992 19:01:02 GMT

[e-mail] (Jamie R. McCarthy) writes:
>[e-mail] writes:
>>[e-mail] (Paul Robichaux) writes:
>>>
>>>I have a requirement to display a 32-bit PICT "all at once"- that is,
>>>when I show it, I need to blast it to the screen as fast as possible.
>>>
>>>On a IIci with an EMachines accelerated graphics card, I can see the
>>>picture being drawn.
>>>
>>>Can anyone suggest a _fast_ way to get that image onscreen? I've
>>>considered loading the picture into an offscreen bitmap and using
>>>CopyBits, and will probably try that tomorrow.
>>
>>Drawing offscreen and using CopyBits will make the image "appear"
>>on the screen faster.  However, if your image is large and deep
>>enough you will still see some scrolling with CopyBits.

>>The best way to make your image appear on the screen "instantly" is
>>to use the color look-up tables to turn your image on.  This type
>>of proceedure is described lightly in Vol 6 of inside Mac.

>I strongly recommend using the palette manager to do this.  And if you
>absolutely positively have to have it onscreen in one tick, yes, you
>must do palette animation.  But that's not an option here, is it?


I'm in dire need of an example or some source code that does this.
I have implemented this with a 16 color grey image, but I had to do some
weird things to get it to work.  Basically, the problem comes from the fact
that two entries of a palette, 0 and 255 are white and black, and can't be
set to the background color.  Therefore when the offscreen pixmap is copied
to the screen the white and black parts of the image are visible right away,
even if the rest of the palette is set to some background color.  The rest of
the image becomes visible when I do color-lookup table switching with the
appropriate colors.

Has anyone managed "instant on" with offscreen pixmaps and picts without
this problem?

Thanks
Tom Busey
Department of Psychology
University of Washington
Seattle WA 98195
[e-mail]


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

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 25 Jun 1992 23:04:49 GMT

[e-mail] (Thomas Busey) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>I strongly recommend using the palette manager to do this.  And if you
>>absolutely positively have to have it onscreen in one tick, yes, you
>>must do palette animation.
>
>I'm in dire need of an example or some source code that does this.
>I have implemented this with a 16 color grey image, but I had to do some
>weird things to get it to work.  Basically, the problem comes from the fact
>that two entries of a palette, 0 and 255 are white and black, and can't be
                       ^^^^^^^ I think you mean color table
>set to the background color.  Therefore when the offscreen pixmap is copied
>to the screen the white and black parts of the image are visible right away,
>even if the rest of the palette is set to some background color.  The rest of
>the image becomes visible when I do color-lookup table switching with the
  I think you mean palette animation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>appropriate colors.
>
>Has anyone managed "instant on" with offscreen pixmaps and picts without
>this problem?

It's true that the Palette Manager will refuse to touch the first and
last CLUT entries--those must stay white and black.  But it sounds like
you're on an 256-color device and you only need to display 16 colors.
That leaves you plenty of room to define your own white and black.

What you want to do, is set up your offscreen pixmap with the
appropriate color table, 16 shades of gray.  Then get the image into the
pixmap somehow--DrawPicture() it in, or put the bits in with your own
custom code, or whatever.  Then set up 16 colors in your _palette_ with
pmAnimated usage.  It doesn't matter where these 16 are.  Your palette
might be:

pmCourteous Black
pmCourteous White
pmAnimated Black
pmAnimated 93% Gray
pmAnimated 87% Gray
 ...
pmAnimated 13% Gray
pmAnimated  7% Gray
pmAnimated White

Then, make all those pmAnimated colors black, or whatever the
background color is.  Just change them in the PaletteHandle, and call
AnimatePalette().

Now you have to convince QuickDraw to map your color table's entries
onto the entries in your palette.  You can't expect it to go by _color_,
because the relevant section of the palette is all black by now.
Fortunately, there's a way to get QuickDraw to close its eyes and adopt
an arbitrary mapping.  If you set bit 14 of your source pixmap's color
table's ctFlags field (got that?), CopyBits will not go through all its
usual color-table checking.  Instead, it will use the value field of the
ColorSpec referred to by each source pixel as an index into the
destination _palette_ (_not_ color table).  More explicitly:  source
pixel number n will be mapped into your destination _palette_ entry
whose number is yourSourceColorTable.ctTable[n].value.  Note that no
RGB colors come into this.  Note also that the destination palette
entries don't have to be pmAnimated for this trick to work--that's
because you have to AnimatePalette() later.

So what you want to do is, set the ctTable[n].value fields to the
palette entries, which will be 2 through 17 if you use the palette I
provided above.  Keep the ctTable[n].rgb fields the same, if you like;
it doesn't matter.  CopyBits() the pixmap to the window.  Then
AnimatePalette() the old (gray ramp) palette back in where the black
entries are.  Ta-da!

This is only true for CopyBits;  it only works if you set bit 14
(0x4000);  it only works on sequential (not indexed) color tables
(because indexed color tables use the value field for something else);
it only works when you're drawing to a window (because only windows can
have palettes);  and it only works when Jupiter is in Sagittarius.  No,
just kidding about that last part there.  See TN120, p. 49, and IM VI
p. 20-17 for documentation.


Whew.  That said, you should know that there's no easy way to get 16
arbitrary colors on a _16_-color screen.  The Palette Manager will
simply refuse to change white and black.  You have to use the Color
Manager.  Alas.


As always, I reserve the right to not know what I'm talking about.  If
I'm wrong, please correct me!
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Never piss off a computer.

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

From: [e-mail] (bill coderre)
Subject: Macs cost too much
Date: 26 Jun 92 12:12:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

Dave Meyers:
|>Moreover, it would be really nice to be able to write a quick hack
|>program to do something specific and just crank it using standard
|>i/o.  That is only reasonable from a command line.

Edward V Wright:
|Not true.
|Under System 7, there is a very "Mac-like" way to write programs like
|this.  It's called a "drag and drop" application.  No command-line
|required.

Dave, there's no reason to be so bitchy. It's quite simple to
implement a shell program that you can link against to do all this
stuff with. It's not QUITE as idiot-proof as UNIX, but almost.

I wrote such a shell before Drag-n-Drop, about three years ago. It
provided a really swell user interface, all the right Mac code, and a
really trivial programming interface. It was about 25 pages of code.
About a dozen people used it to make "pipe" like utilities for Mac,
with about a 1 hour learning curve. No Mac experience required.

I wish now that I had updated it for System 7, since then I could lay
this argument to rest once and for all, by just giving it away. Sigh.
If only I had all the time in the world.

Mind you, the shell still works Just Fine. Totally Seven Studly, ray
bans and all, but not DnD. Sigh.

These are computers, Dave. Nothing's impossible. Not even too
difficult. Just need to find someone that's already done it and bribe
them with chocolate or coffee molecules.

Hey programmers! Let's make the UNIX people happy and write one of
these shells and give it away all over the Usenet, so that everyone
can do their little "pipey" things with zero hassle! Please! I will
give the person who does this a pound of their favorite chocolate, a
case of Anchor Steam, some Illy beans, or you-name-it.

Where's Don Pardo when you need him?

bill coderre
Let's stop griping and start having fun
====================================================================
DANGER: Apple Computer, Inc, maintains no official presence on the
Usenet. Postings by persons from "apple.com" are not monitored or
verified by Apple Computer, Inc. These persons are not entitled to
speak for Apple Computer, Inc, or its subsidiaries and affiliates in
any official capacity unless specifically indicated otherwise.
Therefore Apple Computer, Inc makes no warrantee of the technical
content of these postings, which are given "AS IS", and not subject to
any implied warrantees in any province. Any opinions expressed in
these postings is that of the poster, and might not represent those of
Apple Computer, Inc, or its subsidiaries or affiliates.
====================================================================

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

From: [e-mail] (Howard Berkey)
Date: Sat, 27 Jun 92 20:47:51 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (bill coderre) writes:
>Dave Meyers:
>|>Moreover, it would be really nice to be able to write a quick hack
>|>program to do something specific and just crank it using standard
>|>i/o.  That is only reasonable from a command line.
>
>Edward V Wright:
>|Not true.
>|Under System 7, there is a very "Mac-like" way to write programs like
>|this.  It's called a "drag and drop" application.  No command-line
>|required.
>
>Dave, there's no reason to be so bitchy. It's quite simple to
>implement a shell program that you can link against to do all this
>stuff with. It's not QUITE as idiot-proof as UNIX, but almost.

UNIX idiot-proof???  THAT is something I have never heard before...:-)

>I wrote such a shell before Drag-n-Drop, about three years ago. It
>provided a really swell user interface, all the right Mac code, and a
>really trivial programming interface. It was about 25 pages of code.
>About a dozen people used it to make "pipe" like utilities for Mac,
>with about a 1 hour learning curve. No Mac experience required.
>
>I wish now that I had updated it for System 7, since then I could lay
>this argument to rest once and for all, by just giving it away. Sigh.
>If only I had all the time in the world.

Me Too!

>Hey programmers! Let's make the UNIX people happy and write one of
>these shells and give it away all over the Usenet, so that everyone
>can do their little "pipey" things with zero hassle! Please! I will
>give the person who does this a pound of their favorite chocolate, a
>case of Anchor Steam, some Illy beans, or you-name-it.

This would be a truly worthwhile endeavor, since although I love the Mac OS,
there are simply some things which can be done faster with a shell.  Not a
brain-dead semi-shell like dos, but a true set of shell utilities. For example


'cat *.employee | grep brownnoser > smithers.award'

is much faster than opening a Word Proccessor, making a new file called
smithers.award, then searching through all of the employee files for the
string brownnoser, and save all the lines containing it.  Even if you have
a multi-file search capability.

The mac interface wouldn't have to be given up, the shell could run as an
application just like it does on a NeXT under NeXTStep.  It wouldn't have to
be UNIX or even UNIX-like, although IMHO the shell commands in UNIX are well
thought out.  A set of useful utilities (grep-like search, pipelining,
shell scripting capabilities, etc...) would enhance the Mac OS, not take
away from it.  And comparing it to making the machine more DOS-like would
be like calling a Silicon Graphics Indigo or a NeXT DOS-like.

- -Howard
- --
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                        [e-mail]
    "What's that thing?"
    "Well, it's a highly technical, sensitive instrument we use in
computer repair.  Being a layman, you probably can't grasp exactly what
it does.  We call it a two-by-four."
        -- Jeff MacNelly, "Shoe"

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

From: [e-mail] (Edward V. Wright)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Mon, 29 Jun 1992 19:27:06 GMT

>'cat *.employee | grep brownnoser > smithers.award'

>is much faster than opening a Word Proccessor, making a new file called
>smithers.award, then searching through all of the employee files for the
>string brownnoser, and save all the lines containing it.  Even if you have
>a multi-file search capability.

Of course, you wouldn't be using emacs to store your employee information
in ASCII text format if you had a decent database program, would you? The
problem with all this talk about UNIX-like shells and piping is that it
assumes that text files are the only type there is.  This is (almost) true
on UNIX machines, but certainly isn't on the Mac (which is software-rich
by comparison).  When you start getting into more sophisticated programs,
these commands don't even make sense.  Can you imagine typing something like
"word -m -n my_doc | macdraw -x 100 -y 500 | hypercard -foo >  a_stack" ?


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

From: [e-mail] (bill coderre)
Subject: "True" Multitasking -- a quick summary
Date: 26 Jun 92 12:25:00 GMT
Organization: Apple Computer Inc., Cupertino, CA

Jeffrey Verdegan's excellent idea:
|Okay, I confess a fundamental ignorance of the blood and guts of the Mac's
|scheduler, and I kinda doubt Apple has plans to do anything like this, but as
|long as we're talking about putting mutiple virtual Macs on top of A/UX...

|Would it be possible to either modify WaitNextEvent, or introduce
|a new call whereby the programmer specifies, in addition to sleepTicks,
|a boolean indicating wheter the program is will to let the OS effectively
|"substitute" a new value for sleepTicks, or some such thing?  Then, have a
|control panel/extension, that has sliders for all active programs that would
|indicate what percentage of processor time the given app would get.

The short answer: "Yes. A really excellent idea. Someone please do
this: I will bribe you with chocolate, caffeine, alcohol, or what have
you."

The slightly longer disclaimer: As Jeffrey said, I also am not a total
gearhead about the Mac's dirty scheduler secrets. Yes, I know that a
really reticent app can still starve out the others if it decides to
be perverse and stupid, but apps like that deserve a little remedial
batting practice over the head.

Such a little control panel should give many control freaks a totally
sexual thrill. Like those disk formatters that let you tweak every
single variable in the code. And I can ignore the whole thing knowing
I'm not really missing much, but they can be happy since they are now
8% more efficient on some benchmark.

As I said, I like Mac so much I'll bribe you.

Incidentally, I am a Mac "item" collector, so if you want a genuine
tee shirt (not the company store junk, but something rare and
wonderful, like a 7.0.1 shirt or an Elsie shirt or something), contact
me.

bill coderre
let's stop complaining and start having fun
====================================================================
DANGER: Apple Computer, Inc, maintains no official presence on the
Usenet. Postings by persons from "apple.com" are not monitored or
verified by Apple Computer, Inc. These persons are not entitled to
speak for Apple Computer, Inc, or its subsidiaries and affiliates in
any official capacity unless specifically indicated otherwise.
Therefore Apple Computer, Inc makes no warrantee of the technical
content of these postings, which are given "AS IS", and not subject to
any implied warrantees in any province. Any opinions expressed in
these postings is that of the poster, and might not represent those of
Apple Computer, Inc, or its subsidiaries or affiliates.
====================================================================

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

From: [e-mail] (Elliotte Rusty Harold)
Date: 27 Jun 92 15:34:24 GMT
Organization: New Jersey Institute of Technology

In article <[e-mail]>, [e-mail] (bill coderre) writes:
> Jeffrey Verdegan's excellent idea:
> |Okay, I confess a fundamental ignorance of the blood and guts of the Mac's
> |scheduler, and I kinda doubt Apple has plans to do anything like this, but as
> |long as we're talking about putting mutiple virtual Macs on top of A/UX...
>
> |Would it be possible to either modify WaitNextEvent, or introduce
> |a new call whereby the programmer specifies, in addition to sleepTicks,
> |a boolean indicating wheter the program is will to let the OS effectively
> |"substitute" a new value for sleepTicks, or some such thing?  Then, have a
> |control panel/extension, that has sliders for all active programs that would
> |indicate what percentage of processor time the given app would get.
>

    I think Windows already does this.  Does anyone know how well
it works?

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

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

From: [e-mail] (Alain Raynaud)
Date: 30 Jun 92 11:47:47 GMT
Organization: LRI - Univ. Paris-Sud / CNRS URA 410

It's funny people get so upset on true multitasking, now that Apple has
announced
(at the latest WWDC) that Apple is working on a tru multitasking plus
protected
memory MacOS : it sounds like this should stop all that debate : YES,
Apple is
planning to release such a beast.

Alain Raynaud

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

From: [e-mail] (Jamie R. McCarthy)
Subject: QuickDraw (was re: XWindows)
Organization: Kalamazoo College
Date: Fri, 26 Jun 1992 15:08:40 GMT

[e-mail] (Hugh Fisher) writes:
>
>    Color Quickdraw had some interesting problems, such as the non-support
>    for 32 bit displays, and serious hassles with offscreen images and pixel
>    values. These had to be fixed up later in 32 bit Quickdraw, while X11
>    has supported 32 bit color from the start.

I'm not sure what you mean by "serious hassles."  Lawrence hinted that X
doesn't support friendly, powerful sharing of a color table by multiple
windows, which the Palette Manager provides.  If true, perhaps that's
why offscreen images seem hard--the power doesn't come for free.
Actually, I don't know how offscreen images could have been done more
straightforwardly without sacrificing efficiency.

And just to clarify:  Hugh, as I'm sure you know, the original Color
QuickDraw provided an interface for direct pixel images, which includes
32 bit displays.  That interface remains unchanged to this day.

I'm not a hardware person, and I don't know whether those displays were
available in 1987.  Remember, this is when standard RAM was $100/meg.
Should Apple have provided software support for hardware that very few
people would have had, even if it meant delaying the product?  The
interface for planar PixMaps was written, too, but it remains
unimplemented because no one wants it.  Should Apple have taken the time
to implement that in 1987 as well?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Never piss off a computer.

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

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Mon, 29 Jun 92 00:25:50 GMT

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
|>
|> I'm not sure what you mean by "serious hassles."  Lawrence hinted that X
|> doesn't support friendly, powerful sharing of a color table by multiple
|> windows, which the Palette Manager provides.  If true, perhaps that's
|> why offscreen images seem hard--the power doesn't come for free.
|> Actually, I don't know how offscreen images could have been done more
|> straightforwardly without sacrificing efficiency.

  I wrote an article on this for MacTutor magazine after I had done
  the color version of a Mac game (Fire Brigade). Briefly,

  With the original palette manager, you couldn't store offscreen PICTs
  with animating colors. The Palette Manager prevented 'ordinary' drawing
  calls from getting at pixels reserved for animation. If you set up an
  offscreen pixmap for use with animating colors and tried to draw a PICT
  in it, the PICT came out in black and white. You couldn't draw it and
  then set up the animation pixel values either, or at least not by following
  the Mac API.

  Even worse, the palette manager would rearrange the palette pixel values
  on the fly. After setting up an offscreen pixmap, a simple switch to
  another appication _might_ cause the palette to be reshuffled. Next time
  the app copied from the pixmap to the screen, all the colors changed.

  Since any real animation/paint type application has to work with
  color table animation and offscreen pixmaps, the only practical way
  to write the code was to forget about the Palette Manager and fool
  around directly with the Color Manager calls.

  This all got fixed with 32 bit Quickdraw and the new pmExplicit + colors,
  which, sorry to labour the point, is much more like X Windows: there is
  a nice, straightforward 1:1 mapping between stored pixel values and index
  numbers in palettes/color tables.

|>
|> And just to clarify:  Hugh, as I'm sure you know, the original Color
|> QuickDraw provided an interface for direct pixel images, which includes
|> 32 bit displays.  That interface remains unchanged to this day.
|>
|> I'm not a hardware person, and I don't know whether those displays were
|> available in 1987.  Remember, this is when standard RAM was $100/meg.
|> Should Apple have provided software support for hardware that very few
|> people would have had, even if it meant delaying the product?  The
|> interface for planar PixMaps was written, too, but it remains
|> unimplemented because no one wants it.  Should Apple have taken the time
|> to implement that in 1987 as well?
|> --
|>  Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
|>  Never piss off a computer.

  It wouldn't have taken very much to provide future support. The
  specification of an X Windows color table entry has three 16 bit
  fields for red, green, and blue; and a 32 bit field for the actual
  pixel value. The Mac format has the same fields but only 8 bits
  for the pixel. Sure, you can find out the actual 32 bit value being
  used if you need it, but not just by looking at the color table entry.

  It did cause some trouble. The first few 24 bit color displays from
  Radius, etc had to patch the system software and had compatibility
  problems.

    Hugh Fisher

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

From: [e-mail] (Mitchell Jerome)
Subject: Tech Notes Stack
Date: 26 Jun 1992 20:06:29 GMT
Organization: Sun Microsystems


- ---

I've downloaded the Tech Notes Hypercard stack from ftp.apple.com.

How do I copy (and paste) the code from inside a Technical Note into my C program?
The Edit menu's Copy, Cut and Paste items are disabled, and pressing the mouse
button and dragging over the source code I want doesn't highlight the text.

I'm using the Hypercard 2.1 program that came with the Mac Quadra 900.

- - Mitch

- --
Mitch Jerome
[e-mail]


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

From: [e-mail] (Levent Mollamustafaoglu)
Date: 26 Jun 92 21:16:49 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] writes:
>
>---
>
>I've downloaded the Tech Notes Hypercard stack from ftp.apple.com.
>
>How do I copy (and paste) the code from inside a Technical Note into my C program?
>The Edit menu's Copy, Cut and Paste items are disabled, and pressing the mouse
>button and dragging over the source code I want doesn't highlight the text.
>
>I'm using the Hypercard 2.1 program that came with the Mac Quadra 900.
>
The Stack menus are changed and fields locked at launch time, so you can do
the following :

When you launch the stack, press the option key. The menus will not disappear
then and you can choose the field tool and unlock the main field that has the
text of the tech note. Once the field is unlocked, it will enable copy-paste
etc.

Be careful though. Once you do these, the stack is vulnerable. Be sure not
to change/delete anything.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

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

From: [e-mail] (Francois Schiettecatte)
Subject: appe application
Organization: Johns Hopkins Univ. Welch Medical Library
Date: Fri, 26 Jun 1992 21:23:13 GMT

Hi

I am developing a small 'appe' application and it's icon does not
show up on the bottom of the screen when I start up my Mac and
it is in the extensions folder.
I guess I need to set something using resedit, but what?



thanks

francois


Francois Schiettecatte
Software Engineer
Welch Medical Library
Johns Hopkins University
Internet: [e-mail]
Phone    : [phone]


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

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 27 Jun 1992 14:56:48 GMT

>
>I am developing a small 'appe' application and it's icon does not
>show up on the bottom of the screen when I start up my Mac and
>it is in the extensions folder.
>I guess I need to set something using resedit, but what?
>

appe files are scanned for INIT code at startup time. You must write an
INTI portion of your appe in order to make it show it's icon. This is not
an automatic feature (although, maybe it would be nice.)

You can use Paul Mercer's ShowINIT code to do this. This is available
in numerous places (ftp, America Online, etc.) I would suggest that you
use this code instead of writing your own since it works very nicely and
has become somewhat of a standard.



- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

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

From: [e-mail] (John Gray)
Subject: MacApp I<Classname> and ViewEdit
Organization: AI duPont Institute
Date: Fri, 26 Jun 1992 20:32:11 GMT

Greetings:

When using MacApp, the rules of the game say that when deriving a class
you should have a member function called I<Classname> and it should call
the I<Classname> from the derived class.  Is this necessary for Views
that are created with ViewEdit and then brought in by
gViewServer->NewTemplateWindow and then selected out the new window.
All the parameters to IView and its derived types seem to be exactly
what is being set by ViewEdit.

I have been failing to call this inherited I<Classname> functions for the
Views and am having no problems.  Is this ok or am I headed for trouble?

Thanks
John Gray
[e-mail]

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

From: [e-mail] (Anders Wallgren)
Date: 26 Jun 92 21:24:29 GMT
Organization: Verity, Inc., Mountain View, CA, USA

In article <[e-mail]> John Gray,
[e-mail] writes:
>When using MacApp, the rules of the game say that when deriving a class
>you should have a member function called I<Classname> and it should call
>the I<Classname> from the derived class.  Is this necessary for Views
>that are created with ViewEdit and then brought in by
>gViewServer->NewTemplateWindow and then selected out the new window.
>All the parameters to IView and its derived types seem to be exactly
>what is being set by ViewEdit.

Strictly speaking, you do not need an IMyClass method if you are only
going to instantiate your views from resources.  Whether or not you do
include them depends on what the chances are that someone else will use
this class and perhaps choose to not use resources.  It's sometimes
easier to write stuff that you aren't sure that you're going to need when
you write the class, rather than four months later when you decide to
change your mind, or someone changes your mind for you.

anders

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

From: [e-mail] (Anthony LaVigna)
Subject: Vertical Text in QuickDraw
Organization: College of Engineering, University of Maryland, College Park
Date: Fri, 26 Jun 1992 21:11:36 GMT



I working on a program where I need to draw
text vertically instead of horizontally.  How
do I draw text vertically?  Thanks.


Tony LaVigna
[e-mail]

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

From: [e-mail] (Martin Minow)
Date: 27 Jun 92 02:21:27 GMT
Organization: Apple Computer Inc., Cupertino, CA


[e-mail] asks about drawing text vertically. When I
had this problem, I solved it by writing the text into an offscreen
grafport, and transposing the port. Here's the subroutine for your
reading pleasure:

/*
 * Transpose an arbitrary bitmap (i.e., rotate it 90!).
 */

#ifdef DOCUMENTATION

Title        Transpose a Bitmap

Usage

        #include "Support.h"

        GrafPtr
        TransposeGrafPort(srcPort)
        GrafPtr            srcPort

        Return a GrafPort whose bitmap that is the transpose of
        the source bitmap (i.e., what was vertical in the source
        becomes horizontal in the destination).  This routine calls
        routines in the OffscreenGrafPort library to create the
        new port.

        If the source bitmap is invalid (or there is no memory),
        TransposeGrafPort returns NIL (zero).

        The result is rotated 90! counter-clockwise.  I.e., the
        upper-left pixel in the source becomes the lower-left
        pixel in the destination:

            ****             **  ***
            *    *            *   *
            ****    becomes    *   *
            *      *            *   *
            *    *            ********


Normal Usage:

            GrafPtr            savePort;
            GrafPtr            srcPort;
            GrafPtr            dstPort;

            GetPort(&savePort);
            srcPort = CreateOSGrafPort(rect);
            ... drawing commands ...
            dstPort = TransposeGrafPort(srcPort);
            SetPort(savePort);
            DeleteOSGrafPort(srcPort);
            if (dstPort != NIL) {
                CopyBits(
                    &dstPort->portBits,
                    &window->portBits,
                    &dstPort->portBits.bounds,
                    &drawing_rect,
                    srcCopy,
                    NIL
                );
                DeleteOSGrafPort(dstport);
            }

author

        Martin Minow.

Copyright

        Copyright 1989, Martin Minow.  All rights reserved.

        You may redistribute or incorporate this software in
        any application without restriction as long as this
        copyright notice remains intact and this source is not
        redistributed for profit.

#endif

#include "Support.h"

/*
 * This macro returns a pointer to the byte containing [v, h]
 *        base        is src_base or dst_base
 *        rowBytes    is src_rowBytes or dst_rowBytes
 *        v            is the vertical coordinate
 *        h            is the horizontal coordinate
 */
#define loc(base, rowBytes, v, h)        \
    (unsigned char *) ((base) + ((long) (v) * (rowBytes)) + ((h) >> 3))

GrafPtr
TransposeGrafPort(srcPort)
GrafPtr                srcPort;
{
        register short            i;
        register short            j;
        register short            k;
        register unsigned char    *ptr;
        GrafPtr                    dstPort;
        BitMap                    *src;
        BitMap                    *dst;
        Rect                    dst_rect;
        int                        dst_width, dst_height;
        int                        src_max;
        Ptr                        src_base;
        Ptr                        dst_base;
        short                    src_rowBytes, dst_rowBytes;

        /*
         * Get the destination bitmap organization (transposed)
         * and create the destination bitmap..
         */
        src = &srcPort->portBits;
        dst_rect.top    = src->bounds.left;
        dst_rect.left    = src->bounds.top;
        dst_rect.bottom    = src->bounds.right;
        dst_rect.right    = src->bounds.bottom;
        if ((dstPort = CreateOSGrafPort(dst_rect)) == NIL)
            return (NIL);
        EraseRect(&dst_rect);
        dst = &dstPort->portBits;
        src_base = src->baseAddr;
        dst_base = dst->baseAddr;
        src_rowBytes = src->rowBytes;
        dst_rowBytes = dst->rowBytes;
        dst_width = width(dst->bounds);
        dst_height = height(dst->bounds);
        k = width(src->bounds);                    /* For mirror transform    */
        for (j = 0; j < dst_height; j++) {        /* dst v, src h            */
            --k;                                /* Horiz pixel in src    */
            for (i = 0; i < dst_width; i++) {    /* dst h, src v            */
                ptr = loc(src_base, src_rowBytes, i, k);
                if ((((*ptr) >> (7 - (k & 7))) & 1) != 0) {
                    ptr = loc(dst_base, dst_rowBytes, j, i);
                    *ptr |= (0x80 >> (i & 0x7));
                }
            }
        }
        return (dstPort);
}

- ---
 Note: the above should have tabs set every 4 bytes.
Also note that it presupposes a subroutine that creates an offscreen
GrafPort to hold the destination rect.

Martin Minow
[e-mail]

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

From: [e-mail] (Michael Peirce)
Date: 27 Jun 92 05:53:27 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Anthony LaVigna) writes:
>
>
> I working on a program where I need to draw
> text vertically instead of horizontally.  How
> do I draw text vertically?  Thanks.

The only way is to draw it offscreen, rotate the bitmap, then copy
this to the screen.  Sorry (but QuickDraw/GX fixes this - yeah!)

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

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

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