HDTenEightyP/NetNews huggingface dataset:
From: marek@nmsu.edu (Marek)
Subject: books on graphics
Organization: Computing Research Lab
Distribution: comp.sys.mac.programmer
Date: Fri, 2 Oct 1992 06:46:38 GMT

Hiya,
 Does anyone know of good book(s)that explain how to do graphics on a mac?
I'm looking more toward 3D graphics, and I am not really sure which type
would be the best for the task I will be working on.
If you're really interested in giving me a hand... read on.. otherwise..
just skip this part :)

ok. the full project is to model lighting on a supercomputer (yes.. I do
have access to a couple - I dont know which one I want to use either)..
and then send the rendered graphics to the mac. This will not be real time,
of course. The animation will run, and the user will have the option of
stopping it, changing the location of the "eye" and continuing to view it
from that angle. I realize this is quite ambitious for someone who has never
done any mac programming, but since I am part of a group of five.. and we have
until april of next year, I think we can pull it off. :)
 Any suggestions would be apprectiated, and any book titles/authors you can
provide would be great.
THanks :)
Marek 

______________________________
     __ _   __  ______
    / |/ | |  \ |_  _|     Marek R. Telgarsky
   /     | |  /   ||       marek@freedom.nmsu.edu
  /_/\/|_| ||\\   ||       mrtelga@ceratiidae.cs.sandia.gov
				
                   CASCA LIVES!!!!!!
Newsgroups: comp.sys.mac.programmer
From: D. Jay Newman <dn5@apix.psu.edu>
Subject: SndStartFilePlay() problems...
Organization: Penn State
X-Useragent: Nuntius v1.1
Date: Mon, 05 Oct 92 13:56:06 GMT

Hi:

I have been working on a program which needs to play several
fairly lengthy sounds from disk.  I now use the SndStartFilePlay()
function, because we couldn't tolerate the delays involved in
reading the entire sound into memory before starting to play
it.

For sound files longer than about 120,000 bytes long, it works fine.
For ones shorter than this, there is a "click" at the end of the sound;
whenever there is a click at the end of a sound, there is a click at
the beginning of the next sound.  This didn't happen when we read
the entire sound into memory first!

The sounds were recorded with MacRecorder at 22 kHz with no
compression, and saved as AIFF files.  The same thing happens if
the sound is saved as a resource file.  There is silence both before
and after each sound in the file.

I have used SndStartFilePlay both with a real sound channel and by
forcing it to create one.  It does the same thing each time.

As this is for language testing, I have little control over the sounds
themselves (they are generally voices, but could be other things).

If anybody can help me, I would appreciate it.

()()()()()()()()()()()()() CBEL--Teaching & Learning Technologies ()()()
D. Jay Newman     !  Cautious, careful people always casting about to
dn5@psuvm.psu.edu !  preserve their reputation and social standing never
dn5@apix.psu.edu  !  can bring about a reform.  -- Susan B. Anthony
Newsgroups: comp.sys.mac.programmer
From: mspace@netcom.com (Brian Hall)
Subject: Re: ADSP CTB Tool
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 4 Oct 1992 18:45:56 GMT

cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes:
>1) Is version 1.0 the latest version?

Yes.

>2) Is it possible to use this tool to connect 2 processes on the same Mac?
>(Don't ask why, or suggest AppleEvents. It's for debugging purposes, and I
>can't seem to make it work.)

Yes, but I seem to remember a problem and a work-around for it. Memory
is cloudy, but I think you will have problems if you use synchronous i/o
to an ADSP session on the same machine.  The solution being to write
you i/o to use asynch calls.

>3) Just what ARE the proper arguments to put into the configuration dialog
>box? The notes I got with the Basic Connectivity disk are sketchy at best.
>Can the tool use normal AppleTalk wild cards (i.e. "=") for specifying
>acceptable incoming hosts when "listening?"

Confusing, isn't it?
-- 

 \ | /   | Brian Hall                 mspace@netcom.com
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | The tornado ate my powerbook.
Newsgroups: comp.sys.mac.programmer
From: keith@taligent.com (Keith Rollin)
Subject: Re: WDEF's and QuickDraw globals
Followup-To: comp.sys.mac.programmer
Organization: Taligent
Date: Wed, 30 Sep 1992 20:53:04 GMT

In article <gemRrjq00iVgQ1o2Yn@andrew.cmu.edu>, ww10+@andrew.cmu.edu
(William Conrad Wojciechowski) wrote:
> 
> I was wondering if anybody has a reliable solution for accessing
> QuickDraw globals in a WDEF.  Right now, I am creating patterns and
> other needed globals on the fly.  This is a safe method but, I would
> like to know if there is a safe way to directly access the QuickDraw
> globals. 

I usually use routines like the following:

typedef struct {
	char		privates[76];
	long		randSeed;
	BitMap		screenBits;
	Cursor		arrow;
	Pattern		dkGray;
	Pattern		ltGray;
	Pattern		gray;
	Pattern		black;
	Pattern		white;
	GrafPtr		thePort;
} QDGlobals;

long*	GetA5(void) = 0x200D;			// move.l	A5,D0

Pattern*	GetWhitePattern()
{
	long*		curA5;
	curA5 = GetA5();
	return (Pattern*) (*curA5 - (sizeof(QDGlobals) - sizeof(Ptr)) + 
                    offsetof(QDGlobals, white));
}

-----
Keith Rollin
Phantom Programmer
Taligent, Inc.
Newsgroups: comp.sys.mac.programmer
From: crod@cc.curtin.edu.au (Scott Kevill)
Subject: HELP PLEASE: Fast B&W grafix at 4 or 8 bit colour depths
Organization: Curtin University of Technology
Date: Fri, 2 Oct 1992 02:06:59 GMT

Hello everyone.

I am writing a program that uses 1 bit (b&w) graphics on b&w and
colour machines. The program uses old-style b&w grafports and
an offscreen bitmap. When the monitor is set to black and white,
I get very fast CopyBitses (which is what I want), but at the 4
or 8 bit setting, the CopyBitsing performs extremely slowly.

Could anyone please tell me (or at least give a clue) the simplest
way to speed the 1 bit transfers at 4 and 8 bit monitor depths?

I would prefer not to have to do extensive changes to the program.
Would I have to use GWorlds? Would I have to give my window a
special CLUT and make it a colour window even though I am only
using it for black and white?

I have seen this problem in some black and white games where you
could adjust the game speed by adjusting the monitor setting so
it must be a common problem.

Any help would be GREATLY appreciated.

Thanks,

Scott

P.S. -- Please email me - If there is enough interest, I will post
                          a summary of any responses I get.

+-----------------------+--------------------------------------+
I Scott Kevill          I   "Be like me, be original"          I
I crod@cc.curtin.edu.au I                              -- Me   I
+-----------------------+--------------------------------------+
Newsgroups: comp.sys.mac.programmer
From: BLOOMDA@ctrvax.vanderbilt.edu (_creative_output_)
Subject: posting a Quit event to the finder...?
Organization: Camp Vanderbilt Vision Research Center
Date: Tue, 29 Sep 1992 23:35:27 GMT
X-News-Reader: VMS NEWS 1.21

Hi.

Several folks out there have written pieces of code which quit the Finder,
presumably using AppleEvents to post a Quit event to the finder.  I'm thinking
of Kill Finder, AntiFinder, and System 7 Menus (which can put a 'quit' menu
on the bar).  I'd like to include that functionality in my own applications,
so if anyone out there has done this, could you post or email to me the few
lines of code necessary?

I could (and probably will, eventually) find some department money to buy
IM v.6, but I thought I'd ask here first, perhaps because I'm lazy, but also
to give me the opportunity to expand here on a previous post of mine.

  I'd asked for help with a problem I encountered under system 7, which acts
  like MultiFinder always and occasionally steals time from me, making the
  occasional frame in my carefully orchestrated visual displays last for
  several VRTs longer than it should.  Not rigorous science.  I posted on
  both c.s.m.prog & c.s.m.system, and got no response.

  Well, it turns out that quitting the Finder takes care of this.  My frames
  now march by in regular time like well-trained ducks.  Any researchers in
  vision should take note!  The documentation I've seen with the above-
  mentioned products does not mention this benefit.  Of course, it probably
  means nothing to anyone not attempting rigorous visual displays.

ciao!					= Dave Bloom
					  Vanderbilt U. Vision Research Center

"The day has its eyes,
 and the night has its ears."	- Arabian saying, from _Moon_Over_Morocco_,
							by ZBS Foundation
Newsgroups: comp.sys.mac.programmer
From: rmf@chopin.cs.columbia.edu (Robert M. Fuhrer)
Subject: Re: What does DrawPicture() want?
Followup-To: comp.sys.mac.programmer
Organization: Computer Science Dept., Columbia Univ.
	<lsr-250992163555@lsr.taligent.com> <38962@unix.SRI.COM>
	<lsr-280992140500@lsr.taligent.com>
Date: Sun, 4 Oct 1992 04:37:20 GMT

I have received a couple of responses to my posting regarding my problem
installing a PicHandle in a window. Thanks to those who responded for their
help! Now, a summary of the results:

One person advised calling ClipRect() before the call; though I wasn't doing it
before, adding a call didn't help. Another mentioned that SetWindowPic() was a
trivial call; after disassembling it in Macsbug, I saw that that was true; it
does literally stuff the handle in the window record field and return.

I started to suspect other problems, probably memory-related. I tried using
Macsbug "heap spy"; this turned up nothing. However, when I did a heap dump, I
noticed that a control handle for an active modal dialog was unlocked and
purgeable. I suspected this might be a problem. Does this sound reasonable?

Unfortunately, locking the handle didn't solve the problem anyway. Any other
clues?

This snooping did lead to another confusing problem:

I have a modal dialog which has a scroll bar control item in it. The item's
type is thus "control" (4), and the sub-type is scroll-bar (3). If I look at
the DITL resource in ResEdit, the item number is 15. (Which is good, because my
Rez source builds it that way.) Now, when I do a GetDItem() on item #15, it
returns a handle which doesn't match the handle Macsbug reports as the only
CTRL handle in the application. [It always seems to be off by 4 bytes.]

Am I missing something here?
--

-- Bob
Newsgroups: comp.sys.mac.programmer
From: Andreas Wuertz <wuertz@tik.ethz.ch>
Subject: Re: Q: How to tell the depth of screen?
Organization: Federal Institute of Technology
X-Useragent: Nuntius v1.1
     <1992Oct1.003256.10649@tamsun.tamu.edu>
Date: Thu, 1 Oct 1992 08:19:46 GMT

In article <1992Sep30.185610.3998@hobbes.kzoo.edu> Jamie R. McCarthy,
k044477@hobbes.kzoo.edu writes:
>Both mono and color 12" are 512x384.

Is there a special bw monitor for the LC? Because the standard bw 12"
monitor has 640x480 pixels. 512x384 is right for the 12" colour monitor.
By the way: Start ResEdit 2.1 and create/open a ALRT, DLOG or WIND
resource. You'll get a menu called 'MiniScreen' which has all the current
sizes in it.

Andy (wuertz@tik.ethz.ch)

========================================================================
The only person who got all his work done by Friday was Robinson Crusoe.
========================================================================
Newsgroups: comp.sys.mac.programmer
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: Help: Sample code wanted
Followup-To: comp.sys.mac.programmer
Organization: NCRPDA, Curtin University
Date: Tue, 29 Sep 1992 03:12:26 GMT

In article <1992Sep25.114657.15843@husc3.harvard.edu>, Manuel Veloso
<veloso@husc9.harvard.edu> wrote:
> 
> In article <1992Sep24.171411.7499@nrtpa038.bnr.ca> Ted Lowery,
> tbl@rock.concert.net writes:
> >If you have any code you would like to pass along, or know the exact
> location 
> >of any (server, filename, path and all), please e-mail me back.

> what you've got to do is, when your init is run,
> 1) do any initializations which change actual code data,
> 2) create a new ptr in the system heap,
> 3) copy your init (shutdownproc, in this case) into the new pointer.
> 4) now install your shutdown proc (ShutDwnInstall)

> because your resource/init goes away after the INIT31 closes your 
> resource file (&demolishes the heap you're in). 

An alternative that is often used is to mark your INIT resource as System
Heap and Locked, and then you just need to detach the resource before
INIT31 gets a chance to close your res file.  So the only tricky bit is how
to get your address, which is conviniently placed in the ToolScratch
global.

Handle me;

me = RecoverHandle(ToolScratch);
DetachResource(me);

(you could add an HLock(me) in, but if the resource bits aren't set to
system heap its going to fail anyway when INIT31 trashes the current
"application" heap, so basically, make sure the resource bits are set
correctly!)

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       peter@cujo.curtin.edu.au
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: +61 9 367 8141
From: mkelly@mystix.cs.uoregon.edu (Michael A. Kelly)
Newsgroups: comp.sys.mac.programmer
Subject: C.S.M.P. Digest V1 #173 Available
Date: 4 Oct 92 11:03:46 GMT
Article-I.D.: cs.1992Oct4.110346.29618
Followup-To: poster
Organization: University of Oregon Computer and Information Sciences Dept.


C.S.M.P. Digest             Sun, 04 Oct 92       Volume 1 : Issue 173

Today's Topics:

	Beginner's question on StandardPutFile
	Hacking Think_C Malloc, need big free!
	GetPictInfo bug with QuickTime Picts?
	Is there a PD console package for Mac?
	Fortran callable rountines in THINK C
	Dylan and Newton PDAs
	Packing Rects into the smallest possible container
	Directory Scan Revisited



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

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

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

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to LISTSERV@ricevm1.rice.edu for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to mkelly@cs.uoregon.edu.


-- 
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
mkelly@cs.uoregon.edu                             Computer Science Department
_____________________________________________________________________________
From: eijkhout@cupid.cs.utk.edu (Victor Eijkhout)
Newsgroups: comp.sys.mac.programmer
Subject: Symantec & Borland connection?
Date: 28 Sep 92 16:46:02 GMT
Organization: University of Tennessee, Knoxville - Department of Computer Science
Distribution: world
Reply-To: eijkhout@cupid.cs.utk.edu (Victor Eijkhout)
NNTP-Posting-Host: cupid.cs.utk.edu

Hello,

last week I bought Think Pascal, and started porting a program
that I once wrote on teh IBM PC in Borland Turbo Pascal.
Now, both Pascals use modules, which are not standard. And the
way they realize modules are virtually the same. (And very much
different from a modular Pascal that I once used on the Atari ST.
That one had the best module structure, by the way.)

So I was wondering:
Is there a connection between Symantec and Borland?

Victor.

Newsgroups: comp.sys.mac.programmer
From: Anders Wallgren <anders@verity.com>
Subject: Re: Gestalt Return Value for 24-bit addressing?
Organization: Verity, Mountain View, CA, USA
Date: Fri, 2 Oct 92 20:52:56 GMT
X-Xxmessage-Id: <A6F205949801C897@pokey.verity.com>
X-Useragent: Nuntius v1.1.1d11
X-Xxdate: Fri, 2 Oct 92 21:56:36 GMT

In article <BvHx65.1t9@world.std.com> Andrew E Page,
aep@world.std.com writes:
>    What does the Gestalt Trap return when 24-bit addressing is
>in effect?  It returns a 0,1, or 2 when various flavors of 32-bit
>is in effect, at least according to GestaltEqu.a.  Or does it
>simply pass back a non-zero result code in D0?

Bit 0: 32-bit addressing mode
Bit 1: 32-bit clean System Heap
Bit 2: Machine is 32-bit capable

In your case, I would probably test if bit 0 is off.
Newsgroups: comp.sys.mac.programmer
From: j.cook@primerd.prime.com (C. James Cook)
Subject: Re: CopyBits Note
Organization: Prime Computer R&D
Date: Sat, 26 Sep 1992 22:47:49 GMT

lsr@taligent.com (Larry Rosenstein) writes:
> In article <1992Sep25.182632.12148@terminator.cc.umich.edu>,
> krk@itl.itd.umich.edu (Kenneth Knight) wrote:
> > 
> > I can explain some of this, though maybe not all. When you create a window
> > you define a specific size for it. The appropriate amount of memory is
> > allocated to that window's bit or pix-map based on the size and depth
> 
> I don't think that's right.  All the windows on the screen refer to the
> same set of pixels.  The baseAddress and rowBytes should be identical.  The
> bounds rect determines where the window is on the screen.
> 
> In article <1992Sep25.125700.20992@primerd.prime.com>, Jim Cook
> <J.Cook@ENS.Prime.COM> wrote:
> > 
> > However, if you are randomly copying from the screen, particularly outside
> > any given window's boundaries, you cannot use any window ptr, but must use
> > the window manager's port as returned by GetCWMgrPort. i.e.
> 
> Not every window will be a color window, so if you are picking a random
> window, you have to test before casting it to a CGrafPtr.  

Let me confirm/expand:
1. Yes, the pixmaps for all windows as well as the window manager ultimately 
   point to the <<same>> video ram, which was big enough to be the source in 
   the copybits call.  If they weren't, you would expect a bus error 
   referencing non-existant memory, not memory overflows.
2. Both the screen depth and therefore the source PixMap as well as all windows
   as well as the destination GWorld (i.e. everything) were all 32 bits deep.

Bottom line: I don't think we've hit the answer.  Is it worth emailing the
current copybits expert (who? Bruce Leak?) or sending it in as a question for 
develop or MacDTS?

Cie la vie.
J
Organization: Penn State University
Date: Sat, 26 Sep 1992 13:07:30 EDT
From: <BXX1@psuvm.psu.edu>
Newsgroups: comp.sys.mac.programmer
Subject: Help for CALL COLOR QUICKDRAW

Hi there,

I'm trying to use Mac Fortran II to call the color Quickdraw. I tried to use
the RGBForeColor() function, but it seems failed. I cannot use the RGBColor
record.

Thanks in advance.

Ben
Newsgroups: comp.sys.mac.programmer
Subject: Re: If I have the old, do I need to buy the new Inside Mac?
From: hammett@sbsu1.aukuni.ac.nz (Tim Hammett)
Date: Thu, 1 Oct 1992 20:37:25 GMT
Organization: University of Auckland, New Zealand.
Keywords: Inside Mac

k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>Do I remember right that a year's subscription to the developer CD runs
>something like $30?  (If you can confirm or correct this, please email
>me.)  If so, and if you have a CD-ROM drive--snap it up.  If you don't

This isn't totally correct - a year's subscription to develop (which includes
four of that year's developer disks) costs $30 to US subscribers.

The full developer mailing (12 CD's per year, plus the occasional other
goodie, but excluding any betas) is available from APDA, & costs around
$250 + shipping (which is substantial).

(^^ I don't have my APDA catalog handy, so I'm not totally sure of the $250
figure, but it's that order of magnitude).

--
Tim Hammett, Botany Dept, Auckland University, New Zealand.
t.hammett@aukuni.ac.nz   Phone: +64-9-373-7599 x8365    FAX: +64-9-373-7416
From: sdorner@qualcomm.com (Steven Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HOpen confusion
Date: 27 Sep 92 15:46:28 GMT
Followup-To: comp.sys.mac.programmer
Organization: Qualcomm, Inc

In article <BuxnG8.8Fo@unx.sas.com>, Michael Hecht
<Michael_Hecht@mac.sas.com> wrote:
> * Is ioMisc still used for Opens? IM-IV says I should set it to NIL or to
> an I/O buffer. IM-Files doesn't say anything about it with regards to the
> HOpen family. [Omission?????]

Set it to NIL.  I had a very disturbing experience with ioMisc.  My program
would crash at more or less random times.  No matter where I set
breakpoints, it would crash somewhere else; but only on MacPlusses and
SE's; II's and up were fine.  All these machines were running whatever was
current at the time (6.0.5, I think).

The culprit was ioMisc.  I was failing to zero it, and this made SE's and
Plusses go bonkers (at unpredictable times, since the buffer's only used
when a track needs to be transferred), whereas it didn't affect II's at
all.

I concluded from this that ROM's since the II's must ignore ioMisc on
opens.  However, I wouldn't bet my life on it, and you don't want to cut
off SE's and Plusses (SE's especially, since they're better machines than
Classics).
Newsgroups: comp.sys.mac.programmer
From: tree@kira.uvm.edu (Tom Emerson)
Subject: Re: Think C and ResEdit
Organization: University of Vermont, EMBA Computer Facility
Date: Tue, 29 Sep 1992 14:19:14 GMT

In article <1992Sep29.002900.5889@igor.tamri.com> donb@igor.tamri.com (Don Baldwin) writes:

   1. My Mac is a Powerbook 100 with 2/20; I intend to upgrade to 6 Megabytes
      of RAM.  Is there any reason I shouldn't run Think C on it?  The Think C
      box does say that MultiFinder is needed to run the debugger but I don't
      have MultiFinder (I inderstand that 7.* doesn't keep the MultiFinder
      around).  Does anyone know if I'll be able to use the debugger???

If you are running System 7.x then you can run the debugger with THINK C. The
advent of System 7 made MultiFinder obsolete (and the box should be changed to
reflect this)

   2. Can anyone recommend a good ResEdit book?  I saw Zen and the Art of
      ResEdit (includes disks) and one other book this past weekend; I'd
      appreciate any pointers to exceptional references.

Apple's ResEdit Reference is excellent, IMHO: it tells you everything you need
to know about using the program, contains an introduction to resources, and is
an excellent reference. I haven't looked at any of the other books... I really
don't understand the need.

Tom
--
   Tom Emerson                                    Technical Support
   Language Products Group                     Symantec Corporation
			Internet: tree@uvm.edu
Newsgroups: comp.sys.mac.programmer