From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-041
Date: Sat, 2 Jul 1994 17:46:50 +0200 (MET DST)
C.S.M.P. Digest Sat, 02 Jul 94 Volume 3 : Issue 41
Today's Topics:
Detecting pre-68020 CPU for 68020 code
Fast Animations (WAS: Fast full screen scrolling: impossible?)
FlattenMovieData bug???
Here's how to get OpenDoc
How to know the cursor is into a polygon?
PowerPC load-store (was Re: Fast full screen scrolling: impossible?)
Q: Default button & Return key in Modeless Dialog
Questions about Tmon?
Saving PICT files - Here's CODE!!
Scroll Bars in DLOG?
Why should't you move baseAddrs?
cntl-opt-esc
scroll bars in modal dialogs
The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
(pottier@clipper.ens.fr).
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 help@anon.penet.fi 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 listserv@ens.fr
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
scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
digest are available there.
Also, the digests are available to WAIS users. To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
-------------------------------------------------------
>From nagle@netcom.com (John Nagle)
Subject: Detecting pre-68020 CPU for 68020 code
Date: Thu, 16 Jun 1994 16:44:14 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Now that Symantec C++ is finally generating 68020 code when asked to
do so (for years, that switch did nothing), it's worth nothing that this
creates a problem in C++.
In C programs, even Think C type programs, the first code executed
is in "main", so it's sufficient to check CPU type there. But in C++,
static constructors run before "main". Now that TCL is starting to use
constructors, and constructors are starting to work right in SC++, it's
more likely that code with a 68020 instruction might be executed before
"main".
It's hard to deal with this in a way that's guaranteed to work
from the user program. The check for 68020 needs to be made in
"CODE 1", the startup code block cranked out by the compiler for every
C++ program. The user can't do this; only Symantec can.
Anybody still care about pre-68020 machines, anyway?
John Nagle
+++++++++++++++++++++++++++
>From jwbaxter@olympus.net (John W. Baxter)
Date: Thu, 16 Jun 1994 19:10:32 -0700
Organization: Internet for the Olympic Peninsula
In article <nagleCrI15q.Kru@netcom.com>, nagle@netcom.com (John Nagle)
wrote:
>
> Anybody still care about pre-68020 machines, anyway?
I don't, and I have two of them (a Plus, and a first 100-days Mac now in
512KE form).
However, there still are some Mac Portable owners around who do. By now,
they must be used to programs which claim to require a 68020 or better
crashing on their machine, but it certainly isn't a nice thing to do to
them.
Do the constructors for the static objects actually *use* any 68020
instructions on a regular basis? [Gestalt is available if you really want
to check in each such constructor...or in a phoney or real object you
arrange to have constructed first.]
--
John Baxter Port Ludlow, WA, USA [West shore, Puget Sound]
No hablo Intel.
jwbaxter@pt.olympus.net
+++++++++++++++++++++++++++
>From nagle@netcom.com (John Nagle)
Date: Fri, 17 Jun 1994 15:39:19 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
jwbaxter@olympus.net (John W. Baxter) writes:
>Do the constructors for the static objects actually *use* any 68020
>instructions on a regular basis? [Gestalt is available if you really want
>to check in each such constructor...or in a phoney or real object you
>arrange to have constructed first.]
If you do any subscript calculations involving 2D arrays or arrays
of structures, you'll probably use the 32-bit multiply on a 68020.
On 68000 machines, a subroutine is called for every 32-bit multiply.
You can't have an object you "arrange to have constructed first".
It's a feature of C++ that order of static constructor execution is
random across file boundaries. ARM 12.6.1.
You can't even call Gestalt from the constructor usefully unless
your class is a base class. Base class constructors get called first,
so if your class is derived from another class, its constructor will be
called only after the base class constructor has already run. It
won't help to override functions in the base class, either; the base class
versions will be called when the base class constructor is called.
So there really isn't a sound way to do this.
John Nagle
John Nagle
---------------------------
>From cfranz@home.malg.imp.com (Christian Franz)
Subject: Fast Animations (WAS: Fast full screen scrolling: impossible?)
Date: Thu, 16 Jun 1994 09:14:27 GMT
Organization: Union Bank of Switzerland, CH
In article <1994Jun13.212936.24879@dal1>, seanmcd@ac.dal.ca wrote:
>
> In article <CrCFxp.79K@park.uvsc.edu>, stay@park.uvsc.edu (Steve Taylor) writes:
> > From article <1994Jun12.232257.24853@dal1>, by seanmcd@ac.dal.ca:
> >> I think Chuck Yeager's Air Combat does this too. You can see interlacing
> >> in the terrain if you rock the plane back and forth.
> >>
> >> Sean
> >
> > Could someone describe this technique in more detail? Are you talking
> > about leaving the other lines there and blitting the other half or
> > are you talking about doubling the height of the lines or what?
> > Thanks.
> >
> Well the description given above makes AstroChase 3D sound like CYAC,
> although the only thing I've seen in AstroChase 3D is the venetian blind
> style, rendering the frame onto every other line. Deliverance also has the
> option to do this, as does a game called Gate. It looks to me like CYAC
> does interlacing, i.e., there are no black lines alternating with the
> graphics, but if you rock the plane
> or turn rapidly, you can see the interlacing effect fairly easy in large
> polygons.
I'm currently developing a 3D space game and of course, I have the same
problems. I have tried many things, among them the alternate line modes
used by Astrochase (draw every other line) and CYAC (draw even lines on
even frames, odd lines on odd frames).
All these algorithms make one main assumption:
You draw the image in an off-screen buffer and after you are done drawing
it, you blast the image to screen. It usually takes three steps:
1. erase offscreen buffer
2. draw new frame offscreen
3. blast offscreen image on-screen.
Tuning step 3 can speed up your program, but usually only by 1/6 max
(optimized blitting is usually one third of the time per frame and I
assume you double the speed of blitting by halving the lines to copy).
I have found out that there is a much better method (however, I doubt
if this technique can be applied to moving backgrounds as is the
main title of this thread). Actually I didn't find out myself but
Juri Munkki, Mac Animations Guru DeLuxe, did. Since my program uses
polygon-oriented graphics, you collect all your polygons as if you
would draw them. Then you compare them with all polygons drawn in
the last frame and output *the*difference* to screen. This eliminates
the need to erase your offscreen map and since two successive frames
are usually similar to each other, you just draw a fraction of what
you usually do. Although the overhead for collecting the polygons
is probably a bit more than drawing them, the subsequent elimination
of 90% that needs to be redrawn makes up for this. Also, if you just
output the difference, this eliminates the need to as this is included
into the algorithm.
Mhhh. On second thought, this doesn't work at all for a scrolling
background... But then, neither CYAC nor AC3D have moving background.
> I don't know enough about 3D graphics to know whether you could
> actually render even/odd scanlines or whether he's just splitting an
> off-screen drawing into two blits.
Well, I have some experience with 3D graphics and there are to
fundamental different approaches. On is called object-space, the
other scan-space (well, at least in german. They seem to translate
badly). In object space you calculate all surfaces of the objects
and project them on your (off)screen using normal projection methods.
To tune your animation you use object coherencies (you take
advantage of the fact that an object doesn't change much between
two frames). In this algorithm you can't render only for odd lines.
You have to render the whole scene and then transfer every other
line.
In scan space you take the inverted approach. For each pixel you
decide which surface is frontmost and set this pixel to the
appropriate color/texture. To tune this algorithm you can use
scan-line coherencies (the fact that two pixels in any direction
usually don't change much in color, both in x and y direction).
With scan-space, you *can* render every other line directly.
The third possibility is a combination of both methods. It's what
Juri's program does (as I suspect. I havn't seen a single line of
his code, but the performance of the demos he sent me leave no
other explanation). You use object space to pre-calculate all
objects (i.e. all vertices that define your surfaces), collect
them to polygons that are not drawn but *mathematically* compared
to the last frame, collect the difference to other polygons and
finally draw the new polygons (using scan coherencies). You
can draw directly to screen since you change so few things that
it seems instantaneous. Juri claims that his algorithm is a
bit faster than the one used in FA-18 (I think they use
a similar approach) and quite frankly, I believe every word
of it.
>
> Sean
OK, sorry to have held you up with this rather lengthy discussion
of some arcane and irrelevant topic, but I have spent a lot of
time investigating this and maybe someone can make some use out
of it. Have a nice day.
Cheers,
Christian
- -
Christian Franz * Union Bank of Switzerland, CH
cfranz@home.malg.imp.com <- at home -> +41-1-261 26 96
---------------------------
>From Frank Manshande <frankm@and.nl>
Subject: FlattenMovieData bug???
Date: Mon, 13 Jun 1994 14:47:53 GMT
Organization: AND Software BV
Hi,
According to the Q/A in Develop 16 (page 130)...
"Since FlattenMovieData" will simply append to a data fork of
a file, you can pass it any data file and it will append the
movie data to that file. Quicktime doesn't care what's stored
before or after the movie data, as long as you don't reposition
the movie data within the data dile."
Well, if I try this, and append a movie using FlattenMovieData",
the first 8 bytes will be overwritten with 4 bytes and then 'mdat'.
Even if I pass the flag 'flattenAddMovieToDataFork' !
It seems like this is a bug! I don't want that data stored before
the movie overwritten. My solution now is to read the first 8
bytes, then FlattenMovieData one or more quicktimes movie files
and then restore the first 8 bytes. But I am not certain that
replacing those 8 bytes won't have any side effects. What I do
is store the "Movie" structure, using PutMovieIntoDataFork at
a specific offset.
My datafile looks like this:
- -------------------------------
| some data (other than movies) |
- -------------------------------
| flattened movie |
- -------------------------------
| "Movie" structure |
- -------------------------------
| flattened movie |
- -------------------------------
| "Movie" structure |
- -------------------------------
| flattened movie |
- -------------------------------
| "Movie" structure |
- -------------------------------
This works. But the first 8 bytes are overwritten in "some data".
Any info would be very much appreciated!
Frank Manshande
frankm@and.nl
+++++++++++++++++++++++++++
>From ivanski@world.std.com (Ivan M CaveroBelaunde)
Date: Mon, 13 Jun 1994 18:05:25 GMT
Organization: The World Public Access UNIX, Brookline, MA
Frank Manshande <frankm@and.nl> writes:
>This works. But the first 8 bytes are overwritten in "some data".
What happens is that QT stores the info in a Bento-like atomic form. The
single-fork movie (flattened means "self-contained", not "single-fork").
must contain "atoms" in order for QT to properly navigate it. Atoms are
structured as follows:
{
long atomSize; // includes atomSize+atomType
OSType atomType;
... atom specific data ...
}
So for your multimovie file to work it needs to contain atom headers
before each movie data atom of the right size. It also needs an
atom header in front of your data to allow QT to traverse the movie.
This isn't a bug AFAIK; it seems Develop 16 was wrong in the general
case (you can't just append the movie data for single fork files). If
you control the file format, however, and you can add the atom header
yourself, then it is feasible to do what they say. Given this structure,
however, I'd avoid "restoring" the first 8 bytes as you were doing,
since it's bound to affect your ability to access the multiple movies...
Additionally, you might want to check out John Wang's article
in Develop 17 ("Somewhere in QuickTime"), since I seem to remember
there is a bug in FlattenMovieData in which the size field is not
properly set when using multiple movies, and a fix (BetterFlattenMovieData)
is discussed in it.
Hope this helps,
-Ivan
- -
Ivan Cavero Belaunde (ivanski@world.std.com)
Avid VideoShop Project Lead
Avid Technology, Inc.
+++++++++++++++++++++++++++
>From Frank Manshande <frankm@and.nl>
Date: Tue, 14 Jun 1994 06:51:11 GMT
Organization: AND Software BV
In article <CrCKx2.952@world.std.com> Ivan M CaveroBelaunde,
ivanski@world.std.com writes:
>If you control the file format, however, and you can add the atom header
>yourself, then it is feasible to do what they say. Given this structure,
>however, I'd avoid "restoring" the first 8 bytes as you were doing,
>since it's bound to affect your ability to access the multiple movies...
Well,
First of all thanks for your time!
I have written two small programs. One that adds a movie to ANY kind
of file, and displays the offset of the 'movie resource' using the
PutMovieIntoDataFork call. And another program that can play the movies
at the specified offsets. This does seem to work correctly.
The only side-effect I have encountered so far is that the file which
I added the movies to cannot be played by SimplePlayer. SimplePlayer
can play the first movie if I don't save and restore the first 8 bytes
of the file. But because I don't want to play the movies using a
general movie player, but only from my own program, this should not
be a problem.
The reason I have to restore the first 8 bytes of the file is that
the quicktime movies are added to a specific database file (the database
file is of proprietary format), and the database engine doesn't work
if the first 8 bytes are overwritten.
The reason why I don't just create two seperate files (one with the
database and one with all the quicktime movies) is that our customers
(and our company) only wants ONE file, which contains all the data.
Does anybody know if saving and restoring the first 8 bytes that
FlattenMovieData overwrites has any other side effects then not
allowing programs such as SimplePlayer to play a movie?
Thanks!
Frank Manshande
frankm@and.nl
+++++++++++++++++++++++++++
>From Peter Vanags <peterv@uclink.berkeley.edu>
Date: 15 Jun 1994 20:43:47 GMT
Organization: UCB
In article <CrDKDC.30H@and.nl> Frank Manshande, frankm@and.nl writes:
>Does anybody know if saving and restoring the first 8 bytes that
>FlattenMovieData overwrites has any other side effects then not
>allowing programs such as SimplePlayer to play a movie?
Nope, not a problem. The only caveat is you MUST use
NewMoveFromDataFork() with the offset to the 'mdat' or 'moov' atom to
retrieve the movie, if the other data in the data fork is not stored in
"atom" form.
To be clean about using FlattenMovieData(), you should use the following
procedure:
- store the first 8 bytes of the data fork
- store the file's length
- append a dummy 'mdat' atom to the end of the data fork
- call FlattenMovieData()
- check the offset to the end of the movie data, which is now
in the first 4 bytes of the data fork, compare to the length
before FlattenMovieData() was called
and update your dummy atom
- restore the first 8 bytes of the file's data fork
I talked with John Wang at MacDTS (author of the "Somewhere in QuickTime"
column in develop) quite a bit about this issue right before he published
the article.
Peter Vanags
peterv@uclink.berkeley.edu
+++++++++++++++++++++++++++
>From jywang@apple.com (John Wang)
Date: 16 Jun 1994 00:27:12 GMT
Organization: Apple Computer, Inc.
FYI. The bug fix for the problem described in issue #17 of my article has
been added to QuickTime 2.0. If you use my BetterFlattenMovie or
BetterFlattenMovieData routine, you will be all set since
BetterFlattenMovie only patches FlattenMovie when QuickTime 1.6.X or
earlier is used.
John
---------------------------
>From Jens Alfke <jens_alfke@powertalk.apple.com>
Subject: Here's how to get OpenDoc
Date: Wed, 15 Jun 1994 23:30:31 GMT
Organization: Apple Computer
I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas,
to get the true facts about OpenDoc seeding. Here's the scoop.
* The current (a6) version of OpenDoc is _not_ going to be distributed more
widely than to the WWDC attendees. They decided against a blanket mailing to
all registered developers because, as Mark put it, "You only get one chance
to make a good first impression". The a6 build is still a bit flaky, requires
MPW, and doesn't come with much in the way of documentation. Their fear was
that, if everybody got it, many would play with it a little, run into
problems, and not look at it again later when things are more polished.
* The beta seed _is_ going to be distributed widely. It'll be on the
developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get
a number of OpenDoc articles in that issue of 'develop'. (Note that anyone
can order single issues of 'develop' from APDA for $10.) This will probably
be in September given the lead time involved in pressing CDs. By that time
the code will be more stable, you'll be able to build with CodeWarrior (hope
hope hope), and there will be at least draft versions of the official
documentation for both OpenDoc and the framework.
* But! If you're interested in getting started with OpenDoc _now_ (and how
can I blame you?) you can send mail to OpenDoc@applelink.apple.com and get a
CD with version a6 in return for filling out a short form.
* Feel free to post OpenDoc questions here; I'll try to answer them. There is
an OpenDoc mailing list; send mail to <majordomo@cil.org> with body
"subscribe opendoc-interest" to subscribe. There is also a discussion board
on AppleLink somewhere.
I hope this answers your questions. Sorry about any misinformation I've
posted in the past ...
--Jens Alfke
jens_alfke@powertalk Rebel girl, rebel girl,
.apple.com Rebel girl you are the queen of my world
+++++++++++++++++++++++++++
>From chuck@molecule.Physics.Drexel.Edu (Chuck Browne)
Date: Thu, 16 Jun 1994 16:35:00 GMT
Organization: Drexel University
Jens Alfke (jens_alfke@powertalk.apple.com) wrote:
: I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas,
: to get the true facts about OpenDoc seeding. Here's the scoop.
: * The beta seed _is_ going to be distributed widely. It'll be on the
: developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get
Thanks, Jens
Is there any problem with lending it to Metrowerks for shipping on the
DR4 CD, which roughly comes out at the same time?
(Not that I'm trying to save a couple of bucks or anything... :-) )
Chuck
+++++++++++++++++++++++++++
>From Jens Alfke <jens_alfke@powertalk.apple.com>
Date: Thu, 16 Jun 1994 22:55:44 GMT
Organization: Apple Computer
Chuck Browne, chuck@molecule.Physics.Drexel.Edu writes:
> Is there any problem with lending it to Metrowerks for shipping on the
> DR4 CD, which roughly comes out at the same time?
I think Mark wants people to go directly to Apple to obtain it. He wants to
keep tabs on how many people have it and who they are (in case we need to
send out any mass mailings, or sell your names and addresses to The Sharper
Image :)
> (Not that I'm trying to save a couple of bucks or anything... :-) )
I don't think we're charging anything for the OpenDoc seed.
--Jens Alfke
jens_alfke@powertalk Rebel girl, rebel girl,
.apple.com Rebel girl you are the queen of my world
+++++++++++++++++++++++++++
>From chuck@molecule.Physics.Drexel.Edu (Chuck Browne)
Date: Fri, 17 Jun 1994 00:58:43 GMT
Organization: Drexel University
Jens Alfke (jens_alfke@powertalk.apple.com) wrote:
: Chuck Browne, chuck@molecule.Physics.Drexel.Edu writes:
: > Is there any problem with lending it to Metrowerks for shipping on the
: > DR4 CD, which roughly comes out at the same time?
: I think Mark wants people to go directly to Apple to obtain it. He wants to
: keep tabs on how many people have it and who they are (in case we need to
: send out any mass mailings, or sell your names and addresses to The Sharper
: Image :)
: > (Not that I'm trying to save a couple of bucks or anything... :-) )
: I don't think we're charging anything for the OpenDoc seed.
I meant the $10 for develop, but what you say is good to hear.
(Not that I need OpenDoc or anything, I'm just curious about it and
what it will mean to software in the next couple of years...
maybe I'll try it out, if I manage to get my PhD on schedule..)
Thanks,
Chuck
: --Jens Alfke
: jens_alfke@powertalk Rebel girl, rebel girl,
: .apple.com Rebel girl you are the queen of my world
---------------------------
>From belanger@bach.ulaval.ca (Yves Belanger)
Subject: How to know the cursor is into a polygon?
Date: Tue, 14 Jun 1994 18:09:32 GMT
Organization: Universite Laval, Ste-Foy (Quebec), Canada
Hello,
I am writing an application where districts are drawn on a geographic
map. Districts are made with many points, like a polygon in MacDraw.
Each point is given a longitude and a latitude. I have functions that
translate back and forth these coordinates into screen coordinates.
My problem is how to determine that a user has clicked inside one of
those polygon or the click was outside them all? If the solution could
work with longitude and latitude, that would be greater, since less
computing would be involved. Thank you.
S. Beaudry
+++++++++++++++++++++++++++
>From Mark Hanrek <hanrek@cts.com>
Date: Tue, 14 Jun 1994 22:49:07 GMT
Organization: The Information Workshop
In article <CrEFrx.LDq@athena.ulaval.ca> Yves Belanger,
belanger@bach.ulaval.ca writes:
> I am writing an application where districts are drawn on a geographic
> map. Districts are made with many points, like a polygon in MacDraw.
> Each point is given a longitude and a latitude. I have functions that
> translate back and forth these coordinates into screen coordinates.
The most common approach is to take advantage of the Macintosh's built-in
region capabilities. They are incredibly powerful, and very easy to use.
You can easily take any polygon and create the equivalent region from it,
which is kept in a RegionHandle.
Keep a list of these RegionHandles handy, one for each district, and when
the user clicks, take the location of the click and then in a loop use
the PtInRgn() toolbox call to test whether that point is within each of
the regions. When the result is true, bingo.
If there are overlapping regions, be sure they are set up and tested in
front to back order.
That's all there is to it, unless I misunderstood your situation.
I forget the exact calls to make a region from a polygon, but the whole
process is exceedingly simple.
This is the only approach I know of, really.
Mark Hanrek
+++++++++++++++++++++++++++
>From jwbaxter@olympus.net (John W. Baxter)
Date: Tue, 14 Jun 1994 21:09:23 -0700
Organization: Internet for the Olympic Peninsula
In article <CrEFrx.LDq@athena.ulaval.ca>, belanger@bach.ulaval.ca (Yves
Belanger) wrote:
> Hello,
>
> I am writing an application where districts are drawn on a geographic
> map. Districts are made with many points, like a polygon in MacDraw.
> Each point is given a longitude and a latitude. I have functions that
> translate back and forth these coordinates into screen coordinates.
>
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all? If the solution could
> work with longitude and latitude, that would be greater, since less
> computing would be involved. Thank you.
My approach would be based on creating a QD region which covers the same
"territory" as the polygon, and using the provided PtInRgn call against the
region. Only if that were not "fast enough" would I probe further.
Or...better...switch to QuickDraw GX, where you're likely to be working
with a polygon shape, and you can easily hit-test that (or any other
shape). That may put things a little more into the future than you want,
though.
--
John Baxter Port Ludlow, WA, USA [West shore, Puget Sound]
No hablo Intel.
jwbaxter@pt.olympus.net
+++++++++++++++++++++++++++
>From Jens Alfke <jens_alfke@powertalk.apple.com>
Date: Wed, 15 Jun 1994 22:21:34 GMT
Organization: Apple Computer
In article <CrEFrx.LDq@athena.ulaval.ca> Yves Belanger,
belanger@bach.ulaval.ca writes:
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all?
As has been said, the easiest solution is to create a region of the same
shape as the polygon, then call PtInRegion. This does have the drawback that
regions containing diagonal lines eat up lots of memory. (Think of the
boundary of the region as a polygon, including little stairsteps at pixel
edges on diagonal lines. The region then occupies about two to four bytes per
vertex of that polygon.) Unfortunately, regions larger than 64kbytes will
crash QuickDraw. This shouldn't be a problem unless your polygons are very
large or complex.
To create a region from a polygon:
* Call OpenRgn
* MoveTo the first point in the polygon, LineTo each succeeding point. Make
sure to end with a LineTo back to the first point.
* Call CloseRgn.
Your other alternative is to use a real "point in polygon" test. You could
either be the four millionth person this month to ask about this on
comp.graphics.algorithms, or you could get a standard computer graphics
textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam
et al. There may also be source code available by ftp, but I have no idea
where.
--Jens Alfke
jens_alfke@powertalk Rebel girl, rebel girl,
.apple.com Rebel girl you are the queen of my world
+++++++++++++++++++++++++++
>From mxmora@unix.sri.com (Matt Mora)
Date: 16 Jun 1994 09:28:11 -0700
Organization: SRI International, Menlo Park, CA
In article <1994Jun15.222134.21946@gallant.apple.com> Jens Alfke <jens_alfke@powertalk.apple.com> writes:
>In article <CrEFrx.LDq@athena.ulaval.ca> Yves Belanger,
>belanger@bach.ulaval.ca writes:
>> My problem is how to determine that a user has clicked inside one of
>> those polygon or the click was outside them all?
>
>As has been said, the easiest solution is to create a region of the same
>shape as the polygon, then call PtInRegion. This does have the drawback that
>regions containing diagonal lines eat up lots of memory. (Think of the
>boundary of the region as a polygon, including little stairsteps at pixel
>edges on diagonal lines. The region then occupies about two to four bytes per
>vertex of that polygon.) Unfortunately, regions larger than 64kbytes will
>crash QuickDraw. This shouldn't be a problem unless your polygons are very
>large or complex.
>
>To create a region from a polygon:
>* Call OpenRgn
>* MoveTo the first point in the polygon, LineTo each succeeding point. Make
>sure to end with a LineTo back to the first point.
>* Call CloseRgn.
>
>Your other alternative is to use a real "point in polygon" test. You could
>either be the four millionth person this month to ask about this on
>comp.graphics.algorithms, or you could get a standard computer graphics
>textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam
>et al. There may also be source code available by ftp, but I have no idea
>where.
>From the UMPG Vol II
Subject: Re: Point in Polygon routine needed
From: fry@zariski.harvard.edu (David Fry)
In article <8fxkxAO00WB7M=nOFO@andrew.cmu.edu> Andrew Lewis Tepper <at15+@andrew.cmu.edu> writes:
>I don't know if this routine is "standard", I just came up with it recently:
>
>For a polygon of points p1...pn, and a point P, make a table as follows:
>
>T(1)= angle from p1 to P to p2
>T(2)= angle from p2 to P to p3
>...
>T(n)= angle from pn to P to p1
>
>express all angles as: -PI < angle < PI.
>
>Add all entries in the table. If the sum = 0, the point is outside. If
>the sum is +/- PI, the point is inside. If the point is +/- xPI, you
>have a strange polygon. If ANY angle was = +/-PI, the point is on the
>border.
>
>Does anyone know if this is considered a good (known?) algorithm? It
>took a long time to come up with!
You have the essence of the "good," standard algorithm, but if you're
working with thousands of polygons, those floating point calculations
will be too slow and will probably lead to round-off error at some
point. Round-off error is a huge pain in computational geometry
problems. The hard part is finding ways to avoid it.
The trick is that you don't need to know the angle between the lines,
you just need to know its sign, called the *circulation*. For every
line AB in the polygon, form the triangle PAB and you want to know
does it lie inside the polygon or not. That is, if you were riding a
bike counterclockwise around the boundary of the polygon, would P
lie on your left or your right when you crossed AB? You can find this
by calculating PA x PB = (A.x-P.x)*(B.y-P.y) - (A.y-P.y)*(B.x-P.x).
The circulation (the sign of PA x PB) can be found without doing a
multiplication in many cases, but this is good enough. Remember,
we've oriented the polygon so that you come to A before coming to B as
your traverse its boundary.
Then the algorithm is:
In = 0
foreach edge AB in the polygon
if A.y < P.y and B.y >= P.y and PA x PB > 0
In = In + 1
if A.y >= P.y and B.y < P.y and PA x PB < 0
In = In - 1
Then if In = 1, P is inside the polygon, and is outside if I = 0.
This doesn't handle the case where P lies on some edge AB of the
polygon.
David Fry fry@math.harvard.edu
Division of Applied Sciences fry@huma1.bitnet
Harvard University ...!harvard!huma1!fry
Cambridge, MA 02138
- ----------
end of artile
Xavier
--
___________________________________________________________
Matthew Xavier Mora Matt_Mora@sri.com
SRI International mxmora@unix.sri.com
333 Ravenswood Ave Menlo Park, CA. 94025
+++++++++++++++++++++++++++
>From Rick Wong <rick@jessica.stanford.edu>
Date: 16 Jun 1994 17:59:54 GMT
Organization: Stanford University
In article <CrEFrx.LDq@athena.ulaval.ca> Yves Belanger,
belanger@bach.ulaval.ca writes:
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all?
One approach is to create an offscreen bitmap with its origin set
up so that the bitmap is centered around the click locaction. The
bitmap doesn't have to be very big at all, just enough for your hit
tolerance. For each polygon you want to test, clear the bitmap,
then draw the polygon into it (if you want to see if the point is
inside the polygon, you should draw it with a black fill pattern).
You can then examine the individual bits around the click location
to see if any are set.
Of course, such "cleverness" is unnecessary under QuickDraw GX....
--Rick Wong
---------------------------
>From platypus@cirrus.som.cwru.edu (Gary Kacmarcik)
Subject: PowerPC load-store (was Re: Fast full screen scrolling: impossible?)
Date: 15 Jun 1994 15:23:53 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
In article <1994Jun12.182803.1@west.cscwc.pima.edu> 103t_english@west.cscwc.pima.edu writes:
> And finally, what happened to the load/store multiple instructions that are
> (I assume?) faster on the 601, but will probably be slower "in future
> implementations?"
the load/store multiple instructions are not faster than a series of loads
and stores (except perhaps if there are stalls from the instruction cache).
they take 1 cycle per load or store.
these instructions are present to make saving and restoring registers
(GPRs only) to the stack a little bit easier. that's really the only benefit
to them.
many of the PowerPC architects do not like these instructions because they
do not fit the RISC model very well, thus they complicate the processor
implementation. don't expect IBM/Motorola to invest much time on these
instructions. witness the lack of equivalent instructions for floating-
point registers or for 64-bit GPRs.
these instructions will become slower when they decide to eliminate them
and handle them via trap-and-emulate. (hey, at least they're telling you
all this up front)
-gary j kacmarcik
platypus@cirrus.som.cwru.edu
+++++++++++++++++++++++++++
>From zstern@adobe.com (Zalman Stern)
Date: Wed, 15 Jun 1994 20:34:44 GMT
Organization: Adobe Systems Incorporated
Gary Kacmarcik writes
> the load/store multiple instructions are not faster than a series of loads
> and stores (except perhaps if there are stalls from the instruction
cache).
> they take 1 cycle per load or store.
Which will happen relatively often on the 601. (For example anytime you save
8 or more registers, its guaranteed to happen.)
> these instructions are present to make saving and restoring registers
> (GPRs only) to the stack a little bit easier. that's really the only
benefit
> to them.
They improve code density somewhat. Given the size of native apps that's a
concern.
> many of the PowerPC architects do not like these instructions because they
> do not fit the RISC model very well, thus they complicate the processor
> implementation. don't expect IBM/Motorola to invest much time on these
> instructions. witness the lack of equivalent instructions for floating-
> point registers or for 64-bit GPRs.
Bottom line: the architecture would be better without load/store multiple.
However since the architects could not reach agreement to remove these
instructions, the implementors should support them. As it stands now, some
implementors will makes these instructions competitive and some won't.
Applications developers will be stuck with a choice which way to go. For
load/store multiple, this doesn't bother me that much. (One might take a
minor speed hit to win on code space most places anyway.) However the manual
says similar things about load/store update instructions vs. using a
load/store and an add instruction. This causes a much bigger performance
tradeoff right in the middle of your inner loops. A PowerPC implementation
where the two instruction sequence is faster than an update form instruction
would be braindead.
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
`Wait a second! This is just an octahedron suspended in blue liquid.' - JT
+++++++++++++++++++++++++++
>From platypus@cirrus.som.cwru.edu (Gary Kacmarcik)
Date: 16 Jun 1994 18:34:53 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
In article <1994Jun15.203444.3373@adobe.com> zstern@adobe.com (Zalman Stern) writes:
>
> Gary Kacmarcik writes
> > these instructions are present to make saving and restoring registers
> > (GPRs only) to the stack a little bit easier. that's really the only
> > benefit to them.
>
> They improve code density somewhat. Given the size of native apps that's a
> concern.
but they don't affect code density all that much. the recommended way
doing the load/store sequence of instructions is to have a series of
loads (or stores) somewhere in the app or OS like
lwz r13,0(r0)
lwz r14,4(r0)
...
lwz r31,68(r0)
bcctr
(or something like that - i believe that the standard save/restore glue
does a few other things, but i don't have the exact sequence handy).
then a function that wants to save a bunch of registers just calculates
the address of where the first register should be saved and branches to
appropriate lwz instruction. you have to do this anyway for floating-
point and 64-bit reg's, so it's not a big deal.
the end result is that if it's done this way, it won't have a big impact
on code density. performance is basically to same too, since the branches
(both of which are unconditional) are "free" and the glue code may
already be in the i-cache (from previous functions).
-gary j kacmarcik
platypus@cirrus.som.cwru.edu
+++++++++++++++++++++++++++
>From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
Date: Fri, 17 Jun 1994 04:23:38 +1200 (NZST)
Organization: (none)
platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
> many of the PowerPC architects do not like these instructions because they
> do not fit the RISC model very well, thus they complicate the processor
> implementation. don't expect IBM/Motorola to invest much time on these
> instructions. witness the lack of equivalent instructions for floating-
> point registers or for 64-bit GPRs.
>
> these instructions will become slower when they decide to eliminate them
> and handle them via trap-and-emulate. (hey, at least they're telling you
> all this up front)
That won't be too bad -- everyone sees it coming, and coming (fairly) soon,
and if you're saving a number of registers the speed hit won't be *that*
horrible (but horrible enough), and most people don't use it inside of
tight loops, and it's no faster than the alternative anyway.
The really, *really* horrible one will come when the "load with update"
and "store with update" instructions get the trap-and-emulate treatment.
For the non PPC-savvy folk, those instructions get used to implement
the C constructs *++p and *--p (and *p++ and *p-- with a smart optomising
compiler that can transform your code).
They're used a *lot*, they're a big speed win on the 601 (less on the
603 and 604 if you don't mind tying up two units for a load and an addi
in parallel becasue you've got nothing better to do with them), and they
occur in speed-critical inner loops.
-- Bruce
---------------------------
>From efisch@cs.tamu.edu (Eric A Fisch)
Subject: Q: Default button & Return key in Modeless Dialog
Date: 16 Jun 1994 18:56:00 GMT
Organization: Texas A&M Computer Science Department, College Station, TX
I am working with modeless dialogs and am quite pleased with the
results. I am having a problem defining a default button and making
the return (or enter) key activate it. Right now, when the return key
is pressed it is passed into the active editable text field. I do have
the OK button at item number 1, but I am clearly missing something. Any
thoughts?
Thanks,
Eric Fisch
efisch@cs.tamu.edu
+++++++++++++++++++++++++++
>From egurney@vcd.hp.com (Eddy J. Gurney)
Date: Thu, 16 Jun 1994 20:01:29 GMT
Organization: Hewlett-Packard VCD
Eric A Fisch (efisch@cs.tamu.edu) wrote:
>I am working with modeless dialogs and am quite pleased with the
>results. I am having a problem defining a default button and making
>the return (or enter) key activate it. Right now, when the return key
>is pressed it is passed into the active editable text field. I do have
>the OK button at item number 1, but I am clearly missing something. Any
>thoughts?
Yes. After calling IsDialogEvent() from your event loop and determining
that this is an event for an open modeless dialog, you need to
"pre-process" the event before passing it on to DialogSelect() and check
for a "keyDown" or "autoKey" event when theEvent.message & charCodeMask
is equal to the Enter or Return key and process it appropriately... being
sure to NOT pass the event on to DialogSelect() afterwards.
You need to do a similar thing anyway to catch Command-key equivalents,
which DialogSelect() also just "pushes" through to TEKey...
--
Eddy J. Gurney N8FPW Hewlett-Packard Company, Vancouver (USA!) Division
egurney@vcd.hp.com #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
and those who did and never thought." John Charles Salak
+++++++++++++++++++++++++++
>From dubois@primate.wisc.edu (Paul DuBois)
Date: 16 Jun 1994 15:46:39 -0500
Organization: Castra Parvulorum
>From article <2tq780$3i8@news.tamu.edu>, by efisch@cs.tamu.edu (Eric A Fisch):
> I am working with modeless dialogs and am quite pleased with the
> results. I am having a problem defining a default button and making
> the return (or enter) key activate it. Right now, when the return key
> is pressed it is passed into the active editable text field. I do have
> the OK button at item number 1, but I am clearly missing something. Any
> thoughts?
You have to handle it yourself in a modeless dialog.
--
Paul DuBois
dubois@primate.wisc.edu
---------------------------
>From apabla@hercules.cs.uregina.ca (jaime apablaza)
Subject: Questions about Tmon?
Date: Wed, 01 Jun 1994 03:19:37 GMT
Organization: University of Regina
How much does Tmon Pro cost and where can I order it from? I read in the
faq that Tmon has a rather steep learning curve so I was wondering is
that because the manual is rather cryptic. If so are there third party
books on using Tmon? Email preferred.
+++++++++++++++++++++++++++
>From hall_j@sat.mot.com (Joseph Hall)
Date: Wed, 1 Jun 1994 05:42:03 GMT
Organization: Motorola Inc., Satellite Communications
Seems it was apabla@hercules.cs.uregina.ca (jaime apablaza) who said:
>How much does Tmon Pro cost and where can I order it from? I read in the
>faq that Tmon has a rather steep learning curve so I was wondering is
>that because the manual is rather cryptic. If so are there third party
>books on using Tmon? Email preferred.
I'm not aware of any books on TMON (other than the fairly good documentation
that comes with it), but at least TMON seems to have a future now. For a
while it looked as if it had been dropped on the floor and left for dead.
The current trend is STRONGLY toward Jasik's The Debugger, though.
Obviously there is no TMON for PowerPC at this time.
--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home)
(on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com
+++++++++++++++++++++++++++
>From chewy@shell.portal.com (Paul F. Snively)
Date: 1 Jun 1994 14:26:07 GMT
Organization: tumbolia.com
In article <1994Jun01.031937.138522@sue.cc.uregina.ca>
apabla@hercules.cs.uregina.ca (jaime apablaza) writes:
> How much does Tmon Pro cost and where can I order it from? I read in the
> faq that Tmon has a rather steep learning curve so I was wondering is
> that because the manual is rather cryptic. If so are there third party
> books on using Tmon? Email preferred.
I would mail, but others might want to read this, too...
TMON Pro does have a significant learning curve, as does probably any
reasonably capable object-level debugger on the Mac. The Mac is a
complex beast itself; to create a debugger that can interact with
heaps, resources, code, registers, etc. is difficult (says a guy who
used to work at ICOM Simulations, Inc.)
Having said that, here are my brief pointers for happiness in TMON Pro:
1) Whenever you have a TMON Pro window open, note the little square box
in
the upper right corner. It looks like a zoom box, and in a sense,
it is:
it will expand the window to show a variety of hidden (ugh) options
for
use in that window.
2) Learn--and I mean _really_ learn--TMON Pro's expression syntax.
Easily
90% of the cool things that you can do with TMON involve non-trivial
use
of expressions. For example, TMON Pro's "Stack Crawl" window is
just a
Memory window with a moderately hairy expression used to crawl up
the
stack. There's an even hairier expression used to create a Memory
window
that gives the names of all of the windows in the current world
(hairy to
do because the titleHandle is at different offsets in b&w vs. color
windows). In particular, make sure that you fully understand
delayed vs.
immediate evaluation.
3) Remember that TMON Pro does, in fact, have a command line.
Command-space
will open it. You may think, "but I hate command lines!" So do I,
but
it's the only way to do certain things in TMON Pro, e.g. type: