From: owner-csmp@ee.mcgill.ca
Subject: csmp digest Vol 4 No 045



C.S.M.P. Digest             Mon, 24 Nov 97       Volume 4 : Issue 45
 
Today's Topics:
 
        3D collision...
        AIFF sound files
        Dialog picture item opcodes for single gray line
        Fast font and screen blitters...
        PPC assembler?
        Q: timing issues with Sound Manager
        Quickdraw fast with regions?
        Shutting Down the Comp.?
        Updated toolbox references
        Which books for 3D programming & 3d maths



The Comp.Sys.Mac.Programmer Digest is moderated by Mark Aiken
(marka@ee.mcgill.ca).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news 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
ee.mcgill.ca).  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 digests can be obtained by email, ftp or through the World Wide Web.

If you want to receive the digest by mail, send email to 
majordomo@ee.mcgill.ca with no subject and one of the following commands
as body:

    help		                Sends you a summary of commands
    subscribe csmp                      Adds you to the mailing list
    unsubscribe csmp                    Removes you from the list

Once you have subscribed, you will automatically receive each new
issue as it is created.

Back issues are available by ftp from Info-Mac mirror sites in the
per/csmp subdirectory, e.g.

  ftp://sumex-aim.stanford.edu/info-mac/per/csmp/

The contents of all back issues can be searched by accessing the
following URL, courtesy of Andrew Barry (ajbarry@ozemail.com.au):

    http://marvin.stattech.com.au/search.html

They can also be searched through the following URLs, thanks to
Tim Tuck (Tim.Tuck@sensei.com.au):

    http://wais.sensei.com.au/searchform.html
    wais://wais.sensei.com.au:210/csmp?

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

>From nagilum@mindspring.com (Nagilum)
Subject: 3D collision...
Date: Fri, 24 Oct 1997 07:40:08 -0800
Organization: Fission

   I am making a 3D game, similar in many ways to quake. I need to do
collision, but I don't have any idea how I should do it. I want to be albe
to impliment fairly realistic phyisics, so the method would have to be
able to acomidate things like a spike stiking out of the wall (of course
also it has to support slanted walls, as this game will have very complex
arcitexture). I already have a way of dealing with groud, I only need a
way to make walls, any size or shape, collide with other things (players,
monsters, rockets...). Does anyone have any idea of how Quake or Duke does
collision? PLEASE HELP ME! Thanks.

-- 
- ---------------------------------
   James Marr
      nagilum@mindspring.com
- ---------------------------------
I think, therefore I use a Mac.

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

>From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne)
Date: Sat, 25 Oct 1997 21:21:50 +0800
Organization: Hong Kong Supernet

In article <nagilum-2410970740090001@ip228.meford.or.pub-ip.psi.net>,
nagilum@mindspring.com (Nagilum) wrote:

:   I am making a 3D game, similar in many ways to quake. I need to do
:collision, but I don't have any idea how I should do it. I want to be albe
:to impliment fairly realistic phyisics, so the method would have to be
:able to acomidate things like a spike stiking out of the wall

It depends mostly on how complex your world is. If it's more like
Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal
floors and with solid  objects  (trees, desks, etc) treated as walls you
can do most of your colision detection in 2D, basically storing the 2D map
and testing for collisions in that, then using the 3D info to decide the
result of the 'collision', e.g. you might need to decide whether a player
stops at or steps/jumps onto a wall.

If you really want to ipmlement a Quake type engine you are in for a lot
more work, as Quake has a true 3D world where walls/floors need not be
horizontal or vertical. To keep the processing manageble you will probably
want to treat all players and non-player characters as boxes or cylinders,
i.e. so their complex interior geometry is ignored. Then you just need to
do some 3D math, to see whether the corners or edges or the player might
overlap adacent walls.

In either case you will probably store a list of basic game environment
objects, such as rooms, walls, floors, spikes, trees, desks, etc.,
together with their surfaces. If you make sure you store the global (x, y
and possibly z) location of each object centre you can quickly eliminate
those objects not near a player which you don't need to check against. For
a large map you can reduce checking further by dividing your map into
zones (e.g. rooms or floors) so that if a player is in one zone you only
need to check proximity to and collisions with objects in that room.

And for both 2D and 3D checking you can save time by storing the unit
normal to each wall/floor surface and the result of the scalar product of
this with a point on the wall. If you repeat the calculation again with
another point (the corner or center of the player) the difference between
the results tells you which side of the wall the test point is on and how
far away it is.

As for 'fairly realistic physics', you then want to be able to handle
elastic collisions, where things bounce off walls, changing speed and
direction accordingly. This is pretty straigntforward to do using vector
math once you know the normal to the surface and the velocity vector of
the object colliding with it. For an impressive degree of realism you
could also deal with extended objects properly, allowing objects to start
spinning or change their rate of rotation if hit on one side/at one end.
I've not seen this done in games, so if you manage this it will be fairly
impressive.

John

-- 
John Blackburne; programmer, writer, consultant, trainer
tel/fax: Hong Kong (+852) 2816 7484
home page: <http://www.hk.super.net/~johnb>

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

>From nagilum@mindspring.com (Nagilum)
Date: Sun, 26 Oct 1997 18:51:53 -0800
Organization: Fission

In article <johnb-2510972121500001@max6-60.hk.super.net>,
johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote:

> In article <nagilum-2410970740090001@ip228.meford.or.pub-ip.psi.net>,
> nagilum@mindspring.com (Nagilum) wrote:
> 
> :   I am making a 3D game, similar in many ways to quake. I need to do
> :collision, but I don't have any idea how I should do it. I want to be albe
> :to impliment fairly realistic phyisics, so the method would have to be
> :able to acomidate things like a spike stiking out of the wall
> 
> It depends mostly on how complex your world is. If it's more like
> Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal
> floors and with solid  objects  (trees, desks, etc) treated as walls you
> can do most of your colision detection in 2D, basically storing the 2D map
> and testing for collisions in that, then using the 3D info to decide the
> result of the 'collision', e.g. you might need to decide whether a player
> stops at or steps/jumps onto a wall.
> 
> If you really want to ipmlement a Quake type engine you are in for a lot
> more work, as Quake has a true 3D world where walls/floors need not be
> horizontal or vertical. To keep the processing manageble you will probably
> want to treat all players and non-player characters as boxes or cylinders,
> i.e. so their complex interior geometry is ignored. Then you just need to
> do some 3D math, to see whether the corners or edges or the player might
> overlap adacent walls.
> 
> In either case you will probably store a list of basic game environment
> objects, such as rooms, walls, floors, spikes, trees, desks, etc.,
> together with their surfaces. If you make sure you store the global (x, y
> and possibly z) location of each object centre you can quickly eliminate
> those objects not near a player which you don't need to check against. For
> a large map you can reduce checking further by dividing your map into
> zones (e.g. rooms or floors) so that if a player is in one zone you only
> need to check proximity to and collisions with objects in that room.
> 
> And for both 2D and 3D checking you can save time by storing the unit
> normal to each wall/floor surface and the result of the scalar product of
> this with a point on the wall. If you repeat the calculation again with
> another point (the corner or center of the player) the difference between
> the results tells you which side of the wall the test point is on and how
> far away it is.
> 
> As for 'fairly realistic physics', you then want to be able to handle
> elastic collisions, where things bounce off walls, changing speed and
> direction accordingly. This is pretty straigntforward to do using vector
> math once you know the normal to the surface and the velocity vector of
> the object colliding with it. For an impressive degree of realism you
> could also deal with extended objects properly, allowing objects to start
> spinning or change their rate of rotation if hit on one side/at one end.
> I've not seen this done in games, so if you manage this it will be fairly
> impressive.

thanks! Any idea where I can get some formulas for this (I'm only 16 and
in Advance Algebra 2 (zzzz)).

-- 
- ---------------------------------
   James Marr
      nagilum@mindspring.com
- ---------------------------------
I think, therefore I use a Mac.

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

>From nagilum@mindspring.com (Nagilum)
Date: Thu, 30 Oct 1997 21:55:38 +0800
Organization: Fission

In article <ivolow1-ya023580003110970619420001@news.zippo.com>,
ivolow1@ic3.ithaca.edu (Ilan Volow) wrote:

> In article <nagilum-2610971851540001@ip49.meford.or.pub-ip.psi.net>,
> nagilum@mindspring.com (Nagilum) wrote:
> 
> > In article <johnb-2510972121500001@max6-60.hk.super.net>,
> > johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote:
> > 
> > > In article <nagilum-2410970740090001@ip228.meford.or.pub-ip.psi.net>,
> > > nagilum@mindspring.com (Nagilum) wrote:
> > > 
> > > :   I am making a 3D game, similar in many ways to quake. I need to do
> > > :collision, but I don't have any idea how I should do it. I want to
be albe
> > > :to impliment fairly realistic phyisics, so the method would have to be
> > > :able to acomidate things like a spike stiking out of the wall
> > > 
> > > It depends mostly on how complex your world is. If it's more like
> > > Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal
> > > floors and with solid  objects  (trees, desks, etc) treated as walls you
> > > can do most of your colision detection in 2D, basically storing the 2D map
> > > and testing for collisions in that, then using the 3D info to decide the
> > > result of the 'collision', e.g. you might need to decide whether a player
> > > stops at or steps/jumps onto a wall.
> > > 
> > > If you really want to ipmlement a Quake type engine you are in for a lot
> > > more work, as Quake has a true 3D world where walls/floors need not be
> > > horizontal or vertical. To keep the processing manageble you will probably
> > > want to treat all players and non-player characters as boxes or cylinders,
> > > i.e. so their complex interior geometry is ignored. Then you just need to
> > > do some 3D math, to see whether the corners or edges or the player might
> > > overlap adacent walls.
> > > 
> > > In either case you will probably store a list of basic game environment
> > > objects, such as rooms, walls, floors, spikes, trees, desks, etc.,
> > > together with their surfaces. If you make sure you store the global (x, y
> > > and possibly z) location of each object centre you can quickly eliminate
> > > those objects not near a player which you don't need to check against. For
> > > a large map you can reduce checking further by dividing your map into
> > > zones (e.g. rooms or floors) so that if a player is in one zone you only
> > > need to check proximity to and collisions with objects in that room.
> > > 
> > > And for both 2D and 3D checking you can save time by storing the unit
> > > normal to each wall/floor surface and the result of the scalar product of
> > > this with a point on the wall. If you repeat the calculation again with
> > > another point (the corner or center of the player) the difference between
> > > the results tells you which side of the wall the test point is on and how
> > > far away it is.
> > > 
> > > As for 'fairly realistic physics', you then want to be able to handle
> > > elastic collisions, where things bounce off walls, changing speed and
> > > direction accordingly. This is pretty straigntforward to do using vector
> > > math once you know the normal to the surface and the velocity vector of
> > > the object colliding with it. For an impressive degree of realism you
> > > could also deal with extended objects properly, allowing objects to start
> > > spinning or change their rate of rotation if hit on one side/at one end.
> > > I've not seen this done in games, so if you manage this it will be fairly
> > > impressive.
> > 
> > thanks! Any idea where I can get some formulas for this (I'm only 16 and
> > in Advance Algebra 2 (zzzz)).
> > 
> > -- 
> > -----------------------------------
> >    James Marr
> >       nagilum@mindspring.com
> > -----------------------------------
> > I think, therefore I use a Mac.
> 
> You might want to take physics course so you can familiar with the
> different phyics formulas needed to make the game seem realistic. Also, the
> book "The Tricks of the Mac Game Programming Guru's" has a whole chapter on
> game physics, and it would be a very good source for the most basic info on
> attatching real-world movement to your graphics.
> 
> -- 
> "C:\ONGRTLNS.W95"

I ment does anyone have any formauls for a quake style collision system. I
have a friend who is in physics, and he said he would help me out with the
physics part, but before I can realisticly bounce a grenade off a wall, I
must know that the greneade it hitting the wall. I don't have anyover
head; so I can adapt to any system that anyone can think of. Anything, I
am really getting discuraged by this problems; I don't want to do anything
else with my game until I have finalised what collision system I am going
to use, as anything I do may not be compatible with the new collision
system... Thanks

-- 
- ---------------------------------
   James Marr
      nagilum@mindspring.com
- ---------------------------------
I think, therefore I use a Mac.

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

>From ivolow1@ic3.ithaca.edu (Ilan Volow)
Date: Fri, 31 Oct 1997 06:19:42 -0400
Organization: None

In article <nagilum-2610971851540001@ip49.meford.or.pub-ip.psi.net>,
nagilum@mindspring.com (Nagilum) wrote:

> In article <johnb-2510972121500001@max6-60.hk.super.net>,
> johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote:
> 
> > In article <nagilum-2410970740090001@ip228.meford.or.pub-ip.psi.net>,
> > nagilum@mindspring.com (Nagilum) wrote:
> > 
> > :   I am making a 3D game, similar in many ways to quake. I need to do
> > :collision, but I don't have any idea how I should do it. I want to be albe
> > :to impliment fairly realistic phyisics, so the method would have to be
> > :able to acomidate things like a spike stiking out of the wall
> > 
> > It depends mostly on how complex your world is. If it's more like
> > Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal
> > floors and with solid  objects  (trees, desks, etc) treated as walls you
> > can do most of your colision detection in 2D, basically storing the 2D map
> > and testing for collisions in that, then using the 3D info to decide the
> > result of the 'collision', e.g. you might need to decide whether a player
> > stops at or steps/jumps onto a wall.
> > 
> > If you really want to ipmlement a Quake type engine you are in for a lot
> > more work, as Quake has a true 3D world where walls/floors need not be
> > horizontal or vertical. To keep the processing manageble you will probably
> > want to treat all players and non-player characters as boxes or cylinders,
> > i.e. so their complex interior geometry is ignored. Then you just need to
> > do some 3D math, to see whether the corners or edges or the player might
> > overlap adacent walls.
> > 
> > In either case you will probably store a list of basic game environment
> > objects, such as rooms, walls, floors, spikes, trees, desks, etc.,
> > together with their surfaces. If you make sure you store the global (x, y
> > and possibly z) location of each object centre you can quickly eliminate
> > those objects not near a player which you don't need to check against. For
> > a large map you can reduce checking further by dividing your map into
> > zones (e.g. rooms or floors) so that if a player is in one zone you only
> > need to check proximity to and collisions with objects in that room.
> > 
> > And for both 2D and 3D checking you can save time by storing the unit
> > normal to each wall/floor surface and the result of the scalar product of
> > this with a point on the wall. If you repeat the calculation again with
> > another point (the corner or center of the player) the difference between
> > the results tells you which side of the wall the test point is on and how
> > far away it is.
> > 
> > As for 'fairly realistic physics', you then want to be able to handle
> > elastic collisions, where things bounce off walls, changing speed and
> > direction accordingly. This is pretty straigntforward to do using vector
> > math once you know the normal to the surface and the velocity vector of
> > the object colliding with it. For an impressive degree of realism you
> > could also deal with extended objects properly, allowing objects to start
> > spinning or change their rate of rotation if hit on one side/at one end.
> > I've not seen this done in games, so if you manage this it will be fairly
> > impressive.
> 
> thanks! Any idea where I can get some formulas for this (I'm only 16 and
> in Advance Algebra 2 (zzzz)).
> 
> -- 
> -----------------------------------
>    James Marr
>       nagilum@mindspring.com
> -----------------------------------
> I think, therefore I use a Mac.

You might want to take physics course so you can familiar with the
different phyics formulas needed to make the game seem realistic. Also, the
book "The Tricks of the Mac Game Programming Guru's" has a whole chapter on
game physics, and it would be a very good source for the most basic info on
attatching real-world movement to your graphics.

-- 
"C:\ONGRTLNS.W95"

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

>From jmunkki@alpha.hut.fi (Juri Munkki)
Date: 1 Nov 1997 02:53:36 GMT
Organization: Helsinki University of Technology

In article <nagilum-3010972155380001@ip156.meford.or.pub-ip.psi.net> nagilum@mindspring.com (Nagilum) writes:
>physics part, but before I can realisticly bounce a grenade off a wall, I
>must know that the greneade it hitting the wall. I don't have anyover
>head; so I can adapt to any system that anyone can think of. Anything, I
>am really getting discuraged by this problems; I don't want to do anything
>else with my game until I have finalised what collision system I am going
>to use, as anything I do may not be compatible with the new collision
>system... Thanks

Here's a brief outline of what Avara uses for grenades and other fast
moving objects:

Each time the object is moved, a ray is shot from the old position to
the new and that ray is collision-tested with objects that are in the
vicinity. Ray/object algorithms can easily be found, because they are
used for raytracing algorithms.

If the ray doesn't intersect with anything, the actual object is moved
and then its bounding volume (in the case of Avara, the intersection of
a bounding box & sphere) is tested against other bounding volumes. If
there's a hit, the grenade explodes.

Bounding volume intersections can become complicated, if you use
complicated bounding volumes. Even though Avara uses relatively
simple bounding volume shapes, there's a slight bug in the way
box/box intersections are detected. Fortunately the sphere/sphere,
sphere/box and box/sphere tests make this problem almost unnoticeable,
unless you know exactly what to look for.

More general babbling:

Don't get discouraged. Geometry and algorithms for geometrical problems
are really quite fascinating mental puzzles. There's usually a neat
solution, if you are clever. In many cases you can think of the problem
in 2D and use the 2D solution to solve the 3D case. It doesn't always
work, but it usually gives you at least some insight to the 3D problem.

Try to stay away from working with angles. Use normalized axis vectors
instead. In most cases you only need a few dot products here and there
to solve your problem.
-- 
Juri Munkki jmunkki@iki.fi		Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki		   Windsurfing: Faster than the wind.

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

>From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne)
Date: Mon, 03 Nov 1997 22:18:21 +0800
Organization: Hong Kong Supernet

In article <nagilum-3010972155380001@ip156.meford.or.pub-ip.psi.net>,
nagilum@mindspring.com (Nagilum) wrote:

[ SNIP ! ]

:I ment does anyone have any formauls for a quake style collision system. I
:have a friend who is in physics, and he said he would help me out with the
:physics part, but before I can realisticly bounce a grenade off a wall, I
:must know that the greneade it hitting the wall. I don't have anyover
:head; so I can adapt to any system that anyone can think of. Anything, I
:am really getting discuraged by this problems; I don't want to do anything
:else with my game until I have finalised what collision system I am going
:to use, as anything I do may not be compatible with the new collision
:system... Thanks

I don't think it's possible to just provide a set of formulae to do this.
Generic formulae are close to useless, as in any real world situation
there are always many shortcuts specific to your world that you can apply.

E.g. the most generic formulae would treat all 3D objects as polyhedra and
do 3D math on their surfaces, edges and vertices to determine if and
when/where objects collide. But in practice you rarely want or can afford
such precision. 

Most 3D worlds use many compromises to limit the number of calcuations,
e.g. typically many objects (switches, doors) are geometrically flat, with
textures used to give the illusion of 3D, while the player and non-player
characters are often treated geometrically as cuboids or cylinders. Other
compromises include flat vs sloped floors, elastic collisions (proper
bounces) vs pseudo-elastic or inelastic, how/whether gravity/drag effects
motion/projectiles, whether bridges or outdoors/indoors environments are
(well) supported.

It's considerations such as these which seperate games: e.g. Doom has a
strictly 2D map with only 2D objects, no ballisic projectiles and no
outdoor environments. Marathon has maps with multiple layers but still no
bridges, still only 2D sprites. Dark Forces partly supports bridges and 3D
objects, but most objects are sprites and collisions are still all done in
2D. Duke has 3D surfaces, full support for bridges and better ballistics
and bounces but still uses a 2D map and sprites. Quake has a 3D
environment and objects/enemies but still uses textures for switches and
simple bounding boxes for player/object collisions. Avara has one of the
most complete 3D implimentations, but it doesn't do textures.

Each of these will have it's own optimisations for 3D rendering and
collision testing, because a complete, realistic 3D system would just be
too complex for modern computers. It also allows them to trade
compromises, e.g. using textures to represent some 3D objects to allow for
more [complex] 3D objects elsewhere, using bounding boxes to reduce the
complexity of hit-testing.

Your best bet would be to read up on or take a course on the physics and
math involved, to get a handle on what you need. Once you have this you
could try implimenting some simple ideas in a demo, to give you a better
idea of what's involved and so you can see the impact the decisions you
make on how to impliment 3D in your game will have. Unfortunately it won't
be until you are close to completing coding that you'll be able to really
see what effects such decisions will have, and so you may be still making
such decisions well down the line.

Implimenting a 3D engine is far from trivial and is not something to be
undertaken lightly. If it were easy you wouldn't see so many commercial
games recycling other people's 3D engines: all the 3D engines above,
except for Avara's, have been adopted by other publishers in commercial
games.

John

-- 
John Blackburne; programmer, writer, consultant, trainer
tel/fax: Hong Kong (+852) 2816 7484
home page: <http://www.hk.super.net/~johnb>

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

>From Andre-John Mas <amas@lhr-sys.dhl.com>
Date: Tue, 04 Nov 1997 16:18:30 +0000
Organization: DHL Systems Ltd

One approach to checking for 3D collision would be to take your
2D collision algorithm and modify it to work in a 3D environment.
Your 2D algorithm will take into account X and Y, you simply need
to add support for the Z coordinate.

BTW I haven't actually tested the above

AJ

-- 
* Andre Mas                    **  Tel. +44 181 996 3841 *
* mailto:amas@lhr-sys.dhl.com  **  Fax. +44 181 996 3802 *
* current geographical Location - United Kingdom ....... *

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

>From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne)
Date: Thu, 06 Nov 1997 23:47:00 +0800
Organization: Hong Kong Supernet

In article <345F4AD6.6496@lhr-sys.dhl.com>, Andre-John Mas
<amas@lhr-sys.dhl.com> wrote:

:One approach to checking for 3D collision would be to take your
:2D collision algorithm and modify it to work in a 3D environment.
:Your 2D algorithm will take into account X and Y, you simply need
:to add support for the Z coordinate.

This would work fine if you only had horizontal floors and vertical walls,
as in Doom (I, II), Marathon (I, II, inf) Dark Forces. Then you just do 2D
hit testing in a 2D map (you may use floors or layers to make it more 3D
but it's still basically a 2D map) and use the z valuse to decide what to
do with it, e.g. did the rocket 'hit' that low wall high enough to go over
it.

But I think the original poster wanted proper physics in a Quake-like 3D
world, in which case you are going to have to deal with X, Y and Z all at
once and at some point do proper 3D math, which is similar to but a fair
bit more complex than the 2D stuff, especially if you want to come close
to realistic physics.

John

-- 
John Blackburne; programmer, writer, consultant, trainer
tel/fax: Hong Kong (+852) 2816 7484
home page: <http://www.hk.super.net/~johnb>

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

>From jrl@netcom.com (Dr. J. Robert Lee)
Subject: AIFF sound files
Date: Thu, 30 Oct 1997 15:32:10 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

Looking for documentation on AIFF sound file structure.. The docs that
I found at Apple are incomplete. Any suuggestions?
-- 
J. Robert Lee, Ph.D.

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

>From shanks@yallara.cs.rmit.edu.au (Vaughan)
Date: 3 Nov 1997 00:40:52 GMT
Organization: Comp Sci, RMIT University, Melbourne, Australia.

Dr. J. Robert Lee (jrl@netcom.com) wrote:
: Looking for documentation on AIFF sound file structure.. The docs that
: I found at Apple are incomplete. Any suuggestions?

    There's a few pages explaining the structure in Think Reference (a
commercial online reference that came with Symantec C/C++ 8)

	Vaughan :-)

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

>From nebulus@netcom.com (Bruce McDiffett)
Date: Mon, 3 Nov 1997 04:46:24 GMT
Organization: Cineplex Odious

Vaughan (shanks@yallara.cs.rmit.edu.au) wrote:
: Dr. J. Robert Lee (jrl@netcom.com) wrote:
: : Looking for documentation on AIFF sound file structure.. The docs that
: : I found at Apple are incomplete. Any suuggestions?

:     There's a few pages explaining the structure in Think Reference (a
: commercial online reference that came with Symantec C/C++ 8)

: 	Vaughan :-)


You can also grab the AIFF-C spec off the web - one URL that works is:

ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z

The AIFF-C format supports various kinds of compression of the digital 
audio data within the AIFF wrapper.



Bruce
Microsoft Windows - Who Do You Have To Blow Today?

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

>From 3gl21@qlink.queensu.ca (Gregory Lo)
Subject: Dialog picture item opcodes for single gray line
Date: Thu, 30 Oct 1997 19:48:16 -0500
Organization: Queen's University

Hey all,

I seem to remember reading somewhere of a trick to create a small PICT
resource containing only the opcodes for a horizontal line (sometimes with
a pattern), and merely using that PICT in a DITL wherever a horizontal
divider was needed.  However, I can't seem to find a reference to it
anywhere.

Anyone care to post it?  I'd appreciate the refresher.

TIA,

GLo

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

>From MacComCenter@airmail.net (Alec Carlson)
Date: Sun, 02 Nov 1997 12:36:30 -0500
Organization: Smith Micro Software, Inc.

In article <3gl21-3010971948160001@du114.n221.resnet.queensu.ca>,
3gl21@qlink.queensu.ca wrote:

> Hey all,
> 
> I seem to remember reading somewhere of a trick to create a small PICT
> resource containing only the opcodes for a horizontal line (sometimes with
> a pattern), and merely using that PICT in a DITL wherever a horizontal
> divider was needed.  However, I can't seem to find a reference to it
> anywhere.
> 
> Anyone care to post it?  I'd appreciate the refresher.
> 

Try this trick. Open ResEdit. Create a new cicn resource. Create a new PICT
resource. Open the cicn resource, use the pencil to create a 4 pixel color
rectangle in the upper left corner. Select all 4 pixels. Click to the PICT
resource and Paste these into the PICT. You can now use the PICT resource
in a dialog to define a line of that color in any thickness or length.

Alec Carlson

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

>From smfr@santafe.edu (Simon Fraser)
Date: Mon, 03 Nov 1997 09:14:46 +0000
Organization: Imperial College, London, UK

In article
<782F0DB6357844C1.769B15C9B1FBC423.C4966F11332AE6C2@library-proxy.airnews.net>,
MacComCenter@airmail.net (Alec Carlson) wrote:

> In article <3gl21-3010971948160001@du114.n221.resnet.queensu.ca>,
> 3gl21@qlink.queensu.ca wrote:
> 
> > I seem to remember reading somewhere of a trick to create a small PICT
> > resource containing only the opcodes for a horizontal line (sometimes with
> > a pattern), and merely using that PICT in a DITL wherever a horizontal
> > divider was needed.  However, I can't seem to find a reference to it
> > anywhere.
> > 
> > Anyone care to post it?  I'd appreciate the refresher.
> > 
> Try this trick. Open ResEdit. Create a new cicn resource. Create a new PICT
> resource. Open the cicn resource, use the pencil to create a 4 pixel color
> rectangle in the upper left corner. Select all 4 pixels. Click to the PICT
> resource and Paste these into the PICT. You can now use the PICT resource
> in a dialog to define a line of that color in any thickness or length.

You don't even need to do this. There is such a PICT in the System
file, with an ID of 11. This will give you a grey pattern in mono,
and grey in colour dialogs. Just set the ID of the PICT item in the
dialog to 11. Not sure if/where this is documented, but it's worked
on all systems that I've tried.

Simon

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

>From Jessica Wirna <venus@amug.org>
Subject: Fast font and screen blitters...
Date: Sat, 8 Nov 1997 05:46:09 -0700
Organization: AMUG Internet Services


	Hi all!
	
	I'm looking at what's taking up the most time in my game code, and
it's basically two parts: Blitting the screen from my back-buffer directly
onto the visible screen, and writing fonts onto the back-buffer. Does
anyone know of a good tutorial or book/discussion on speeding up these two
functions? I've already spent a fairly significant amount of time working
on my screen blitter code, but since it only partly looks like
	
	*dest++ = *src++;
	
	I am guessing maybe there is more work I could put into it to
speed it up a bit. Every ounce counts in this game, because it's got to
scream! (haven't we all heard this requirement before.... :) My biggest
problem is that it seems you can't just blindly copy the first 640*480
bytes of back-buffer into the screen memory of the current portmap,
because (now here's where I might be fuzzy) the macintosh has set up a
larger memory block than is visible on-screen in the portmap pixel block 
memory, and the non-visible portions are actually used to store
information about the colormap/mouse cursor graphic/etc, so, if you
blindly copy, you basically crash your mac. Maybe someone has some tips
about how this can be safely optimized more!
	
	My font blitter is also a bit strange, I'm just doing memory
copies from 16x16 tiles of letters/numbers onto my screen where the score
and other text should appear. This unfortunately causes any section of the
tile where the pixel values are black to overwrite what's beneath it in
the back-buffer, so I'm looking at making a more sophisticated blitter
that only writes pixel values that are non-black in the source pixel
block. One possibility that seems easy is to track where the pixel runs
'start' and 'stop' on each horizontal line in the source pixel block and
write a routine that does variable length pixel copies from the source
block to the destination back-buffer, however, I've heard about things
like 'compiled sprites/fonts' and I'm sure there are many things I haven't
even heard of. Would anyone be willing to tutor me a little? :)
	
	Thanks,
	
		Jessica 	:)

	PS, If you could cc me in email with your response, I would be
very grateful! I just got back to netnews and this newsgroup and realized
I missed a lot of responses to my PPC asm question. :( My netnews isn't
very reliable....


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

>From "Matthew" <matthewf@panix.com>
Date: Sun, 09 Nov 1997 11:42:07 -0500
Organization: PANIX Public Access Internet and Unix, NYC

Of course you should write your own sprite blitters, but - and Im sure youve
heard this before - there is no good reason to not use copybits if you are
just copying the whole back buffer to the screen.  You risk not being
compatable with every graphics card and future Mac OS versions (including
Rhapsody).  Copybits for large areas will be fine tuned for each machine and
each processor and each graphic card.

Sometimes there are obvious exceptions like if you are going to draw every
other line or use pixel doubling or have some other special effect you are
going for.

At least have a checkbox in your prefs dialog letting the user turn on a
'more compatable' mode which uses Copybits.

>>
	I'm looking at what's taking up the most time in my game code, and
it's basically two parts: Blitting the screen from my back-buffer directly
onto the visible screen, and writing fonts onto the back-buffer. Does
anyone know of a good tutorial or book/discussion on speeding up these two
functions? I've already spent a fairly significant amount of time working
on my screen blitter code, but since it only partly looks like
	
	*dest++ = *src++;
<<

Well make sure the pointers are double ptrs (for PPC only).  Unroll your
loop ie:
 for (count=0; count<50; count++)
    *dest++ = *src++;

could become:
 for (count=0; count<10; count++)
    {*dest++ = *src++;
    *dest++ = *src++;
    *dest++ = *src++;
    *dest++ = *src++;
    *dest++ = *src++;}

but dont unroll too much as to "blow your cache" - that is - your entire
loop needs to fit it the processor's cache or else it will spend too much
time looking at slower RAM.

also if you are doing a sprite based game you usually dont need to draw to
the entire screen - just the parts that changed.
if you are doing a scrolling game there is a trick to make that run alot
faster too (look at how SpriteWorld 2.0 or SAT 2.5 handles scrolling).  It
basically involves *not* redrawing the enitre back buffer each time and
copying the screen in quarters - very clever stuff!

>>
My biggest
problem is that it seems you can't just blindly copy the first 640*480
bytes of back-buffer into the screen memory of the current portmap,
<<

correct

>>
	My font blitter is also a bit strange, I'm just doing memory
copies from 16x16 tiles of letters/numbers onto my screen where the score
and other text should appear. This unfortunately causes any section of the
tile where the pixel values are black to overwrite what's beneath it in
the back-buffer, so I'm looking at making a more sophisticated blitter
that only writes pixel values that are non-black in the source pixel
block. One possibility that seems easy is to track where the pixel runs
'start' and 'stop' on each horizontal line in the source pixel block and
write a routine that does variable length pixel copies from the source
block to the destination back-buffer, however, I've heard about things
like 'compiled sprites/fonts' and I'm sure there are many things I haven't
even heard of. Would anyone be willing to tutor me a little? :)
<<

I wouldnt want to dissuade someone from a DIY project - but why re-invest
the wheel when you can put your energies into the work it will take to make
your game unique.  Check out Spriteworld and SAT and if either library can
handle your graphic/sprite/blitter needs Id suggest using these well-tested
free libraries and concentrate on just the specifics of your game.

hope this helps,
Matthew

>>
I missed a lot of responses to my PPC asm question. :( My netnews isn't
<<

ok - here is what I wrote about your previous post:

>>>
Try < http://www.tau.it/lightsoft> which sells a ppc assembler called
'Fantasm' - you can download ppc example code from their site.

also try writing C example code and then use your C development environment
to *disassemble* it and see how it works (make sure to turn off all code
optimizations or the disassembled code might be indecipherable)

are you sure your project needs to be written in ppc assembler?
<<<

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

>From "Lawson English" <english@primenet.com>
Date: 9 Nov 1997 16:47:00 -0700
Organization: Primenet Services for the Internet

Matthew <matthewf@panix.com> said:

> 
> Well make sure the pointers are double ptrs (for PPC only).  Unroll your
> loop ie:
>  for (count=0; count<50; count++)
>     *dest++ = *src++;
> 

Unrolling a loop like this past a certain point on a PowerPC may not give
you much speed-gain due to the way the PowerPC accesses memory and
schedules instructions. A tight loop may be better than large loop because
a smaller instruction loop may actually fit completely within the on-chip
instruction pipeline, thereby requiring NO access to memory for new
instructions. Experiment. If you have access to a 604, try using the
monitor registers to determine actual instructions-per-cycle and so on.

Also, direct screen-writes are so slow compared to DRAM writes that it may
be possible to include simple filters *within* the blitter without ANY loss
of speed. You can do simple things like rotate by 90 degrees, for instance,
and still have cycles leftover due to the latency of VRAM.

You can also try to stagger writes to different addresses (this makes more
sense with DRAM) so that the CPU can be doing more per cycle, rather than
waiting for a chache-line to become available again.

IE, instead of writing consecutive bytes (words/long-words) in a single
stream, try writing several streams to different scan-lines or parts of the
same scan-line within the same loop.

Lots of possibilities here. As I said: PowerPC assembler is easy. OTOH,
making *optimized* PowerPC assembly code can be difficult and you may find
that your code isn't that much (if any) faster then the equivalent
algorithm written in C.

- -------------------------------------------------
For the next few weeks, as a show of support, use this sig ONLY.
I use Cyberdog.
- -------------------------------------------------




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

>From Jessica Wirna <venus@amug.org>
Subject: PPC assembler?
Date: Mon, 3 Nov 1997 15:36:52 -0700
Organization: AMUG Internet Services

	
	I bought the IBM book on the powerPC series processors, and, while
it does contain the complete instruction set and has some discussion on
how things should be used and what registers need to be set for given
operations, etc, etc, etc, it isn't really at my level because I am
basically an absolute beginner. Does anyone know a good book/tutorial on
assembler for the macintosh?
	
	Thanks,
	
		Jessica


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

>From Gregory_Norz@baylor.edu (Greg Norz)
Date: Mon, 03 Nov 1997 23:13:30 -0500
Organization: Ambient Entertainment

In article <Pine.SOL.3.96.971103153501.5587A-100000@general>, Jessica Wirna
<venus@amug.org> wrote:

>         
>         I bought the IBM book on the powerPC series processors, and, while
> it does contain the complete instruction set and has some discussion on
> how things should be used and what registers need to be set for given
> operations, etc, etc, etc, it isn't really at my level because I am
> basically an absolute beginner. Does anyone know a good book/tutorial on
> assembler for the macintosh?

Hmm...a book on PPC assembler? There are a few good ones out there.
Unfortunately, there aren't many that will give you help in learning. Most
of the ones that I've seen are quite technical on the specs of the PPC
processor. You may want to try 'PowerPC Numerics', an Inside Macintosh
volume. Also, look on www.amazon.com and search for titles. There are some
good ones there.

I think that the Inside Macintosh book may be your best bet for a beginner, tho.

greg norz

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

>From twr@po.cwru.edu (Tom Remotigue)
Date: Tue, 04 Nov 1997 17:59:56 -0700
Organization: Case Western Reserve University

> Hmm...a book on PPC assembler? There are a few good ones out there.
> Unfortunately, there aren't many that will give you help in learning. Most
> of the ones that I've seen are quite technical on the specs of the PPC
> processor. You may want to try 'PowerPC Numerics', an Inside Macintosh
> volume. Also, look on www.amazon.com and search for titles. There are some
> good ones there.
> 
> I think that the Inside Macintosh book may be your best bet for a
beginner, tho.

Also, don't limit yourself to just  books on PPC assembly. If you can find
a textbook from any microprocessors class, you might want to check it out.
Assembly for any architecture is more or less the same idea (just watch
out for big-endian vs. little-endian).

Tom

-- 
twr@po.cwru.edu
Department of Electrical Engineering
Case Western Reserve University

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

>From jbuttles@netheaven.com (Jared Buttles)
Date: 5 Nov 1997 00:55:45 GMT
Organization: (none)

In article <Pine.SOL.3.96.971103153501.5587A-100000@general>, Jessica
Wirna <venus@amug.org> wrote:

>         
>         I bought the IBM book on the powerPC series processors, and, while
> it does contain the complete instruction set and has some discussion on
> how things should be used and what registers need to be set for given
> operations, etc, etc, etc, it isn't really at my level because I am
> basically an absolute beginner. Does anyone know a good book/tutorial on
> assembler for the macintosh?

You might want to do some exploring at

http://www.tau.it/lightsoft/fantasm/fant.html

Also, I hear that the asm manual that comes with CodeWarrior is pretty
complete, though I haven't looked at it.

-- 
Jared Buttles: Christian, Mac user, programmer, furry, sailor

jbuttles@netheaven.com

"Saying Windows 95 is equal to Macintosh is like finding a potato that looks like Jesus and believing you've witnessed the second coming." 

- ---Guy Kawasaki Apple Fellow

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

>From "Lawson English" <english@primenet.com>
Date: 6 Nov 1997 12:46:01 -0700
Organization: Primenet Services for the Internet

Tom Remotigue <twr@po.cwru.edu> said:

> 
> Also, don't limit yourself to just  books on PPC assembly. If you can
find
> a textbook from any microprocessors class, you might want to check it
out.
> Assembly for any architecture is more or less the same idea (just watch
> out for big-endian vs. little-endian).

Also, don't forget to test your ASM implementation against your C/C++
version. PPC asm is easy to do, but a bitch to significantly optimize past
what a decent PPC compiler is already capable of. You may find that you
can't get the PPCAsm code to work *as fast* as the equivalent C code,
letalone faster.

Finally, the best place to find answers about PPC coding is
comp.sys.powerpc.tech

- -------------------------------------------------
For the next few weeks, as a show of support, use this sig ONLY.
I use Cyberdog.
- -------------------------------------------------




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

>From hirmes@panix.com (hirmes)
Subject: Q: timing issues with Sound Manager
Date: Tue, 21 Oct 1997 18:35:00 -0500
Organization: PANIX Public Access Internet and Unix, NYC

i'm trying to write a simple sound sequencer.  basically, i'd like to have
several "tracks" that have a specific 'snd ' or AIFF sample associated
with each track.  the tracks would be divided into, say, 100 "frames" per
second.  the track data structure could be an array of Booleans(i.e.
Boolean tracks[ MAX_TRACKS ][  MAX_LENGTH_IN_SECONDS * 100 ] ).  a timing
mechanism could check all the tracks every 1/100th of a second. if tracks[
currentTrack ][ currentTime ] was TRUE then the sound sample would begin
to play.  i guess what i'm basically describing is similar to a MIDI
sequencer except that the sound samples are kept as resources or loaded
from files, there's no pitch/frequency control, and everything is done via
the Sound Manager.  My questions are:

is this possible using basic Extended Time Manager and Sound Manager
calls?  i.e. can Sound Manager calls such as SndPlay (used asynchronously)
get called several times a second on several channels by the Time
Manager?  

if so, does anyone have any sample Time Manager code that does this sort
of rapid execution of functions? any better ideas about what kind of
datastructures to use?  etc..

oh, also assume this is PPC only.

thanks,

d. hirmes
hirmes@pobox.com

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

>From hirmes@panix.com (hirmes)
Date: Wed, 22 Oct 1997 11:12:38 -0500
Organization: PANIX Public Access Internet and Unix, NYC

In article <nospam-2210970912450001@d152.nhe.interaccess.com>,
nospam@nospam.net.com.edu (Darrin Cardani) wrote:

> In article <hirmes-2110971835000001@hirmes.dialup.access.net>,
> hirmes@panix.com (hirmes) wrote:
> 
> > i'm trying to write a simple sound sequencer. 
> [...]
> >i guess what i'm basically describing is similar to a MIDI
> > sequencer except that the sound samples are kept as resources or loaded
> > from files, there's no pitch/frequency control, and everything is done via
> > the Sound Manager.
> 
> You might want to check out an old issue of develop that had an article on
> how to write a simple multi-track recorder. The code was called Cheap
> Studio, and I think it can be found at www.devworld.com. They used to have
> all the back issues of develop, and I would assume they still do.
> 
> Darrin

i guess i shouldn't have mentioned MIDI at all-- it seems to have confused
the issue.  the great thing about QuickTime MIDI support is that it's easy
to use and doesn't require any additional hardware.  the bad thing about
QT MIDI support is that unless you have additional hardware, you're stuck
with the standard MIDI library of sounds that comes with your system.  if
there was a way to create additional MIDI sound libraries from AIFF files,
then i probably wouldn't need to write the program i described. 
basically, i want the _structure_ of a MIDI sequencer, but the ability to
trigger actual AIFF or 'snd ' files instead of sounds from a the MIDI
library...

thanks anyway!

d. hirmes

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

>From nospam@nospam.net.com.edu (Darrin Cardani)
Date: Wed, 22 Oct 1997 09:12:44 -0500
Organization: Total Integration, Inc.

In article <hirmes-2110971835000001@hirmes.dialup.access.net>,
hirmes@panix.com (hirmes) wrote:

> i'm trying to write a simple sound sequencer. 
[...]
>i guess what i'm basically describing is similar to a MIDI
> sequencer except that the sound samples are kept as resources or loaded
> from files, there's no pitch/frequency control, and everything is done via
> the Sound Manager.

You might want to check out an old issue of develop that had an article on
how to write a simple multi-track recorder. The code was called Cheap
Studio, and I think it can be found at www.devworld.com. They used to have
all the back issues of develop, and I would assume they still do.

Darrin

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

>From jaeho@xs4all.nl (Jae Ho Chang)
Date: Thu, 23 Oct 1997 00:41:03 +0200
Organization: XS4ALL, networking for the masses

>is this possible using basic Extended Time Manager and Sound Manager
>calls?  i.e. can Sound Manager calls such as SndPlay (used asynchronously)
>get called several times a second on several channels by the Time
>Manager?  

It will cause a system error, because SndPlay() can't be called at
interrupt time.
I've never tried this, but the clue might be using SndDoImmediate() with
Time Manager.

Jae Ho Chang =)
--
http://www.xs4all.nl/~jaeho
Institute of Sonology
Royal Conservatory, The Hague

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

>From Michel.Pollet@teaser.fr (Michel Pollet)
Date: Thu, 6 Nov 1997 17:54:54 +0100
Organization: SAT/SAGEM

hirmes <hirmes@panix.com> wrote:

> is this possible using basic Extended Time Manager and Sound Manager
> calls?  i.e. can Sound Manager calls such as SndPlay (used
> asynchronously) get called several times a second on several channels by
> the Time Manager?

I think it would be much better to actually use the SndDblPlay, and use
the interruption is gives to compute the time you want. You could then
decide what to play.
The SndDblTime interrupt is MUCH more precise than the Time Manager, who
is reputed (and proven) to be of a resolution that is NOT to the
millisecond :-)

You could just compute from the frequency of the sound you wish to play
the delay needed... and generate balck sample for the delays you need.
For your SndPlay, you could use a SndPlay on your preloaded sounds with
a command callback, generate a Pause Command as the first interrupt for
each sound, and generate a resume sound command from your main
SndDblBuffer sheduler.
That would bypass the problem of the SndPlay & interrupts...

--
Michel Pollet                       Macintosh developer & MkLinux hacker
Email: michel@dcm.sat.fr                        Phone: +33 4 92 96 68 66
http://www.teaser.fr/~mpollet/           <-- Have a look at my guitars !

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

>From Michel.Pollet@teaser.fr (Michel Pollet)
Date: Mon, 10 Nov 1997 16:58:24 +0100
Organization: SAT/SAGEM

hirmes <hirmes@panix.com> wrote:

> is this possible using basic Extended Time Manager and Sound Manager
> calls?  i.e. can Sound Manager calls such as SndPlay (used
> asynchronously) get called several times a second on several channels by
> the Time Manager?

I think it would be much better to actually use the SndDblPlay, and use
the interruption is gives to compute the time you want. You could then
decide what to play.
The SndDblTime interrupt is MUCH more precise than the Time Manager, who
is reputed (and proven) to be of a resolution that is NOT to the
millisecond :-)

You could just compute from the frequency of the sound you wish to play
the delay needed... and generate balck sample for the delays you need.
For your SndPlay, you could use a SndPlay on your preloaded sounds with
a command callback, generate a Pause Command as the first interrupt for
each sound, and generate a resume sound command from your main
SndDblBuffer sheduler.
That would bypass the problem of the SndPlay & interrupts...

--
Michel Pollet                       Macintosh developer & MkLinux hacker
Email: michel@dcm.sat.fr                        Phone: +33 4 92 96 68 66
http://www.teaser.fr/~mpollet/           <-- Have a look at my guitars !

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

>From spam@dev.nul (Nate Wilson)
Subject: Quickdraw fast with regions?
Date: Sat, 25 Oct 1997 23:11:19 -0500
Organization: (none)

Hello,
I need some advice on Quickdraw and would appreciate your
suggestions. I have a window that displays a grid, like a
tic-tac-toe game, with text drawn in the squares. The grid
never changes but the text in the squares does. Would it be
faster to redraw the contents of the window by:

a)  Erasing the whole window portRect
    Redrawing the grid with a bunch of MoveTo() and LineTo()'s
    Redrawing the text with a bunch of MoveTo(), DrawSting()'s
or

b)  Defining a complicated region of just the squares inside the
     grid (would only have to be done once when app launches)
    Erasing the region
    Redrawing the text with a bunch of MoveTo(), DrawSting()'s

The second approach eliminates the unnecesary(sp) redrawing
of the grid, but I imagine that it would take QD longer to erase
a complicated, dis-contiguos region than a simple recangle.
Any thoughts on the subject?

Thanks,
Nate

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

>From woody@alumni.caltech.edu (William Edward Woody)
Date: Sat, 25 Oct 1997 23:19:39 -0700
Organization: In Phase Consulting

spam@dev.nul (Nate Wilson) wrote:
> The second approach eliminates the unnecesary(sp) redrawing
> of the grid, but I imagine that it would take QD longer to erase
> a complicated, dis-contiguos region than a simple recangle.
> Any thoughts on the subject?

Yes. There is real speed, and there is apparent (or perceived)
speed.

And while erasing a bunch of discontinuous regions in the fashion
you suggest may be harder and slower for QuickDraw, I'll bet you
it will feel a *lot* faster.

The ultimate example of slow drawing which seems faster is code
to draw the window off-screen and blow the bits on the screen
when the drawing is done. This is used a lot with some CAD systems
and other drawing tools, and while it is sometimes takes twice as
long to draw the display, it feels a lot faster.

                                            - Bill

-- 
William Edward Woody                 | In Phase Consulting
woody@alumni.caltech.edu             | Macintosh & Microsoft Windows
http://www.alumni.caltech.edu/~woody | http://www.znd.net/inphase

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

>From dstone@BIT.chem.utoronto.ca (David Stone)
Date: 27 Oct 1997 15:25:45 GMT
Organization: University of Toronto Chemistry

In article <woody-2510972319400001@192.0.2.1>, woody@alumni.caltech.edu
(William Edward Woody) wrote:
> 
> spam@dev.nul (Nate Wilson) wrote:
> > The second approach eliminates the unnecesary(sp) redrawing
> > of the grid, but I imagine that it would take QD longer to erase
> > a complicated, dis-contiguos region than a simple recangle.
> > Any thoughts on the subject?
[snip]
> The ultimate example of slow drawing which seems faster is code
> to draw the window off-screen and blow the bits on the screen
> when the drawing is done.

I think what he's trying to suggest is drawing the grid into an
offscreen GWorld when your program starts up (anyway you like...)
and then CopyBits it to the screen whenever you need a new game board.
That way you only ever really _draw_ the board once; redraws will be
much faster.

David Stone
(remove the obvious bit to reply...)

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

>From woody@alumni.caltech.edu (William Edward Woody)
Date: Mon, 27 Oct 1997 10:30:56 -0800
Organization: In Phase Consulting

In article <dstone-271097112736@csgmac.chem.utoronto.ca>,
dstone@BIT.chem.utoronto.ca (David Stone) wrote:

> In article <woody-2510972319400001@192.0.2.1>, woody@alumni.caltech.edu
> (William Edward Woody) wrote:
> > 
> > spam@dev.nul (Nate Wilson) wrote:
> > > The second approach eliminates the unnecesary(sp) redrawing
> > > of the grid, but I imagine that it would take QD longer to erase
> > > a complicated, dis-contiguos region than a simple recangle.
> > > Any thoughts on the subject?
> [snip]
> > The ultimate example of slow drawing which seems faster is code
> > to draw the window off-screen and blow the bits on the screen
> > when the drawing is done.
> 
> I think what he's trying to suggest is drawing the grid into an
> offscreen GWorld when your program starts up (anyway you like...)
> and then CopyBits it to the screen whenever you need a new game board.
> That way you only ever really _draw_ the board once; redraws will be
> much faster.

Not quite; I was talking about drawing the entire game off-screen
into an offscreen GWorld and using CopyBits to copy it on to the screen
whenver you need to redraw the screen <<at>> <<any>> <<time>>. For
responces to updateEvt events, for example, or in responce to a new
move.

It's slow, but it seems faster.

This may not be the best strategy, by the way, but it's the one that
the Finder in MacOS 8 uses to update it's windows.

                                            - Bill

-- 
William Edward Woody                 | In Phase Consulting
woody@alumni.caltech.edu             | Macintosh & Microsoft Windows
http://www.alumni.caltech.edu/~woody | http://www.znd.net/inphase

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

>From michael@kluev.-deIete-.msk.ru
Date: Tue, 28 Oct 1997 01:48:23 +0300
Organization: _

In article <dstone-271097112736@csgmac.chem.utoronto.ca>,
dstone@BIT.chem.utoronto.ca (David Stone) wrote:

> In article <woody-2510972319400001@192.0.2.1>, woody@alumni.caltech.edu
> (William Edward Woody) wrote:
> > 
> > spam@dev.nul (Nate Wilson) wrote:
> > > The second approach eliminates the unnecesary(sp) redrawing
> > > of the grid, but I imagine that it would take QD longer to erase
> > > a complicated, dis-contiguos region than a simple recangle.
> > > Any thoughts on the subject?
> [snip]
> > The ultimate example of slow drawing which seems faster is code
> > to draw the window off-screen and blow the bits on the screen
> > when the drawing is done.
> 
> I think what he's trying to suggest is drawing the grid into an
> offscreen GWorld when your program starts up (anyway you like...)
> and then CopyBits it to the screen whenever you need a new game board.
> That way you only ever really _draw_ the board once; redraws will be
> much faster.

Not necessary full window blit will be faster than drawing of
several lines. Though it might "seems" faster.

-- 
Michael Kluev.

PS. Remove "-delete-." part from my address to reply.

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

>From "Seth Hill" <ferris@proaxis.com>
Date: 31 Oct 97 01:27:54 -0800
Organization: All USENET -- http://www.Supernews.com

My first rule of programming with quickdraw: Regions are slow as hell.
Erasing a rectangle & drawing some stuff is very definitly faster than
erasing a region and drawing some stuff, even if you're drawing more stuff
with the rectangle approach.

However, in a Tick-tack-toe style game, where you're not redrawing the
screen 30 times a second, it really wouldn't be a big speed hit.

But, being a game programmer at heart, I'd recomend doing all of you're
drawing into an offscreen gworld (using method A), and then using CopyBits
to put it into your window. This has the advantages of easy updates
(CopyBits the gworld to the screen on an update event), no flicker between
erasing the window & redrawing it, and it's probably faster than drawing
everything on the screen without the gworld. However, using gworlds adds a
layer of complexity to your program that you might not want to deal with,
in which case, I'd ignore this paragraph and sitck with the first one.

On Sat, Oct 25, 1997 8:11 PM, Nate Wilson <mailto:spam@dev.nul> wrote:
>Hello,
>I need some advice on Quickdraw and would appreciate your
>suggestions. I have a window that displays a grid, like a
>tic-tac-toe game, with text drawn in the squares. The grid
>never changes but the text in the squares does. Would it be
>faster to redraw the contents of the window by:
>
>a)  Erasing the whole window portRect
>    Redrawing the grid with a bunch of MoveTo() and LineTo()'s
>    Redrawing the text with a bunch of MoveTo(), DrawSting()'s
>or
>
>b)  Defining a complicated region of just the squares inside the
>     grid (would only have to be done once when app launches)
>    Erasing the region
>    Redrawing the text with a bunch of MoveTo(), DrawSting()'s
>
>The second approach eliminates the unnecesary(sp) redrawing
>of the grid, but I imagine that it would take QD longer to erase
>a complicated, dis-contiguos region than a simple recangle.
>Any thoughts on the subject?
>
>Thanks,
>Nate
>


_____________________________________________________________________
                 Seth Hill | ferris@proaxis.com
      Troposphere Software | http://www.proaxis.com/~ferris/software/
_____________________________________________________________________
"What are we going to do tomorrow night, Brain?"
"The same thing we do every night, Pinky - Try to take over the world!
        -Pinky And The Brain



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

>From ilesasw@aol.com (Ilesa SW)
Subject: Shutting Down the Comp.?
Date: 2 Nov 1997 00:52:20 GMT
Organization: AOL http://www.aol.com

Anyone have any (or know where I can find) some sample C code for shutting down
 the computer? I hear it can be done w/ AppleEvents, but what is the event
 class/id, and what parameters need to be sent?

Thx, and email responses to mal@ilesa.com.

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

>From i'm@not.here (Jeff Clites)
Date: Sun, 02 Nov 1997 02:21:59 -0800
Organization: California Institute of Technology, Pasadena

In article <19971102005200.TAA03391@ladder02.news.aol.com>,
ilesasw@aol.com (Ilesa SW) wrote:

>Anyone have any (or know where I can find) some sample C code for shutting down
> the computer? I hear it can be done w/ AppleEvents, but what is the event
> class/id, and what parameters need to be sent?

The AppleScript for this is just:

tell application "Finder"
   shut down
end tell

The easiest thing to do is:
1) Paste this into the ScriptEditor, and save it as a compiled script
2) Use RedEdit to copy the 'scpt' resource from your saved, compiled
script into the resource file for your program.
3) Execute this resource-based script from your app. Code to allow you to
do this can be found by searching DejaNews for the following post:

   From: sbryan@vendorsystems.com (Steve Bryan)
    Newsgroups: 
      comp.sys.mac.programmer.help,comp.sys.mac.programmer.codewarrior
   Subject: Re: [Q] How to Hide Applications Programmatically
   Date: Mon, 20 Oct 1997 15:41:12 -0500
   Message-ID: <sbryan-2010971541290001@202.1.1.54>

This should do the trick.

- ------------------------------------------------------------------------
Jeff Clites                                           Pasadena, California

My account name is jac and the rest of my address has igor and caltech and
edu, separated by dots. Don't spam me or anybody else (please).

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

>From Maf Vosburgh <maf@mmcorp.com>
Date: 4 Nov 1997 19:00:25 GMT
Organization: MultiMedia Corporation

In article <19971102005200.TAA03391@ladder02.news.aol.com> Ilesa SW,
ilesasw@aol.com writes:
>Anyone have any (or know where I can find) some sample C code for shutting down
> the computer? I hear it can be done w/ AppleEvents, but what is the event
> class/id, and what parameters need to be sent?


This does the trick.

Maf

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

OSErr	ShutDownSafely(void)
{
	OSErr 		result = noErr;
	AEDesc		finderAddr;
	AppleEvent	shutDownEvent;
	AppleEvent	nilReply;
	OSType		finderSig = 'MACS';
	
	result = AECreateDesc('sign', &finderSig, sizeof(OSType), &finderAddr);
		
		
	if (result == noErr)
		 result = AECreateAppleEvent('FNDR', 'shut', &finderAddr,
						kAutoGenerateReturnID,kAnyTransactionID,&shutDownEvent);
		
	if (result == noErr)
		result = AESend(&shutDownEvent, &nilReply, 
						kAENoReply + kAECanSwitchLayer + kAEAlwaysInteract,
						kAENormalPriority, kAEDefaultTimeout, nil, nil);


	return result;
}

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

>From meadowsr@fgm.com
Subject: Updated toolbox references
Date: Tue, 28 Oct 1997 11:21:22 -0600
Organization: Deja News Usenet Posting Service

Where can I find updated IM-type reference material containing the new
control types now available (like the bevel button, slider, window
header, group box--all those nifty things Resorcerer lets you use).  I've
searched around apple.com to no avail.



PDF Inside-Mac would be OK, QuickView databases are preferred.



thanks...

randy

PLEASE cc: your response to <mailto:meadowsr@fgm.com> if possible.

- -----------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

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

>From i'm@not.here (Jeff Clites)
Date: Tue, 28 Oct 1997 20:07:41 -0800
Organization: California Institute of Technology, Pasadena

In article <878058597.5268@dejanews.com>, meadowsr@fgm.com wrote:

>Where can I find updated IM-type reference material containing the new
>control types now available (like the bevel button, slider, window
>header, group box--all those nifty things Resorcerer lets you use).  I've
>searched around apple.com to no avail.

You can download the Appearance Manager docs from

      http://gemma.apple.com/MacOS8/

- ------------------------------------------------------------------------
Jeff Clites                                           Pasadena, California

My account name is jac and the rest of my address has igor and caltech and
edu, separated by dots. Don't spam me or anybody else (please).

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

>From meeroh@mit.edu (Miro Jurisic)
Date: Sat, 08 Nov 1997 00:42:54 -0500
Organization: MIT

In article <878058597.5268@dejanews.com>, meadowsr@fgm.com wrote:

> Where can I find updated IM-type reference material containing the new
> control types now available (like the bevel button, slider, window
> header, group box--all those nifty things Resorcerer lets you use).  I've
> searched around apple.com to no avail.

<http://gemma.apple.com/MacOS8/Appearance_Manager.sea.hqx>

hth,

meeroh

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

>From fred@no.spam.leeds.ac.uk
Subject: Which books for 3D programming & 3d maths
Date: Mon, 3 Nov 1997 17:56:38 +0000 (GMT)
Organization: University of Leeds

Which books are programers using or recommending for 3D graphics
development and for the maths for 3D and/or physics models for games?

Is there anything better than Foley and van Dam?

Are any of the books aimed at Windows/DirectX any use?

Ben.

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

>From twr@po.cwru.edu (Tom Remotigue)
Date: Mon, 03 Nov 1997 19:17:01 -0700
Organization: Case Western Reserve University

In article <345E8058.5526@no.spam>, fred@no.spam.leeds.ac.uk wrote:

> Which books are programers using or recommending for 3D graphics
> development and for the maths for 3D and/or physics models for games?
> 
> Is there anything better than Foley and van Dam?
> 
> Are any of the books aimed at Windows/DirectX any use?
> 
> Ben.

Check out the 'Graphics Programming Black Book' by Mike Abrash. He worked
on Quake, wrote 'The Zen of Assembly Language Programming' and did a bunch
of stuff for Dr. Dobb's. Lots of theory and info on how they developed
Quake. Lots of Windows C/assembly code, but a useful book nonetheless.

Tom

-- 
twr@po.cwru.edu
Department of Electrical Engineering
Case Western Reserve University

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

>From Gregory_Norz@baylor.edu (Greg Norz)
Date: Mon, 03 Nov 1997 23:18:36 -0500
Organization: Ambient Entertainment

In article <345E8058.5526@no.spam>, fred@no.spam.leeds.ac.uk wrote:

> Which books are programers using or recommending for 3D graphics
> development and for the maths for 3D and/or physics models for games?
> 
> Is there anything better than Foley and van Dam?

I happen to like 'Advanced Amimation and Rendering Technique' by Alan and
Mark Watt, Addison Wesley Publishers. It's quite deep and not for the faint
of heart, but it will give you what you need. It has a good deal of math in
it. If you want some deep math, look for a book on Computational Geometry.
Most books of that nature will provide a lot of the math behind many basic
2D and 3D concepts. Also, Brian Hook has one about programming a 3D game
engine in C++. It's not too bad either.

> 
> Are any of the books aimed at Windows/DirectX any use?

There are several. Search www.amazon.com as the exact titles escape me now.
I know for a fact that the Microsoft Press has at least one out. There are
some third party (if such a thing exists in the book world) ones, too.
> 
> Ben.

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

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