From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-031 Date: Fri, 27 May 94 14:27:48 MET DST C.S.M.P. Digest Fri, 27 May 94 Volume 3 : Issue 31 Today's Topics: Any good Mac C books? Basic, basic windows & PICT drawing Help: Palette translation in CopyBits How do I draw masked icons w-System 6? Motorola announces Power Mac compilers Polling the Serial Port 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 as comp.sys.mac.programmer.src. ------------------------------------------------------- >From ralcasid@tech.iupui.edu (Peter R Alcasid) Subject: Any good Mac C books? Date: Fri, 29 Apr 1994 16:37:47 GMT Organization: Purdue University School of Engineering & Technology at Indianapolis,IN I'm intrested in programming the Mac using Think C. Does anyone know of any good books that gives a step by step tutorial on how to program the Macintosh (i.e. accessing the Toolbox using C). I've got Inside Macintosh: Macintosh Toolbox Essentials but everything is in PASCAL! Any suggestions would be appretiated. Ron Alcasid +++++++++++++++++++++++++++ >From jtbell@presby.edu (Jon Bell) Date: Sat, 30 Apr 1994 11:05:08 GMT Organization: Presbyterian College, Clinton, South Carolina USA In article , Peter R Alcasid wrote: >I'm intrested in programming the Mac using Think C. Does anyone know of any >good books that gives a step by step tutorial on how to program the Macintosh >(i.e. accessing the Toolbox using C). "Macintosh C Programming Primer", by Dave Mark and Cartwright Reed, published by Addison-Wesley. It's in two volumes. -- Jon Bell Presbyterian College Dept. of Physics and Computer Science Clinton, South Carolina USA +++++++++++++++++++++++++++ >From rfblec@sunfish.usd.edu (Bob "Skippy" Blechinger) Date: Wed, 4 May 1994 10:31:01 GMT Organization: University of South Dakota ralcasid@tech.iupui.edu (Peter R Alcasid) writes: >I'm intrested in programming the Mac using Think C. Does anyone know of any >good books that gives a step by step tutorial on how to program the Macintosh >(i.e. accessing the Toolbox using C). I've got Inside Macintosh: Macintosh >Toolbox Essentials but everything is in PASCAL! Any suggestions would be >appretiated. >Ron Alcasid Ron, Try "Learn C on the Macintosh" by Dave Mark; it comes with a "lite" version of Think C, *and* it comes with an upgrade offer to the *full* Think C for only $129 (this might have changed since I got mine, though) After that, you can step up to the "Macintosh C Programming Primer", by Dave Mark & Cartwright Reed; it's a 2-volume set, and again, quite good... Hope this helps! -Bob Blechinger AppleCore of Siouxland Mac Software Director Sioux Falls, South Dakota rfblec@sunfish.usd.edu +++++++++++++++++++++++++++ >From dmoney@magnus.acs.ohio-state.edu (Dean R Money) Date: 4 May 1994 16:31:48 GMT Organization: The Ohio State University Bob "Skippy" Blechinger wrote: >ralcasid@tech.iupui.edu (Peter R Alcasid) writes: >>I'm intrested in programming the Mac using Think C. Does anyone know of any >>good books that gives a step by step tutorial on how to program the Macintosh >>(i.e. accessing the Toolbox using C). I've got Inside Macintosh: Macintosh >>Toolbox Essentials but everything is in PASCAL! Any suggestions would be >>appretiated. > > Try "Learn C on the Macintosh" by Dave Mark; it comes with a "lite" >version of Think C, *and* it comes with an upgrade offer to the *full* >Think C for only $129 (this might have changed since I got mine, though) > > After that, you can step up to the "Macintosh C Programming Primer", by >Dave Mark & Cartwright Reed; it's a 2-volume set, and again, quite good... I would agree. Those three books, along with Inside Mac I, II, V, and VI, not only got me started in programming on the Mac, but helped me learn C from scratch. I did know Pascal before, though, so it wasn't difficult for me to understand the Pascal examples in IM, and make Toolbox calls in C. Dean. +++++++++++++++++++++++++++ >From susanlesch@aol.com (SusanLesch) Date: 4 May 1994 23:33:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , rfblec@sunfish.usd.edu (Bob "Skippy" Blechinger) writes: > Try "Learn C on the Macintosh" by Dave Mark; it comes > with a "lite" > version of Think C... Oh, dear, no. I would _not_ recommend "Learn C on the Macintosh" to anyone seriously interested in learning the C language. There is no formal definition of all data types, little rigor, and a casual attitude that does not lend itself to the difficulties of IM. I wish I could suggest an alternative, but I must leave that to others. For examples, that are, sadly, fairly representative of the book on the whole: "long" is never defined, mentioned once. "continue" is not in the book. There is an incomplete definition of the "if" statement, both in the text and the appendix, leaving out the essential form "if else"! I believe LCOM causes more harm than good. +++++++++++++++++++++++++++ >From susanlesch@aol.com (SusanLesch) Date: 5 May 1994 00:28:02 -0400 Organization: America Online, Inc. (1-800-827-6364) Sorry, I believe in an earlier post I said "if else" is not in "Learn C on the Macintosh". It is "else if" that's missing. (We're having AOL problems and I can't retrieve what I said.) While I have the book out, the cover blurb says, among other things, "reference material, including glossary, Standard Library functions, and a C syntax reference." If that's C's syntax, we're all in trouble. For shame, Addison-Wesley. +++++++++++++++++++++++++++ >From ojtv@sun3.oulu.fi (Olli Vuolteenaho) Date: Fri, 6 May 1994 15:55:15 GMT Organization: University of Oulu, Department of Physiology SusanLesch (susanlesch@aol.com) wrote: : Sorry, I believe in an earlier post I said "if else" is : not in "Learn C on the Macintosh". It is "else if" that's : missing. (We're having AOL problems and I can't retrieve : what I said.) : : While I have the book out, the cover blurb says, among : other things, "reference material, including glossary, : Standard Library functions, and a C syntax reference." If : that's C's syntax, we're all in trouble. For shame, : Addison-Wesley. Sorry for my ignorance, but what kind of special definition would "else-if" need? It isn't specifically defined, for example, in Turbo C/C++ reference manual either, is it. I don't have as pessimistic opinion about Learn C on the Macintosh as you do. If you have programming experience it feels awfully slow-paced, but then it wasn't written for you. I think that it presents the basics of C in an entertaining way, it might even encourage someone to explore programming deeper, unlike, for example, Lippman's C++ primer that I've often seen recommended as the first book on (C++) programming (it's an excellent book for the more experienced, though). And BTW, 'long' is explained on p. 207 of my LCOM. Olli +++++++++++++++++++++++++++ >From susanlesch@aol.com (SusanLesch) Date: 7 May 1994 00:48:07 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <1994May6.155515.10438@ousrvr.oulu.fi>, ojtv@sun3.oulu.fi (Olli Vuolteenaho) writes: > what kind of special definition would "else-if" need?... For a comparison, take the Waite Group's New C Primer Plus. There are three forms described for the if statement: if, if-else, and if-else if-else. Lacking else-if, a newbie (like me :-) might wind up with nested if's, sort of like wasting time with case statements. > [Learn C on the Macintosh] presents the basics of C in an > entertaining way, it might even encourage someone to > explore programming deeper Sure, entertainment is part of education. But if substance is forfeited in exchange, I am worried. Perhaps if the book were titled "Learn C Basics on the Macintosh", I wouldn't object so much. It's the reader being led to think this is comprehensive C that offends me. I'd also like to be taught good habits and structure. On another tack, take the first incarnation of HyperCard, which was presented in an equally "entertaining way" and could "encourage" someone to "explore programming deeper". The problem here is similar. An informal definition of a language, perhaps encouraging lackadaisical programming practices, without mention of error-checking is _lots_ of fun! > And BTW, 'long' is explained on p. 207 of my LCOM. Yes, in passing, in the middle of an exercise on dice rolling, in a chapter titled "Variable Data Types" that doesn't define them. Where is the formal presentation of data types? Again using New C Primer Plus as a comparison, long, int, char, unsigned, float, and double are neatly presented in one chapter (3). Thank you for responding, by the way. Mr. Mark's books are extremely popular, and I would not expect many people to agree with my assessment of Learn C on the Macintosh. +++++++++++++++++++++++++++ >From nick@pitt.edu ( nick.c ) Date: 7 May 94 20:55:24 GMT Organization: (none) In Article <2q9pdh$1fj@search01.news.aol.com>, susanlesch@aol.com (SusanLesch) wrote: > I would _not_ recommend "Learn C on the Macintosh" to > anyone seriously interested in learning the C language. > There is no formal definition of all data types, little > rigor, and a casual attitude that does not lend itself to > the difficulties of IM. While I disagree with this assessment of _Learn_C_on_the Macintosh_ (I'm reading the C++ version now, and find it quite informative, as I found the C one), if you want rigor and less casual an aproach (and even if you don't) you should have a copy of Kernigan and Ritchie. This is probably stating the obvious, but since it is the *definitive* work, you should have a copy - no matter what you're doing with C. _/ _/ _/ _/_/_/ _/ _/ Sea Shells to C shells, Waikiki to _/_/ _/ _/ _/ _/ _/_/_/ the Internet, a wave, is a wave... _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ CompSrv: 71232,766 I-Net: Nick@pitt.edu +++++++++++++++++++++++++++ >From thundero@news.delphi.com (THUNDERONE@DELPHI.COM) Date: 9 May 1994 04:07:27 -0000 Organization: Delphi Internet Services Corporation nick@pitt.edu ( nick.c ) writes: >In Article <2q9pdh$1fj@search01.news.aol.com>, susanlesch@aol.com >(SusanLesch) wrote: >> I would _not_ recommend "Learn C on the Macintosh" to >> anyone seriously interested in learning the C language. >> There is no formal definition of all data types, little >> rigor, and a casual attitude that does not lend itself to >> the difficulties of IM. > While I disagree with this assessment of _Learn_C_on_the > Macintosh_ (I'm reading the C++ version now, and find it quite > informative, as I found the C one), if you want rigor and > less casual an aproach (and even if you don't) you should have > a copy of Kernigan and Ritchie. This is probably stating the > obvious, but since it is the *definitive* work, you should have > a copy - no matter what you're doing with C. If you're learning C++ from Learn C++ on the Macintosh, you're going to have serious problems using C++ for any medium to large-sized project. I agree with Susan on "Learn C.."- I know of no one who has actually learned good C programming from it. There are *good* C (and C++) books out there. They usually assume you have a PC or Unix, but so does "Learn C on the Macintosh" (printf and fopen are not Macintosh calls, you see). Get one of them instead. You might find the C++ book "quite informative," but that doesn't change the fact that it does not teach correct use of C++. Among other things, it does not mention virtual destructors once. It says that because constructors *never* return anything, one should not allocate memory in them, and discusses a "two-stage" workaround for this "problem." It does not teach proper inheritence theory. A review I read of the book in DDJ mentioned that the book would only be useful as a doorstop. I happen to agree. Chris +++++++++++++++++++++++++++ >From $stephan@sasb.byu.edu (Stephan Fassmann) Date: 9 May 1994 18:39:34 GMT Organization: Brigham Young University In article <2qkctv$suu@news.delphi.com> thundero@news.delphi.com (THUNDERONE@DELPHI.COM) writes: >If you're learning C++ from Learn C++ on the Macintosh, you're going >to have serious problems using C++ for any medium to large-sized >project. I agree with Susan on "Learn C.."- I know of no one who has >actually learned good C programming from it. There are *good* C (and >C++) books out there. They usually assume you have a PC or Unix, but >so does "Learn C on the Macintosh" (printf and fopen are not Macintosh >calls, you see). Get one of them instead. How about a nice list, Because I would like to get some books on Mac c/C++ programing. Stephan Fassmann InterNet: $stephan@sasb.byu.edu GEnie: S.FASSMANN carpe diem carpe noctem +++++++++++++++++++++++++++ >From Joe_Cabrera@bmugbost.uu.holonet.net Date: Tue, 10 May 1994 02:41:47 EST Organization: BMUG Boston >> I believe ["Learn C on the Macintosh" by Dave Mark] causes more harm than good.<< Can you offer an alternative text to use, then? I'm also beginning to learn C and LCOM doesn't feel like a "serious" enough book to begin learning C from. I also have the Waite group's New C Primer Plus. Is that any better? (As you can see, since I'm just beginning, I'm more interested in learning C itself rather than how it applies directly to the Mac yet.) -BMUG Boston 617-721-5840, East Coast BBS of The World's Largest Mac User Group +++++++++++++++++++++++++++ >From susanlesch@aol.com (SusanLesch) Date: 10 May 1994 17:21:04 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <1994May10.024147.694130@bmugbost.uu.holonet.net>, Joe_Cabrera@bmugbost.uu.holonet.net writes: >> I believe ["Learn C on the Macintosh" by Dave Mark] causes more harm than good.<< (-SGL) > I also have the Waite group's New C Primer Plus. Is that > any better? (-JC) Well, I am no expert, and am as interested in seeing the names of some good books as anyone. I used "New C Primer Plus" and loved it. The comparisons between K&R and ANSI C are simply great. As the only caveat, I skimmed the PC / Unix / DOS sections on command lines for the most part, keeping in mind that the authors tried to be somewhat Macintosh and THINK C aware. My vote says yes, by all means, use it. "New C Primer Plus" is being used on America Online to teach C right now in a cross-platform class in their online Programmer U, if I'm not mistaken. +++++++++++++++++++++++++++ >From Chris Hanson Date: Wed, 11 May 94 06:50:50 -0600 Organization: Green Dragon Creations, Inc. In article <$stephan.3540.0@sasb.byu.edu>, Stephan Fassmann writes: > > In article <2qkctv$suu@news.delphi.com> thundero@news.delphi.com (THUNDERONE@DELPHI.COM) writes: > >If you're learning C++ from Learn C++ on the Macintosh, you're going > >to have serious problems using C++ for any medium to large-sized > >project. I agree with Susan on "Learn C.."- I know of no one who has > >actually learned good C programming from it. There are *good* C (and > >C++) books out there. They usually assume you have a PC or Unix, but > >so does "Learn C on the Macintosh" (printf and fopen are not Macintosh > >calls, you see). Get one of them instead. > > How about a nice list, Because I would like to get some books on Mac > c/C++ programing. > > Stephan Fassmann InterNet: $stephan@sasb.byu.edu GEnie: S.FASSMANN > carpe diem carpe noctem "Practical C Programming" from O'Reilly & Associates is one of the best C books out there. It assumes UNIX -- it is an O'Reilly book, after all. :-) TTFN, Chris +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Thu, 12 May 1994 01:11:39 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) I wouldn't recommend Dave Mark's "Learn C on the Mac" as a first Mac C book. Dan Parks Sydow (DanParks@aol.com) has put out two great beginner and beginner/intermediate Mac C books. They illustrate what they discuss. Get "Think THINK C!" first. This will get you well into the idea, concept and viewpoint of programming on a MAC (leave the DOS C books alone for a while). Once you get that, and get through it, get Think C 5.0.4, since it's simplest and most available example source runs on it without complication. Also get at least old volume I and II of Inside Mac (if you're low on funds. If not, get all current IM volumes available. Read the IM on what you have already learned, so you can see what the explanations connect with, anh how. That way, when you read on something you haven't learned, you'll be better able to make a connection. Once you've gotten into it you can kind of tell which way to go from there. I'd recommend Dan's second book - Macintosh Programming Techniques - to drive in the foundation of what you'll need to go on. Then get the Primer books and their disks (saves typing all that in - or scan and OCR it). Many other books are just example sourc and explanations with some new (to the beginner) how-to. If you want details on specifics, like ANSI C stuff, get The C Programming Language (the "K&R" book). The Think C 5.x Standard Libraries manual is excellent, too. But a major source of "how to program" is example source. Download as much as possible. Example code that runs is a competent programmer telling you HOW to do some aspect of programming. "Competent" simply means he or she wrote a program that runs. It may not be optimumly coded, but it does run. "How do I write a Main Event Loop?" I look at as many Main Event Loops in as many example source projects as it takes to get the idea of how they are done. This shows differences, similarities and identities among them, and I can spot how and where to put modifications in. So, those two books, TC 5 (you can update later), New Inside Mac andas much example C source as you can get. Straight Think C source is the vast majority of example source you'll find. Not Pascal, not C++. Go with the flow. -Ken- --------------------------- >From bsa3320@u.cc.utah.edu (Brandon Allen) Subject: Basic, basic windows & PICT drawing Date: 13 May 1994 14:13:59 -0600 Organization: University Of Utah Computer Center Somebody posted, asking for simple code regarding windows and displaying PICT's. I can't find the thread now, but here is a bit of code that may prove instructive. I hope it's not TOO basic for you. I'd be happy to answer any other questions (for which I have answers). Just e-mail me, if you like. I don't know it all, but I'll be glad to tell you what I do know. ___________________________________________________________________________ { Ok, I'm assuming that you know how to create } {WIND & PICT resources using ResEdit . } { The first thing you'll need to do is load the} { WIND data using the GetNewCWind call, } { this function will return a WindowPtr to } { the window you are creating.} PROGRAM ShowAWindow; VAR myWindow: WindowPtr; { A pointer to your window data } windowID: Integer; { ID number of your WIND resource } pictureID: Integer; { ID of your Pict resource } myPicture: PicHandle; { Handle to the PICT } myRect: Rect; { A rectangle that will enclose the PICT } { when it is drawn } BEGIN windowID := 666; { Or whatever number you choose as } { your resource ID } myWindow := GetNewCWindow(windowID, NIL, WindowPtr(-1)); { Now, the nil after the windowID tells } { the Mac to allocate some new memory for } { your window, rather than using some } { that you have already allocated for it. } { The WindowPtr(-1) tells the computer } { which window to display the new } { window BEHIND. For instance if you } { wanted your new window to appear behind } { a window whose data was contained in a } { variable called frontWind, then you } { would use frontWind instead. In this case } { we want this window to be the } { front-most window, so we send a } { WindowPtr that points to the value -1. } { This is a standard value that tells the } { computer not to display your window } { behind any other window. } SetPort(myWindow); { Now that we have created and displayed } { our window where we want it, we } { designate it as the current graphics port. } { This means that any drawing you } { do in your program will occur in this window. } myPicture := GetPicture(pictureID); { This call loads your PICT resource into memory } IF myPicture <> NIL THEN BEGIN myRect := myPicture^^.picFrame; DrawPicture(myPicture, myRect) END; { This bit of code ensures that the previous call } { to GetPicture was successful. If the PICT had } { not been loaded, myPicture would contain NIL. } { If it doesn't contain NIL, we'll go ahead and draw } { it into our window with the DrawPicture call. } { Obviously myPicture is the handle we just } { created with the GetPicture call. myRect is } { the rectangle into which the picture will be } { drawn. This Rect is in local coordinates for } { your window (0,0 corresponds to the upper } { left hand corner of your window, not of } { the screen). If myRect is different from the } { size of your PICT, QuickDraw will resize it } { automatically. Thus, the assignment of the } { PICT's Rect (myPicture^^.picFrame) to } { myRect keeps the PICT at its original size. } { The rest of your program here ... } END. --------------------------- >From jonbl@microsoft.com (Jon Blossom) Subject: Help: Palette translation in CopyBits Date: Tue, 3 May 1994 01:14:07 GMT Organization: Microsoft Corporation I'm trying to create an off-screen GWorld whose palette matches the palette of the window I'm copying to. What happens is that I set up a palette, say entry 3 is red, and set it up for both the GWorld and the window. Then I poke a 3 somewhere into the GWorld memory, but when I call CopyBits(), the color's been translated to something else. If I do a PmForeColor(3) then poke the result of a GetForeColor(), I get the correct results. Somewhere, QuickDraw is remapping colors. Anyone know how to prevent QuickDraw from remapping so that I have an identity relationship between the color table in my off-screen GWorld and the palette in my window? I don't want to have to go through this cheesy translation step! Thanks -Jon Blossom jonbl@microsoft.com +++++++++++++++++++++++++++ >From u9119523@sys.uea.ac.uk (Graham Cox) Date: Fri, 6 May 1994 16:33:02 GMT Organization: School of Information Systems, UEA, Norwich In article , jonbl@microsoft.com (Jon Blossom) wrote: > I'm trying to create an off-screen GWorld whose palette > matches the palette of the window I'm copying to. > > What happens is that I set up a palette, say entry 3 > is red, and set it up for both the GWorld and the window. > Then I poke a 3 somewhere into the GWorld memory, but > when I call CopyBits(), the color's been translated to something > else. > > If I do a PmForeColor(3) then poke the result of a GetForeColor(), > I get the correct results. > > Somewhere, QuickDraw is remapping colors. > > Anyone know how to prevent QuickDraw from remapping so that I > have an identity relationship between the color table in my > off-screen GWorld and the palette in my window? I don't > want to have to go through this cheesy translation step! > > Thanks > > -Jon Blossom > jonbl@microsoft.com Gosh, someone at Microsoft asking how to do things properly! Whatever next! I suppose I should be nice and try and help, though actually I don't know the exact answer. However, it is definitely documented in Inside Mac VI in the Palette Manager chapter. You have to set up your GWorld colour table to the be the same as the window's colour table, then build a palette for the window which uses Animated Colours. Then you can draw using indexed values. However, do you NEED to do this? (examine the problem carefully). Normally you should be working with RGB Colours, and drawing using QuickDraw into the GWorld- life will be easy if you do it this way, and don't try to draw with indexes. Of course, there are times when you might legitimately want to do this, but as I don't know what the problem is in this case, then it's hard to be sure. One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image directly- this is a sure fire way of making a program incompatible with the video device. If QuickDraw doesn't know about the contents of an image (because you bypassed it) you will almost certainly not end up with what you want. Please do it right- I know we all love to hate MS products on the Mac, but they COULD be really good if more people like you asked questions!!! - ------------------------------------------------------------------------ Graham -Everyone is entitled to their opinion, no matter how wrong they may be... - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 7 May 94 10:59:55 MST Organization: (none) In article , u9119523@sys.uea.ac.uk (Graham Cox) writes: > In article , jonbl@microsoft.com (Jon Blossom) > wrote: > >> I'm trying to create an off-screen GWorld whose palette >> matches the palette of the window I'm copying to. >> >> What happens is that I set up a palette, say entry 3 >> is red, and set it up for both the GWorld and the window. >> Then I poke a 3 somewhere into the GWorld memory, but >> when I call CopyBits(), the color's been translated to something >> else. >> >> If I do a PmForeColor(3) then poke the result of a GetForeColor(), >> I get the correct results. >> >> Somewhere, QuickDraw is remapping colors. >> >> Anyone know how to prevent QuickDraw from remapping so that I >> have an identity relationship between the color table in my >> off-screen GWorld and the palette in my window? I don't >> want to have to go through this cheesy translation step! >> > [snip] > One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image > directly- this is a sure fire way of making a program incompatible with the > video device. If QuickDraw doesn't know about the contents of an image > (because you bypassed it) you will almost certainly not end up with what > you want. What if you are trying to get a video-game to go as fast as possible? OBviously, QuickDraw is too slow for such purposes... > > -------------------------------------------------------------------------- > Graham > > -Everyone is entitled to their opinion, no matter how wrong they may be... > -------------------------------------------------------------------------- Lawson +++++++++++++++++++++++++++ >From ltaylor@academic.csubak.edu (John Stiles) Date: 7 May 1994 22:19:15 GMT Organization: California State University, Bakersfield >>> Anyone know how to prevent QuickDraw from remapping so that I >>> have an identity relationship between the color table in my >>> off-screen GWorld and the palette in my window? I don't >>> want to have to go through this cheesy translation step! >>> The same thing happened to me. The GWorld was assigned a clut, this clut was changed to a palette and was applied to a window. Still, CopyBits wanted to do colormapping. Great. I did notice that the mapping was 0 to 0, 1 to 1, 2 to 2, ... 255 to 255--i.e., no change. (it had to be with the custom palette I was using!) The only workable solution was to implement a cheap blitter. It worked and I got it running faster than CopyBits anyway. So, problem solved. Still, there should be a more acceptable solution. *Stiles +++++++++++++++++++++++++++ >From hall_j@sat.mot.com (Joseph Hall) Date: Sun, 8 May 1994 23:40:17 GMT Organization: Motorola Inc., Satellite Communications Seems it was 103t_english@west.cscwc.pima.edu who said: >What if you are trying to get a video-game to go as fast as possible? >OBviously, QuickDraw is too slow for such purposes... Obviously, you have never used a properly-aligned CopyBits. There is no need to draw directly into screen memory on the Mac. Munge your bits in your favorite quickest, hairiest way offscreen and then use QuickDraw to copy them onto the screen. I'll grant that QuickDraw's line- and circle-drawing algorithms are both slow and a little weird, but you don't have to use *them* to draw into an offscreen area. -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From pottier@trimaran.ens.fr (Francois Pottier) Date: 9 May 1994 10:11:30 GMT Organization: Ecole Normale Superieure, PARIS, France In article <2qh453$aag@nic-nac.csu.net>, John Stiles wrote: > The same thing happened to me. The GWorld was assigned a clut, this >clut was changed to a palette and was applied to a window. Still, CopyBits >wanted to do colormapping. Great. > I did notice that the mapping was 0 to 0, 1 to 1, 2 to 2, ... 255 to >255--i.e., no change. (it had to be with the custom palette I was using!) > The only workable solution was to implement a cheap blitter. It worked >and I got it running faster than CopyBits anyway. So, problem solved. Still, >there should be a more acceptable solution. There is one. Just replace the destination color table's ctSeed with the source table's one. This will let CopyBits know that the color tables are indeed equal, and no mapping will be performed. I think it is described in Inside Mac, but I don't know for sure, since Imaging hasn't appeared in French bookstores yet. -- Francois Pottier pottier@dmi.ens.fr - ---------------------------------------------------------------------------- This area dedicated to the preservation of endangered species. "Moof!" +++++++++++++++++++++++++++ >From Phil Smy Date: 10 May 1994 18:42:26 GMT Organization: Innotech MultiMedia Corp. In article <2ql28i$1q4@nef.ens.fr> Francois Pottier, pottier@trimaran.ens.fr writes: >There is one. Just replace the destination color table's ctSeed with >the source table's one. This will let CopyBits know that the color tables >are indeed equal, and no mapping will be performed. I think it is described >in Inside Mac, but I don't know for sure, since Imaging hasn't appeared in >French bookstores yet. Here's what I do to make a GWorld with matching palette: thePal = GetPalette(front->macPort); if (thePal) { offColors = GetCTable(ktheCLUT); Palette2CTab(thePal,offColors); } GetGWorld(&savePort,&saveDevice); depth = (*(*saveDevice)->gdPMap)->pixelSize; depth = depth & 0x0000FFFF; error = NewGWorld(&offPort, depth ,&borderRect,offColors,nil,0); if (error != noErr) // do something about this! SetGWorld(offPort,nil); I have had no colour mapping problems doing this. I don't know if this helps. Phil ****************************************************************** * Phil Smy * Interactive CDRom MultiMedia * * Sr. Developer * #include * * Innotech MultiMedia Corp. * Wot Gorilla? * ****************************************************************** +++++++++++++++++++++++++++ >From grobbins@apple.com (Grobbins) Date: 10 May 1994 19:56:42 -0700 Organization: Skunkworks In article <2qh453$aag@nic-nac.CSU.net>, John Stiles wrote: >>>> Anyone know how to prevent QuickDraw from remapping so that I >>>> have an identity relationship between the color table in my >>>> off-screen GWorld and the palette in my window? > The same thing happened to me. The GWorld was assigned a clut, this >clut was changed to a palette and was applied to a window. Still, CopyBits >wanted to do colormapping. Did you try setting bit 14 of ctFlags? Take a look at the palette manager article in issue 5 of develop and the ctSeed reference in the Palette Manager chapter of Inside Mac VI for a discussion of how to use that bit to avoid unintended color mappings. Grobbins grobbins@apple.com Usual disclaimers apply. +++++++++++++++++++++++++++ >From tenglish@west.cscwc.pima.edu Date: 10 May 94 21:51:32 MST Organization: (none) In article <1994May8.234017.25097@sat.mot.com>, hall_j@sat.mot.com (Joseph Hall) writes: > Seems it was 103t_english@west.cscwc.pima.edu who said: >>What if you are trying to get a video-game to go as fast as possible? >>OBviously, QuickDraw is too slow for such purposes... > > Obviously, you have never used a properly-aligned CopyBits. > > There is no need to draw directly into screen memory on the Mac. Munge > your bits in your favorite quickest, hairiest way offscreen and then use > QuickDraw to copy them onto the screen. > > I'll grant that QuickDraw's line- and circle-drawing algorithms are > both slow and a little weird, but you don't have to use *them* to draw > into an offscreen area. > I'm sorry. From what you had said (as I dimly recall it), you seemed to be advocating the use of QuickDraw for *everything*. Obviously, CopyBits is part of QUickDraw, but I was taking you to mean circles and so on as well... Lawson (formerly 103T_English... The Sys Admin got her lines crossed and renamed my account with my brother's... imagine my surprise...) +++++++++++++++++++++++++++ >From Mark Hanrek Date: Wed, 11 May 1994 12:06:41 GMT Organization: The Information Workshop In article Graham Cox, u9119523@sys.uea.ac.uk writes: >> I'm trying to create an off-screen GWorld whose palette >> matches the palette of the window I'm copying to. In addition to the suggestions regarding the ctSeed, try taking the following approach. - -- Color Tables If you can, try to avoid thinking of "a palette of colors" because this English expression ends up confusing us when working with the Palette Manager, which is clearly from another planet. :) Try an approach that has worked well for me, of working with color tables at all times, until the very last minute. Then, when you are ready to activate the colors you need, just before drawing to the window, create a palette from your color table using CTab2Palette. E-Z. If you are going to be drawing into a GWorld, have the color table with the colors you want already attached to the GWorld. It helps to have the color table supplied when you create the GWorld as well. For example, say you want to read in and draw a GIF picture.... - Read in the GIF data, and extract the color table and picture rect. - Create a color table with the picture's colors in it. - Create a GWorld of the proper rect and supply the color table, too. - While decoding the GIF's pixels, write the values directly into the GWorld's pixels, after having locked it down, natch. - Create a palette from the color table using CTab2Palette. - Activate the colors using NSetPalette and ActivatePalette - Copybits from the GWorld to the window. Also, observe the unwritten rules of always doing... ForeColor( blackColor ); BackColor( whiteColor ); before performing a CopyBits. - --- Palettes Also, it is good to be up on what the Palette Manager is doing. There is an informative article in the March '93 d e v e l o p called "The Palette Manager Way" in the Graphical Truffles column. It describes how one can use the pmTolerant + pmExplicit usage modes to ensure that the positions of your colors don't change when your palette is activated. Keep in mind that when you activate your palette, the Palette Manager is arbitrating your "request" with the needs of the rest of the windows. If you must have the exact colors you specify, then always use the pmTolerant + pmExplicit mode when you are creating your color tables and palettes. One thing that helped me get the hang of things was always creating palettes and color tables using ( pmTolerant + pmExplicit ) in the appropriate parameter. Things will work as you expect because you are essentially "insisting" that the Palette Manager give you exactly what you are asking for, and leave things in the positions you have them in. Once you get things working, then as a separate exercise you can relax your color needs and experiment with the usage modes, if by some freak accident of nature you actually have some extra time. :) Hope this helps. Mark Hanrek +++++++++++++++++++++++++++ >From jonbl@microsoft.com (Jon Blossom) Date: Thu, 12 May 1994 02:59:06 GMT Organization: Microsoft Corporation >> One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image >> directly- this is a sure fire way of making a program incompatible with the >> video device. If QuickDraw doesn't know about the contents of an image >> (because you bypassed it) you will almost certainly not end up with what >> you want. > >What if you are trying to get a video-game to go as fast as possible? >OBviously, QuickDraw is too slow for such purposes... Which is basically exactly what I'm trying to do. For certain applications, QuickDraw just isn't fast enough. For instance, my polygon fills beat QD by about 25% or more because I know exactly how I want to draw them. What I really want to do is build my image the way I want it then say "QuickDraw, here is a picture. Put it on the screen as fast as you can." Unfortunately, I know that it's NOT going as fast as it can because it's doing this damn color translation along the way even though I know it doesn't have to. -Jon Blossom jonbl@microsoft.com --------------------------- >From s010mes@discover.wright.edu (Moshe Segal) Subject: How do I draw masked icons w-System 6? Date: Tue, 10 May 1994 15:33:15 GMT Organization: Wright State University, Dayton, OH 45435 Does anybody know how to accomplish the following task: Display an ICN# resource in a window using System 6. You may recall that almost all of the icon utilities are only available on System 7, while the commands like "GetIcon" only display ICON resources, which have no mask and leave an unsightly white square around them when displayed. I know it must be possible to display ICN# resources on pre-System 7 platforms. Indeed, a game called "Icon Bounce" does this beautifully. At first I thought that was done by storing the ICN# patterns and masks as regions. But, alas, I couldn't figure out to get a pointer or handle to the bitmap fields of the icon. Anyone know the answer or know where I could find it on the net or in a book (I have only the new Inside MacIntoshes). Or, does anyone have the source code for the aforementioned Icon Bounce game? Please post the response, as I am on a friends account. Michael E. Kotler +++++++++++++++++++++++++++ >From Matt Slot Date: 10 May 1994 21:01:38 GMT Organization: University of Michigan Moshe Segal, s010mes@discover.wright.edu writes: >Does anybody know how to accomplish the following task: Display an ICN# >resource in a window using System 6. You may recall that almost all of >the icon utilities are only available on System 7, while the commands like >"GetIcon" only display ICON resources, which have no mask and leave an >unsightly white square around them when displayed. Here is a snippet I extracted from some Icon plotting tools that I wrote. I found the technique in a TechNote (I think). It works for both System 6 and System 7. This code is was snipped from a program I wrote and wrapped into a little function... it should be ready for dropping into a program with no bugs. Matt Slot fprefect@engin.umich.edu void PlotIconInAllSystems(short iconID, Boolean hilited, Rect *iconRect) { BitMap iconMap; Handle iconHdl; if (!hasSys7 || PlotIconID(&iconRect, 0, (hilited) ? ttSelected : 0, iconID)) { if (iconHdl = GetResource('ICN#', iconID)) { HLock(iconHdl); iconMap.baseAddr = *iconHdl; iconMap.rowBytes = 4; SetRect(&iconMap.bounds,0,0,32,32); CopyBits(&iconMap, &thePort->portBits, &iconMap.bounds, &iconRect, srcCopy, 0); if (hilited) { iconMap.baseAddr += 128; CopyBits(&iconMap, &thePort->portBits, &iconMap.bounds, &iconRect, srcXor, 0); } HUnlock(iconHdl); ReleaseResource(iconHdl); } else FrameRect(&iconRect); // Something went wrong -- wimp out } } +++++++++++++++++++++++++++ >From Richard Knuckey Date: Fri, 13 May 94 20:15:37 +1200 Organization: Purple X's Humble Macintosh The following mimics all of the system 7 icon drawing styes (in black and white only) It is cut from a larger and more complete icon handling unit. const largeRowBytes = 4; smallRowBytes = 2; miniRowBytes = 2; largeMaskOffset = largeIconSize * largeRowBytes; smallMaskOffset = smallIconSize * smallRowBytes; miniMaskOffset = miniIconSize * miniRowBytes; type IconListHandle = ^IconListPtr; IconListPtr = ^IconListType; IconListType = record icon: packed array[1..32] of longint; mask: packed array[1..32] of longint; end; procedure DrawIconList (iconBounds: Rect; iconSize, transform: integer; iconData: univ Handle); var iconBitMap, maskBitMap: BitMap; iconDisabled, iconOffLine, iconOpen, iconSelected: Boolean; copyMode, iconTransform: integer; drawPort: GrafPtr; begin GetPort(drawPort); HLock(iconData); with iconBitMap do begin baseAddr := iconData^; bounds := iconBounds; maskBitMap := iconBitMap; case iconSize of largeIconSize: begin rowBytes := largeRowBytes; maskBitMap.rowBytes := largeRowBytes; maskBitMap.baseAddr := Ptr(ord4(baseAddr) + largeMaskOffset); end; smallIconSize: begin rowBytes := smallRowBytes; maskBitMap.rowBytes := smallRowBytes; maskBitMap.baseAddr := Ptr(ord4(baseAddr) + smallMaskOffset); end; miniIconSize: begin rowBytes := miniRowBytes; maskBitMap.rowBytes := miniRowBytes; maskBitMap.baseAddr := Ptr(ord4(baseAddr) + miniMaskOffset); end; otherwise begin HUnlock(iconData); exit(DrawIconList); end; end; end; {the transform type is in the lower nibble} iconTransform := BAND(transform, $000F); iconDisabled := iconTransform = ttDisabled; iconOffline := iconTransform = ttOffline; iconOpen := iconTransform = ttOpen; iconSelected := BAND(transform, ttSelected) <> 0; if iconOffline | iconOpen then begin PenMode(patXor); if iconSelected then PenPat(dkGray) else PenPat(ltGray); PaintRect(iconBounds); end; if (not (iconOffline | iconOpen)) & iconSelected then copyMode := srcOr else copyMode := srcBic; CopyBits(maskBitmap, drawPort^.portBits, iconBounds, iconBounds, copyMode, nil); if iconDisabled then begin PenMode(patXor); PenPat(gray); end; if iconOpen | iconOffline | iconDisabled then PaintRect(iconBounds); if (not iconOpen) then begin if iconOffline then if iconSelected then copyMode := srcBic else copyMode := srcOr else if iconDisabled then copyMode := srcBic else copyMode := srcXor; CopyBits(iconBitmap, drawPort^.portBits, iconBounds, iconBounds, copyMode, nil) end; if iconDisabled then PaintRect(iconBounds); PenMode(patOr); PenPat(black); HUnlock(iconData); end; --------------------------- >From julie@zoot.sps.mot.com (Julie Shipnes) Subject: Motorola announces Power Mac compilers Date: 12 May 1994 16:29:40 -0500 Organization: Motorola RISC Software, Austin, TX MOTOROLA ANNOUNCES HIGH-PERFORMANCE POWERPC MICROPROCESSOR COMPILERS FOR POWER MACINTOSH AUSTIN, Texas, May 10 -- Motorola's RISC Microprocessor Division today announced plans to port its optimizing PowerPC microprocessor compilers to Apple's complete line of Power Macintosh computers. The C, C++ and FORTRAN compilers will be fully compatible with Apple's Macintosh Programmers' Workshop (MPW) development environment and will enable developers to simultaneously optimize code for each member of the PowerPC family of microprocessors, including PowerPC 601(TM), PowerPC 603(TM), PowerPC 604(TM) and PowerPC 620(TM). "The ability to take full advantage of the PowerPC performance features of each member of the PowerPC family is a critical aspect of Motorola's commitment to provide a complete solution for our customers," said Les Crudele, vice president and general manager, Motorola RISC Microprocessor Division. "Our compilers will permit developers to leverage the performance potential of current and future PowerPC microprocessors without the need to recompile applications." The compilers, which are currently being tested within Apple and at select beta sites, have demonstrated significant performance improvements for critical applications. Much of the performance increase is because the Motorola compilers optimize code to take advantage of individual features of the superscalar PowerPC microprocessors, while still maintaining code compatibility across all PowerPC architecture family members. The compilers can be configured to optimize code for a particular chip implementation, or they can generate a series of objects that target multiple PowerPC microprocessor. As a result, developers can develop applications now that will be optimally configured for existing and future Apple systems. "By integrating their compiler development with the PowerPC chip design efforts in Austin, Motorola is in a unique position to bring highly optimizing compilers to market quickly for forthcoming PowerPC microprocessors," said Peter Christy, senior director of developer products engineering at Apple Computer, Inc. "The Motorola compilers complement the MPW compilers and tools already available from Apple and others, and provide Macintosh developers with a more complete set of options for creating high-performance applications for the exciting Power Macintosh platform." Motorola has also announced its intention to integrate its compilers into the CodeWarrior development environment offered by Metrowerks, Inc. By supporting both the MPW and CodeWarrior environments, users will be able to leverage the performance advantages of the Motorola compilers without needing to adopt a new development environment. "The addition of Motorola's compilers to the CodeWarrior environment will offer an immediate performance boost for those CodeWarrier developers that are working on leading-edge applications for future implementations of PowerPC microprocessors," said Metrowerks president and CEO Greg Galanos. According to Galanos, Metrowerks is defining a tools and language interface for CodeWarrior that will permit developers to use standardized language conventions and user interfaces for a variety of development tools. Motorola will accept orders in July 1994 for the MPW-based compilers and tools running native on Power Macintosh and 68000-based Macintosh systems at an initial list price of $349. The company will offer a beta version of the compiler for CodeWarrior in late 1994. For additional information, customers can call 800-845-MOTO. PowerPC microprocessors are based on reduced instruction set computing (RISC) and incorporate leading edge technologies from IBM and Motorola. The family of PowerPC microprocessors is designed to address a wide range of computing requirements, from portable and desktop computers to midrange workstations and servers, to multi-processing, fault-tolerant and supercomputing systems. PowerPC microcontrollers also will be used for embedded control applications in automotive and consumer products. Companies developing PowerPC systems and subsystems include Apple Computer, Canon, DayStar Digital, Ford Motor Co., Groupe Bull, Harris, Hitachi, IBM, ISG Technologies, Mercury Computer Systems, Motorola Computer Group, Parsytec, PowerHouse, Scientific Atlanta, Shannon Computer, Tadpole Technologies, the Taiwan New PC Consortium, THOMSON-CSF and YARC. Having 1993 worldwide sales of $5.7 billion, Motorola's Semiconductor Products Sector is the largest U.S.-based broad line supplier of semiconductors, with a balanced portfolio of more than 50,000 devices. Motorola is one of the world's leading providers of wireless communications, semiconductors, and advanced electronic systems and services. Major equipment businesses include cellular telephone, two-way radio, paging and data communications, personal communications, automotive, defense and space electronics and computers. Communications devices, computers and millions of consumer products are powered by Motorola semiconductors. Motorola's 1993 sales were $17 billion. NOTE: Product names are trademarks of their respective companies. PowerPC, PowerPC architecture, PowerPC 601, PowerPC 603, PowerPC 604 and PowerPC 620 are trademarks of International Business Machines Corporation and are used by Motorola under license from International Business Machines Corporation. CONTACT: (reader/Inquiry response) Motorola, Inc. RISC Microprocessor Division, P.O. Box 202558, Austin, Texas, 78720-9895, 1-800-845-MOTO - -------------------------- Oakhill ------------------------------- Julie Shipnes Mike Phillip julie@pets.sps.mot.com phillip@pets.sps.mot.com Motorola RISC Compiler Development - ------------------------------------------------------------------- --------------------------- >From sjf@phantom.com (Simon Jensen_Fellows) Subject: Polling the Serial Port Date: 28 Apr 1994 21:27:18 GMT Organization: [MindVox] / Phantom Access Technologies / (+1 800-MindVox) Hi, Anyone got any advice about running a background process that polls the serial port ? I have tried posting a VBL routine, patching a trap and just running a background application. My main problem is that I seem to loose all my settings (Baud rate, parity etc) once I exit the routine back to the O/S. I guess I`m doing something wrong: any advice or sample code ? Thanking you in advance. Simon. +++++++++++++++++++++++++++ >From ctrfree@mr.net (Evan Olcott) Date: 29 Apr 1994 22:50:13 GMT Organization: Centor Freed Inc. Best thing to do is to patch WaitNextEvent. Open the serial drivers upon startup (a lovely piece of extension code) and hold them in an A4 global buffer. Upon each call to your patch, get the globals (to get the refNum and other stuff) and check the port. Seems to work for me. Now the tricky part is serial port arbitration... ;-) Evan Olcott, programmer Centor Freed Inc. 100 N. 6th Street #989C Minneapolis, MN 55417 "There are no experimental failures. There's only more data." - Bryce +++++++++++++++++++++++++++ >From oster@netcom.com (David Phillip Oster) Date: Thu, 12 May 1994 19:59:24 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) You'd have to be absolutely insane to poll the serial ports. Anybody in their right mind would do a PBRead(&io, TRUE); i.e., an asynchronous read. The operating system will call your completion routine at interrupt level when the read completes: you never need to poll. Your completion routine can do another read. You may want to set up a deadman-switch VBL task: your completion routine is expecting data in at most 10 seconds, so it sets up a VBL task with a 15 second timeout. If the read completes, the completion routine cancels the VBL and starts a fresh one. If something went wrong, the VBL gives you back control so you can fix things (like re-enable the serial ports, notify the user that something went wrong, etc.) Back in '85 I used this technique to interface serial digitizing tablets --------------------------- End of C.S.M.P. Digest **********************