From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-069
Date: Sat, 19 Nov 1994 15:31:42 +0100 (MET)
C.S.M.P. Digest Sat, 19 Nov 94 Volume 3 : Issue 69
Today's Topics:
Animation Techniques
Control Strip Tester Available!
Dragging to a background app?
GeoPort-GeoPod Documentation - Does it exist?
How to get list of files in folder
Sample code for Launching appl from SC++ or TC.
Subject: Apple PR: MacOS Software Developer's Kit
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 whsands@netcom.com (Tom Williams)
Subject: Animation Techniques
Date: Tue, 1 Nov 1994 07:41:03 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Hi Everyone.
I am interrested in the different aproaches for storing all of a
programs sprites for a project. In particular, a game. As I browse
through many Mac Games' Resource Forks, I come across two common
aproaches. The first is to have each sprite (usually no larger than
32x32) contained in its own PICT resource. The second is to merge all
the sprites into one big huge pict resource. The second aproach seems
more logical since you could simply create a gworld, copy the entire pict
into the gworld and then copybits the rects of the part of the image you
want to display on the screen at one time.
Does anyone have any arguments and possibly some C source code around
pertaining to the second method?
Thanks in advance,
Warm Regards,
Tom Williams.
+++++++++++++++++++++++++++
>From posto881@cs.uidaho.edu (DuckMan)
Date: 1 Nov 1994 19:41:10 GMT
Organization: University of Idaho, Moscow, Idaho
Tom Williams (whsands@netcom.com) wrote:
: Hi Everyone.
: I am interrested in the different aproaches for storing all of a
: programs sprites for a project. In particular, a game. As I browse
: through many Mac Games' Resource Forks, I come across two common
: aproaches. The first is to have each sprite (usually no larger than
: 32x32) contained in its own PICT resource. The second is to merge all
: the sprites into one big huge pict resource. The second aproach seems
: more logical since you could simply create a gworld, copy the entire pict
: into the gworld and then copybits the rects of the part of the image you
: want to display on the screen at one time.
: Does anyone have any arguments and possibly some C source code around
: pertaining to the second method?
: Thanks in advance,
: Warm Regards,
: Tom Williams.
I tryed the second method myself and it seems to work very well. The only
problem I'm having now is with the copymask.
I have no problem using copymask as long as the source rects line up on the
lefthand side (source.left==0). but if its any distence away funny things
start to happen. Any suggestions?
DuckMan...
+++++++++++++++++++++++++++
>From kenlong@netcom.com (Ken Long)
Date: Wed, 2 Nov 1994 18:05:36 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Tom Williams (whsands@netcom.com) wrote:
: Does anyone have any arguments and possibly some C source code around
: pertaining to the second method?
A most excellent example of this, in all its simplicity, is in the C
source called "swar" available on the alt.sources.mac server, in volume8.
There's another one in C called Cellusoft Graphics Demo, also at the
site, but it's more complex and may not work right.
Of course, ant John Calhoun game source (Pascal) does this. Glypha II
(color) especially.
A third method is direct to screen drawing/animation. See the Arashi
source for this. v1.1 crashes an LC but v1.0 does not.
-Ken-
+++++++++++++++++++++++++++
>From ingemar@lysator.liu.se (Ingemar Ragnemalm)
Date: 2 Nov 1994 19:21:24 GMT
Organization: (none)
whsands@netcom.com (Tom Williams) writes:
> I am interrested in the different aproaches for storing all of a
>programs sprites for a project. In particular, a game. As I browse
>through many Mac Games' Resource Forks, I come across two common
>aproaches. The first is to have each sprite (usually no larger than
>32x32) contained in its own PICT resource. The second is to merge all
>the sprites into one big huge pict resource. The second aproach seems
>more logical since you could simply create a gworld, copy the entire pict
>into the gworld and then copybits the rects of the part of the image you
>want to display on the screen at one time.
The big advantage with keeping each sprite as a separate resource -
preferrably not a PICT but rather a "cicn" or icon suite - is that it
makes it much easier to match the icon and the mask. Editing icons
in ResEdit is easy in that respect.
With huge PICTs, matching the icon and the mask is much harder. Just imagine
the headache when you make a small change in an icon and have to make the
corresponding change in the mask! You also have to have some way to find
each sprite in the PICTs. The advantage is fast loading and smaller space
on disk.
For digestable (that means fairly small) source-code examples of both:
the PICT way: Cellusoft Graphics Routines (or whatever the name is - it's
different every time I see it uploaded). Both C and Pascal versions.
the icon way: OffscreenToys. Only Pascal until someone ports it.
Both should be available from the alt.sources.mac archive (see the a.s.m FAQ).
--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
+++++++++++++++++++++++++++
>From mhl@icf.hrb.com (mark)
Date: 2 Nov 94 16:39:39 EST
Organization: HRB Systems, Inc.
In article <398ork$aup@newsy.ifm.liu.se>, ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
> whsands@netcom.com (Tom Williams) writes:
>
>> I am interested in the different approaches for storing all of a
>>programs sprites for a project. In particular, a game.
>
> The big advantage with keeping each sprite as a separate resource -
> preferably not a PICT but rather a "cicn" or icon suite - is that it
> makes it much easier to match the icon and the mask. Editing icons
> in ResEdit is easy in that respect.
>
Personally I avoid the mask issue by using the "transparent"
mode in CopyBits. There are a few tradeoffs involved here.
1) The sprite (in my case a PICT) must appear on a white
(ForeColor) background. -- Not a problem in my case.
2) The sprite can not contain the color white (ForeColor). --
Again not a problem. What I do is create my sprites in
Photoshop, use the magic wand to select the background (white),
select similar (all white now selected) fill with one tick less
than white, reselect background, fill white. Now I do not need
to worry about masking in CopyBits because CopyBits does it for
me.
This also gives me the benefits of using a 'PICT' versus a
'cicn'. No size restriction. No color table restriction.
In addition, I have all the power of photoshop at my disposal.
Try creating a marble textured sphere in ResEdit's 'cicn'
editor. In Photoshop - Edit>Fill>Pattern, Filter>Distort>KPT
Glass Lens Bright. Quod erat demonstrandum.
Naturally, if the pixel map of your 'PICT' is larger than the
'cicn' you will notice a speed penalty. You may also have a
custom blitter that can do masking faster than CopyBits, but I
find this method quite acceptable.
--
Hope this helps.
Mark H. Linton
____________________________________________________________________