From: pottier@clipper.ens.fr (Francois Pottier) Subject: C.S.M.P. Digest, Issue 3.004 Date: Tue, 15 Mar 94 16:31:03 MET C.S.M.P. Digest Tue, 15 Mar 94 Volume 3 : Issue 4 Today's Topics: Code optimization Getting Started with TCL How would you write a text-based log window? Reducing screen flicker in simple animation. What to say when the appropiate Gestalts aren't there? small snag 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 alex@metcalf.demon.co.uk (Alex Metcalf) Subject: Code optimization Date: Sun, 27 Feb 1994 23:49:17 GMT Organization: Demon Internet I'm working on an arcade game which, when being played, goes through a "loop" of code every 2 ticks. In this time, it's calling various functions, doind some calculations, then copying graphics to the screen. Since it's only just keeping up on my LC475 (!), I need to optimise my code so that it works comfortably on 68030 Macs. I want to find out how long each function call in my loop is taking, but obviously, checking the ticks won't work. A resolution of time such as 10ths of a tick would be useful. I can see that I'm going to have to use the Time manager (is that what it's called?), but I get the impression that it will be more work than it's worth to implement. If this task proves hard, could someone give me some suggestions as to how I could improve the following operations? ¥ Copying 24 x 24 pixel graphics to the window (using CopyBits and CopyMask) ¥ Dividing numbers (I'm using, e.g. bigNum/littleNum) ¥ Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits / CopyMask). I'd like faster routines, if possible, but I don't want them if it means compromising compatibility with other (or future) Macs. That'll be the day.. :-) Thanks, Alex -- Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler Internet, AOL, BIX: alex@metcalf.demon.co.uk AppleLink: alex@metcalf.demon.co.uk@internet# CompuServe: INTERNET:alex@metcalf.demon.co.uk Delphi: alex@metcalf.demon.co.uk@inet# FirstClass: alex@metcalf.demon.co.uk,Internet Fax (UK): (0570) 45636 Fax (US / Canada): 011 44 570 45636 +++++++++++++++++++++++++++ >From ejohnson@netcom.com (Eric Johnson) Date: Mon, 28 Feb 1994 00:57:33 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Alex Metcalf (alex@metcalf.demon.co.uk) wrote: > If this task proves hard, could someone give me some suggestions as > to how I could improve the following operations? > Copying 24 x 24 pixel graphics to the window (using CopyBits and > CopyMask) > Dividing numbers (I'm using, e.g. bigNum/littleNum) > Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits / > CopyMask). I wrote my own CopyBits for a game that I was writing. I can dig it out and post it here. I can give you the following suggestions though. If you've created your icons with ResEdit, you should load them into a gWorld whose color table is the same one that you will eventually display your icons. This will speed up the process because you will not have to worry about "recoloring" your icons into the new table. Consider this gWorld your palette of icons from which you will copy. Then, you need to roll your own CopyBits. You can optimize the hell out of this by creating a loop that uses a nice Motorola 680x0 instruction that will decrease a data register, and branch if the data register is still not zero. Its a good instruction to use, because it assumes that the jump will occur, and not flush the pipeline. I'll be damned if I can remember the exact name of this instruction. It starts with a d, I think. Sorry, I just can't remember. If you don't have a Motorola 68030 or 68040 book, now is the time to get one. You should construct the loop so that it will fill up the instruction cache, or at least use most of it. That way, when the first run through of the loop occurs, the code will find its way into the instruction cache. On the second run of the loop, its all in the cache so it runs like a champ. You might also get better performance in your loop by reading in as much data as you can into the data registers. Then, write it to the destination buffer in one swoop. I think this might help a touch because you should be able to maximize the performance of the data registers. There are some other optimizations that I made, but I don't remember. I'll have to dig out that code for you. It was pretty damn fast. It should be a bit faster for you, because you shouldn't need any masking. I suppose others might find it useful too, so I'll get around to posting it. My only request is that I get credit in someone's about box. -Eric -- Eric E Johnson ejohnson@netcom.netcom.com +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 28 Feb 94 17:12:02 GMT Organization: PowerTools, Austin, Texas In article alex@metcalf.demon.co.uk (Alex Metcalf) writes: >I can see that I'm going to have to use the Time manager (is that >what it's called?), but I get the impression that it will be more work than >it's worth to implement. Actually, it's not difficult. Set up a Time Manager task that calls back every millisecond, and have the task increment a field in your (extended) Time Manager record. Look at this field before and after your function call. The difference is how long the function took to execute. >% Copying 24 x 24 pixel graphics to the window (using CopyBits and >CopyMask) >% Dividing numbers (I'm using, e.g. bigNum/littleNum) >% Copying between GWorlds (all 8 bit, 640x480; I'm using CopyBits / >CopyMask). If I recall correctly, CopyBits with a mask region is substantially faster than CopyMask. But you should try to set up your copying such only the final copy is offscreen-to-onscreen, and this copy can be made with a call to CopyBits in srcCopy mode. Then, for your offscreen-to-offscreen copying, you can write your own masked copy routine optimized for 24X24 graphics. --Al Evans-- -- Al Evans Tu causes, tu causes al@crucible.powertools.com C'est tout ce que tu sais faire cs.utexas.edu!crucible!al -- LaVerdure --------------------------- >From darick@zippy.nimh.nih.gov (Darick DeHart) Subject: Getting Started with TCL Date: Mon, 28 Feb 1994 14:49:56 GMT Organization: RSB/NIH I have been struggling with Think Class Library for about a week. I am a good C programmer with some experience in both Macintosh and Object Oriented programming. I am hoping that mastering TCL will allow me to quickly develop simple Macintosh Applications. Are there any books (besides the Symantec TCL Guide) that provide "Getting Started" type information. I'm also interested in people's opinions on TCL. Is learning it worth the investment in time? How long does it take to become comfortable with the library? +++++++++++++++++++++++++++ >From murphybf@rtsg.mot.com (Brendan F. Murphy) Date: 28 Feb 1994 18:58:15 GMT Organization: Motorola Cellular In article , you write: |> I have been struggling with Think Class Library for about a week. I am a |> good C programmer with some experience in both Macintosh and Object |> Oriented programming. I am hoping that mastering TCL will allow me to |> quickly develop simple Macintosh Applications. What you say is true, but it takes a while to master TCL. The trick is to not force TCL to do something it was not designed to do. In other words, make your application fit TCL way of doing things and you'll be a much happier camper (until you become more experienced in TCL). |> Are there any books (besides the Symantec TCL Guide) that provide "Getting |> Started" type information. There's the code! I'm serious about that one!! This is how you find out the deep dark secretes of TCL. |> I'm also interested in people's opinions on TCL. Is learning it worth the |> investment in time? How long does it take to become comfortable with the |> library? It all depends on the job you are trying to accomplish. If your doing a medium to small application TCL may be the ticket for you. If your doing something that's real industrial strength then MacApp might be the way to go. I have found it to be worth learning and useful as a framework, but PowerPlant just might change my mind in the future when I get a hold of it. There is a news group dedicated to to TCL called comp.sys.mac.oop.tcl and you might want to defer questions to that group. Also there is an ftp site for a bunch of TCL classes at ftp.brown.edu. Hope this helps. +++++++++++++++++++++++++++ >From dent@perth.DIALix.oz.au (Andrew Dent) Date: 1 Mar 1994 17:36:10 +0800 Organization: DIALix Services, Perth, Western Australia Darick Depending on what you are doing with TCL, you may want to escape from some of the hassles by using an interface editor/generator program. Both AppMaker and Marksman generate excellent TCL code (immodest bit here: I wrote the Marksman TCL templates). I believe Marksman is better value for money and certainly the current version has better interface support, including full color. Marksman demos are available on most ftp sites that mirror info-mac or umich. The code demos are posted separately from the editor demo, which lets you do everything but save a prototype. The TCL code demos should be on their way by now. In general, my advice to TCL beginners is "relax and don't try to learn it all". You can do an amazing amount with TCL without having to learn too much about it's internals, until you need to change the standard behaviours. Andy Dent (A.D. Software - Mac & VAX programming) 94 Bermuda Dve, BALLAJURA Western Australia 6066 Phone/Fax: 09 249 2719 (local) +619 249 2719 (International) Internet: dent@DIALix.oz.au Compuserve: 100033,3241 --------------------------- >From egurney@vcd.hp.com (Eddy J. Gurney) Subject: How would you write a text-based log window? Date: Wed, 23 Feb 1994 23:39:46 GMT Organization: Hewlett-Packard VCD I'm wondering if anyone has any suggestions to implementing a simple, fast, and effective read-only text-based log window. I have the need to have a window open to which I would write various status messages while the application runs. Since the this application could run for a lengthy period of time, I'd like the older data to be discarded for newer data when the buffer reaches some predetermined size. Currently I'm using Eric Soldan's "TextEditControl" from Apple's DTS.Lib, and it works fairly well. (If anyone's interested, it was very simple to extract this complete TextEditControl from DTS.Lib to a completely "self contained" module which can be included in a THINK C application, giving you an editable text control in a window with no effort on your part.) I'm just wondering if there is a better solution. It should do all the normal TextEdit things like selecting text, scrolling while selecting, vertical scrollbar (horizontal is not necessary in my case), etc. I'm just wondering if using TextEdit via Eric's TextEditControl is "overkill" and adding too much overhead to something which could be much simpler. (The slowest part right now is when the buffer fills up... in that case I do a TESetSelect to select some number of bytes, call TEDelete to remove them, TESetSelect to move to the end of the data and then TEInsert to add the new text.) Any ideas or suggestions appreciated... Thanks, Eddy -- Eddy J. Gurney N8FPW Hewlett-Packard Company, Vancouver (USA!) Division egurney@vcd.hp.com #include "Failures are divided into two classes-- those who thought and never did, and those who did and never thought." John Charles Salak +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 23 Feb 1994 17:04:04 -0800 Organization: SRI International, Menlo Park, CA In article egurney@vcd.hp.com (Eddy J. Gurney) writes: >I'm wondering if anyone has any suggestions to implementing a simple, >fast, and effective read-only text-based log window. I have the need to >have a window open to which I would write various status messages while >the application runs. Since the this application could run for a lengthy >period of time, I'd like the older data to be discarded for newer data >when the buffer reaches some predetermined size. If you don't really need character level selection (ie line level selection would suffice), use the list manager. I've wrote a dataviewer program that display large amounts of text in a scrolling list and it supports tab stops. My intent was to create a freeware document maker/viewer. Using the list manager is easy and fun. Ldef's are easy to write just keep the data out of the list manager. Another program I wrote called more or less displays large amounts of text by using drawtext. I intend to make both programs support PPC and or AppleEvents so that programmers can pipe debugging output these programs and have a easy to use log. No muss no fuss AEprintf/AEwriteln. :-) Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@qm.sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From walrathw@rferl.org (WalrathW) Date: 28 Feb 94 11:05:50 -0500 Organization: RFE/RL Inc. In article egurney@vcd.hp.com (Eddy J. Gurney) writes: > I'm wondering if anyone has any suggestions to implementing a simple, > fast, and effective read-only text-based log window. I have the need to > have a window open to which I would write various status messages while > the application runs. Since the this application could run for a lengthy > period of time, I'd like the older data to be discarded for newer data > when the buffer reaches some predetermined size. [deleted] > Any ideas or suggestions appreciated... > > Thanks, > Eddy I'm taking the advice suggested in a develop article several issues back, and using the Terminal Manager for simple debugging info. I've got a serial port capture application which only sends the data to files, but I added support for piping it to a TM window as well, to see what's supposed to end up in the files. You might checkout DebugWindow library. Here's some info from the README: DebugWindow is a utility that mimics the Windows 3.x program of the same name. It allows you to easily print out display strings during the development stages of your program without any of the headaches normally associated with built-in "standard I/O" functions. DebugWindow's features: ¥ full "printf()" functionality for C programmers without any added coding on your part ¥ will remember its location and size on the screen across sessions ¥ no more hassles of trying to incorporate Think C's "stdio" window in with your pure Toolbox code ¥ allows you to save any information that you've printed into its window to a TeachText document ¥ callable from either Think C or Hypercard (Debug Window is written by Keith Ledbetter) It's available in the usual Mac archive sites. cheers, ______o0o______ Wayne Walrath RFE/RL Inc. --------------------------- >From P.A.Brooks-Johnson@newcastle.ac.uk (P.A. Brooks-Johnson) Subject: Reducing screen flicker in simple animation. Date: Mon, 21 Feb 1994 13:17:13 GMT Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU. I'll make the apology first for this being a newbie question, but I'm in a bit of a time fix so I need some help. (and where better to look?) A little background: I'm writing a simple algorithm animator for the Mac (and other platforms .....) I'm just moving simple rectangles round the screen so there's no need for complex animation stuff. Based on a book by Mark Watson ( Portable GUI development in C++) which IMO ain't bad, but is a bit buggy, I've got redraw etc to work OK. The problem is the screen flicker, mainly due, I guess, to constantly erasing and redrawing the object which are moving. My solution: I propose to draw to an off screen grafPort then use copyBits to move the image from offScreen.portBits to screen.portBits. The question: Very simple.... is this right?? Is the reduction in flicker worth the bother or shall I just spend my precious (no not precious, just very limited!) time on something else? Is there a better way? I get the impression qd provides some explicit support for this kind of thing..... Thanks for your help, I may even understand all this one day!!! Peter (P.A.Brooks-Johnson@newcastle.ac.uk) +++++++++++++++++++++++++++ >From Michael Burks Date: Mon, 21 Feb 1994 11:07:53 -0500 Organization: Fifth yr. senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 21-Feb-94 Reducing screen flicker in .. by P.A. Brooks-Johnson@newc > > My solution: > I propose to draw to an off screen grafPort then use copyBits to move the image > from offScreen.portBits to screen.portBits. > > The question: > Very simple.... is this right?? Is the reduction in flicker worth the bother or > shall I just spend my precious (no not precious, just very limited!) time on som > ething else? Is there a better way? I get the impression qd provides some explic > it support for this kind of thing..... > > Thanks for your help, I may even understand all this one day!!! > What you propose will work. I would call it psuedo-double bufferring. It's a common thing. Whether you want to do it is a very subjective question. There are lots of other solutions. If it's just rectangles, you could easily keep track of what pixels have changed yourself (this extends to polygons), and only update them. You could also use color cycling (animating colors). Blaine. +++++++++++++++++++++++++++ >From Sander C. Temme Date: 22 Feb 94 14:00:18 +0100 Organization: University of Amsterdam In article P.A. Brooks-Johnson, P.A.Brooks-Johnson@newcastle.ac.uk writes: >The question: >Very simple.... is this right?? Is the reduction in flicker worth the bother or >shall I just spend my precious (no not precious, just very limited!) time on >something else? Is there a better way? I get the impression qd provides some >explicit support for this kind of thing..... The easiest way to do this is documented in the acclaimed book 'How to Write Macintosh Software' by Scott Knaster as 'Smooth Animation for the Rest of Us': You can synchronize your drawing with the vertical retrace (i.e. when the electron beam moves from lower right corner to upper left corner of the screen) so you change the video RAM when no drawing is going on. When the Mac hits vertical retrace, it generates an interrupt. One of the things this interrupt does is increase the TickCount global Variable. So, what the rest of us do to get smooth animation is let our program sit in a tight loop waiting for TickCount to change, and when it does, draw like heck. Only, this method dates from way back when multiple screens and CQuickDraw weren't an issue. You'll have to see whether it still works. When it did (when I toyed around with simple animation on a Plus), it gave nice results for all its simplicity. > >Thanks for your help, I may even understand all this one day!!! (-: (-: Sander Sander C. Temme, University of Amsterdam, Holland temme@phys.uva.nl ------------------------------------------------------------------- 'Denkt U werkelijk dat wij zo gek zijn om voor een weddenschap naar Zuid-Afrika te vliegen?' -- Bob Evers +++++++++++++++++++++++++++ >From mssmith@afterlife.ncsc.mil (M. Scott Smith) Date: Tue, 22 Feb 1994 17:22:35 GMT Organization: The Great Beyond In article <1994Feb22.140018.4396@news.sara.nl> Sander C. Temme writes: > >You can synchronize your drawing with the vertical retrace (i.e. >when the electron beam moves from lower right corner to upper left >corner of the screen) so you change the video RAM when no drawing is >going on. When the Mac hits vertical retrace, it generates an >interrupt. One of the things this interrupt does is increase the >TickCount global Variable. So, what the rest of us do to get smooth >animation is let our program sit in a tight loop waiting for >TickCount to change, and when it does, draw like heck. >Only, this method dates from way back when multiple screens and >CQuickDraw weren't an issue. You'll have to see whether it still >works. When it did (when I toyed around with simple animation on a >Plus), it gave nice results for all its simplicity. > Unfortunately this method doesn't work anymore, at least not for color monitors. The global variable "TickCount" has traditionally been updated every 1/60 of a second -- which was nicely in sync with the refresh rate on the old black and white Mac monitors. On color monitors, the refresh rate is rarely 60 hz., and even if it is, there's no real guarantee that it's going to be perfectly in sync with TickCount. What you need to do, then, is "sync up" with whatever monitor happens to be attached to the Mac. How do you do this? Well, luckily there's sample code floating around to do just this. I know Mike Kelly has written some (I haven't seen him around much; must be busy with his newfound success! :), and I believe there's some code in the Mac programming FAQ which you can download from sumex-aim.stanford.edu (among places). Several other people have written sample code to do it. (I'm sure Jon Witte has.) It's not particularly friendly code, and most implementations I've seen use some assembly language. Just synching to the monitor isn't a full solution, however. For this method to work as expected, you need to be sure that you can get all your drawing done in less than one screen refresh -- typically somewhere around 1/60th -> 1/70th of a second. If it takes 1.5 screen updates to do your drawing, you're not necessarily gaining much by synching. (I haven't done much testing so I can't say if you're better off synching than not in situations like this. In any case, synching will almost always have the effect of slowing down your animation -- after all, you'll be spending time waiting around for that electron gun to get to the top of the screen. I wrote a screen saver that simply animates a sphere bouncing around the screen. I wrote directly to video RAM, and used a number of other tricks to make it as quick as possible. The result was mind-numbingly fast animation -- the ball ricocheted (sp?) back and forth faster than the eye could see. When I added synching, the ball moved pretty slowly -- very smoothly, yes, but it was now animating one frame in the time it was doing 40 or more before. So, in some cases, you might want that "non-smooth" effect which you get with high-frame-rate animation. But I digress..) The method you use to draw to the screen will greatly affect how much time it takes. I didn't catch your original message, so I'm not sure if you're aware that "offscreen buffers" are the best way to achieve smooth animation. If you're not familiar with their definition or use, I'd be happy to explain them to you. You generally do all of your drawing "offscreen", and copy your picture to the screen (via CopyBits or writing directly to the video RAM or directly into a PixMap, etc.) only once it's completely ready. It's much quicker to write offscreen and the user doesn't see the individual pieces of the picture being painted, etc., which can look really bad if done on-screen. Well, this has been somewhat of a cluttered message but I hope you got something out of it. Check out the programming FAQ's -- they should have information on "monitor-independent" synching, which is one step towards smooth animation. And if you're not familiar with offscreen drawing, you'll want to look into GWorlds, which are probably the most painless way to do it. (Plus you'll want to look around for some theory on how to best use offscreen environments -- I've seen lots of different methods, and I suppose which one you choose depends on your specific application.) If you're going to be doing intensive-graphics-therapy in your game/ program/whatever, you might wish to look into (gasp!) drawing directly to the screen. CopyBits is an incredibly versatile tool, but that versatility adds some overhead in many situations; it may not be the best choice for arcade-style animation. On that note, here's a question for those of you in the know -- I haven't had a chance to play around with the PPC much; is direct-screen drawing (if done properly) still functional with the PowerPC's? I've constructed a C++ "direct-screen" library which takes a lot of the pain out of direct screen drawing, I might get around to polishing it up and releasing it some day. Good luck! Executing animation properly can make a big difference in the appearance of your program. It's worth it to spend the time researching -- there's a lot to learn. Later, M. Scott Smith +++++++++++++++++++++++++++ >From john_werner@taligent.com (John Werner) Date: Tue, 22 Feb 1994 16:58:02 GMT Organization: Taligent, Inc. In article <1994Feb22.140018.4396@news.sara.nl>, Sander C. Temme wrote: > You can synchronize your drawing with the vertical retrace > .... > interrupt. One of the things this interrupt does is increase the > TickCount global Variable. So, what the rest of us do to get smooth > animation is let our program sit in a tight loop waiting for > TickCount to change This ceased to be true in 1987 with the advent of the Mac II. On machines with Color Quickdraw, the global TickCount counter is not necessarily tied to the refresh rate on any particular monitor. TickCount is increment 60 times a second, while the refresh rate on most monitors these days is in the 65-75 Hz range. There's still a way to get what you want, however. You need to figure out which screen your window is (mostly) on, by looping through all the screen devices with routines like GetNextDevice. Then you find the slot number for that device and install your VBL task with SlotVInstall. I have a TCL class that does all this in the TCL archives at brown.edu. You won't be able to use the code unless you're writing a TCL app, but it might help you get started. The class is called CVblSync or some such thing. -- John Werner john_werner@taligent.com Taligent, Inc. +++++++++++++++++++++++++++ >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault) Date: Tue, 22 Feb 1994 12:58:35 -0500 Organization: Motorola Codex In article , P.A.Brooks-Johnson@newcastle.ac.uk (P.A. Brooks-Johnson) wrote: > The problem is the screen flicker, mainly due, I guess, to constantly erasing and redrawing the object which are moving. > > My solution: > I propose to draw to an off screen grafPort then use copyBits to move the image from offScreen.portBits to screen.portBits. This is great if you have a lot of internal animation to deal with (like a figure walking while moving across the screen). It may not be necessary if you're doing something simple like drawing solid color rects on the screen. There are several possible ways to reduce flickering animation, and they may be combined: - use the VBL to sync so you draw only during vertical retrace. This gives you the best results. You can loop and wait for the retrace by watching ticks. Try to write your function so you can handle events etc while waiting for vertical retrace to come around. The trick here is arrive at the draw function with very few ticks to waste. You can also install a VBL task to perform the drawing (just don't allow Memory Mgr memory moves to occur during the interrupt) Make sure you switch the saved screen port in before drawing. Provided you're just doing a minimal amount of drawing this will work nicely. There is a couple of things you should be aware of when using VBL sync for drawing - in general it works, but on various monitors (which use different refresh rates) it's not always flicker-free. Getting good results in that situation is a whole book in itself. - queue up all your drawing objects (prepare a draw list) ahead of time. When you get the VBL sync all you do is draw - fast. This means you don't combine calculations with drawing time. Do all your calculations while the user is looking at the last image. - calculate minimum update rects for each moving object on screen. Just determine the deltas between where the old image was drawn and where the new one needs to be, then draw that. For example if I have a rectangle moving horizontally across the screen, all I have to erase is the difference of the move, and draw the move difference on the other side. (Erase a small rectangle on one side and draw a small rectangle on the other) This works best when you have solid colors to animate, and the size and number of rectangles justifies the overhead for the calls and calculations. This technique is great for flight simulators where you have to do polygon manipulation and provide really fast frame rates. - buffered offscreen minimal update. When you have a number of different objects moving around the screen and you'll be spending more time either trying to grab the video card (NuBus) or trying to restore a background, create an offscreen port and do your drawing there. The area that you want to draw to the screen is the union of the previously drawn rect and the union of all the new rects to draw. Create the drawing list, restore background or previous, draw all the rects over this , then wait for VBL, then CopyBits the offscreen image (just the minimal update union rect) to the screen. - color cycle animation can be really quick, but animating colors are best used inside some other image which is copyed to the screen via one of the methods suggested above. I tried to do a simple scrolling effect using color cycling behind moving images, it looked okay, but called for more color management overhead than the effect was worth. Hope this helps, Chris -- #include +++++++++++++++++++++++++++ >From s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) Date: 28 Feb 1994 14:54:15 GMT Organization: University of Karlsruhe, FRG As a visitor to this group, I'd like to know if there is double-buffering for the Mac, meaning you can draw in the background and display a foreground screen and exchange both at vertical blank. This is the best technique for providing smooth animation. Now: Is this possible with the Mac toolbox ? I could not find anything about it in the Inside MacIntosh books. Personal mail preferred, as I don't read this group. Of course, you may also reply in public and PM. Thanks. -- Dietmar Heidrich, Universitaet Karlsruhe, Germany "Die Hoffnung auf den Tod ist das einzige, was mich am Leben erhaelt." --------------------------- >From partingt@fwi.uva.nl (Vincent Partington) Subject: What to say when the appropiate Gestalts aren't there? Date: 23 Feb 1994 11:11:23 GMT Organization: FWI, University of Amsterdam Hi! Apple advises developers to check the Gestalt-selectors to determine of certain System features are available instead of checking for System version. In my Sys7-only app (supporting Sys6 is just too cumbersome because about half of my systemcalls are Sys7-ones in my not-too-big app) I first check for the availability of Gestalt and then check all kinds of Gestalt-selectors for stuff like FSSpec-calls, new Standard File calls, Alias Manager, etc, etc. When I don't find those features I will have to let the user know and will have to pop up an alert telling him to upgrade or die. What should this alert say? Saying "You'll have to upgrade to Sys7 or later" is contradictory to checking Gestalt because Sys8 may not have the FSSpec-calls (small chance). Saying "You'll have to upgrade to System 7.1.6" (which I use) would be weird if Sys8 can do everything Sys7.1.6 can. Saying "Get a system thet has the Gestalt-trap, returns a 1 in bits 0 and 1 of the return from Gestalt-selector for the file system, returns 1 in bit 0 of the returnvalue from Gestalt-selector...etc...etc." would be rather user-unfriendly. Any comment? Vincent. -- BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA Internet : partingt@fwi.uva.nl BLABLA 68040 Power! ABLABLABLABLABLABLABLABLA vincent@tnc.nl BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA FidoNet : 2:281/202.15 BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA NeST : 90:500/202.15 +++++++++++++++++++++++++++ >From hrafal@copernicus.bbn.com (Howie Rafal) Date: 23 Feb 1994 19:31:09 GMT Organization: BBN, Inc In article <2kfdkr$ki1@hermes.fwi.uva.nl>, partingt@fwi.uva.nl (Vincent Partington) wrote: > When I don't find those features I will have to let the user know and will > have You could first check what version of the system is running and give the version message if it applies. Otherwise, If the system version is 7.x or greater, explain that certain necessary features are missing from the Macintosh and then give a list box of the missing managers (if they care). This would be better than listing just one manager is missing. They could then upgrade as needed. +++++++++++++++++++++++++++ >From Pascal_Haakmat Date: Wed, 23 Feb 94 20:08:28 +0100 Organization: (none) VP> What should this alert say? Well, be honest with the user, tell him what's going on ... Like: "Your system does not support the required FSSpec File Manager calls." If Gestalt returns a system version < 7 you might add "You should upgrade to System 7." Pascal. --- Obolus 1.0.2 * Origin: go on upstairs with your sweet little wishes (2:281/202.13) +++++++++++++++++++++++++++ >From wdh@netcom.com (Bill Hofmann) Date: Fri, 25 Feb 1994 18:20:07 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Pascal_Haakmat writes: > VP> What should this alert say? >Well, be honest with the user, tell him what's going on ... >Like: "Your system does not support the required FSSpec File Manager >calls."If Gestalt returns a system version < 7 you might add "You should >upgrade to System 7." Or, perhaps, "_MakeFSSpec is not available." :-> Better yet, explain in details that are useful to the typical user: " requires System 7 or later." or " requires a floating point unit." or " requires color support (Mac II or better)." If you really think the user wants to know which particular feature isn't available, encode it as a little digit somewhere, and put it in the documentation. Since one can't get the revised file manager *without* System 7, telling them they need it won't really help them solve their problem. -- -Bill Hofmann wdh@netcom.COM Fresh Software and Instructional Design +1 510 524 0852 +++++++++++++++++++++++++++ >From gurgle@netcom.com (Pete Gontier) Date: Sat, 26 Feb 1994 22:34:34 GMT Organization: cellular wdh@netcom.com (Bill Hofmann) writes: >the documentation. Since one can't get the revised file manager >*without* System 7, telling them they need it won't really help them >solve their problem. Untrue. One can get it with QuickTime. I'm not sure if the Gestalt selector gets installed, though. I believe you have to test for QuickTime *or* the new File Manager calls, and then use the subset of the new File Manager calls which are in QuickTime. This is a thorny problem, and in general I think you are right to suggest that the message talk about System 7 instead of the new File Manager calls, but in this particular case, there is a solution other than System 7. It's hard to know what to put in the message. -- Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com +++++++++++++++++++++++++++ >From rgaros@bio.vu.nl (Rene G.A. Ros) Date: Sun, 27 Feb 1994 09:17:37 GMT Organization: VU Biology, Amsterdam, The Netherlands gurgle@netcom.com (Pete Gontier) writes: : wdh@netcom.com (Bill Hofmann) writes: : : >the documentation. Since one can't get the revised file manager : >*without* System 7, telling them they need it won't really help them : >solve their problem. : : Untrue. One can get it with QuickTime. I'm not sure if the Gestalt : selector gets installed, though. I believe you have to test for : QuickTime *or* the new File Manager calls, and then use the subset of : the new File Manager calls which are in QuickTime. >From my Suppl. Gestalt Selectors list: QuickTime --------- If you install QuickTime under System 6, a major portion of the Alias Manager and FSSpec support is also added. But, QT doesn't implement the Gestalt selectors because the implementation is not complete. You must check for either Alias Mgr or QuickTime. (Michael Hecht) If QuickTime is present, assume you have an Alias Manager, subject to some limitations (NewAliasMinimalFromFullPath not present). Nearly all the FSSpec calls are available (except FSpExchangeFiles) in System 6 when QuickTime is installed. See for more information Technical Note M.QT.MovieTB.Q&As (QT 510). Regards, Rene -- -------------------------------------------------------------------------------- Rene G.A. Ros Amsterdam, The Nederlands rgaros@bio.vu.nl rgaros@nikhefk.nikhef.nl rener@htsa.aha.nl +++++++++++++++++++++++++++ >From partingt@fwi.uva.nl (Vincent Partington) Date: 27 Feb 1994 15:21:01 GMT Organization: FWI, University of Amsterdam rgaros@bio.vu.nl (Rene G.A. Ros) writes: >QuickTime >--------- >If you install QuickTime under System 6, a major portion of the Alias >Manager and FSSpec support is also added. But, QT doesn't implement the >Gestalt selectors because the implementation is not complete. You must >check for either Alias Mgr or QuickTime. (Michael Hecht) >If QuickTime is present, assume you have an Alias Manager, subject to some >limitations (NewAliasMinimalFromFullPath not present). Nearly all the >FSSpec calls are available (except FSpExchangeFiles) in System 6 when >QuickTime is installed. See for more information Technical Note >M.QT.MovieTB.Q&As (QT 510). What a shame, no FSpExchangeFiles! That's the one I really like about the new calls. Well, I think assuming the FSSpec calls are then when QuickTime is, is weird anyway, so I wouldn't have checked one way or another. I really like a lot of other things about Sys7 too: Alias Manager, Find Folder, Popup CDEF, Apple Events, Notification manager, Temporary Memory (OK, MultiFinder has it too, but not "real" temp mem), CustomGetFile, so supporting Sys6 would be a real drag. Vincent. -- VI is better than Emacs. | Let's | Internet : partingt@fwi.uva.nl MacOS is better than Windows. | start the | vincent@tnc.nl Unix is better than VMS. | religious | FidoNet : 2:281/202.15 Eiffel is better than C++. | war!! | NeST : 90:500/202.15 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 28 Feb 94 16:30:50 +1300 Organization: University of Waikato, Hamilton, New Zealand In article , gurgle@netcom.com (Pete Gontier) writes: > wdh@netcom.com (Bill Hofmann) writes: > >>the documentation. Since one can't get the revised file manager >>*without* System 7, telling them they need it won't really help them >>solve their problem. > > Untrue. One can get it with QuickTime. I'm not sure if the Gestalt > selector gets installed, though. I believe you have to test for > QuickTime *or* the new File Manager calls, and then use the subset of > the new File Manager calls which are in QuickTime. > > This is a thorny problem, and in general I think you are right to > suggest that the message talk about System 7 instead of the new File > Manager calls, but in this particular case, there is a solution other > than System 7. It's hard to know what to put in the message. My ad hoc, informal guideline, which I just thought up off the top of my head, is "explain just the simplest case". If you need the new File Manager calls, then I personally would just say "I need System 7 or later". If in fact the program can be made to work under 6.0.7 with QuickTime installed, then you can explain that in the documentation somewhere, or as an answer to a tech support question. Don't try to burden your compatibility messages with all the possible situations. It's less confusing that way. Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 "Classical Paintings: DaVinci, Degauss, Rembrant, Van Gogh and more! View the works of history's finest artists." -- ad quoted in PC Magazine +++++++++++++++++++++++++++ >From alana@cs.uoregon.edu (Alan Akins) Date: 28 Feb 1994 08:24:00 -0800 Organization: The uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy. In article <1994Feb27.091737.5150@bio.vu.nl>, Rene G.A. Ros wrote: >If you install QuickTime under System 6, a major portion of the Alias >Manager and FSSpec support is also added. But, QT doesn't implement the >Gestalt selectors because the implementation is not complete. You must >check for either Alias Mgr or QuickTime. (Michael Hecht) >If QuickTime is present, assume you have an Alias Manager, subject to some >limitations (NewAliasMinimalFromFullPath not present). Nearly all the >FSSpec calls are available (except FSpExchangeFiles) in System 6 when >QuickTime is installed. See for more information Technical Note >M.QT.MovieTB.Q&As (QT 510). Is this still true of QuickTime 2.0? Have they "completed" the implementation? /Alan\ -- * "Evan's been doing parallel | Alan Akins * * processing for so long... | alana@cs.uoregon.edu * * he's beside himself." | University of Oregon * * - Me | Department of Computer Science * +++++++++++++++++++++++++++ >From rgaros@paramount.nikhefk.nikhef.nl (Rene Ros) Date: Mon, 28 Feb 1994 17:52:43 GMT Organization: NIKHEFK alana@cs.uoregon.edu (Alan Akins) writes: : In article <1994Feb27.091737.5150@bio.vu.nl>, : Rene G.A. Ros wrote: : : >If you install QuickTime under System 6, a major portion of the Alias : >Manager and FSSpec support is also added. But, QT doesn't implement the : >Gestalt selectors because the implementation is not complete. You must : >check for either Alias Mgr or QuickTime. (Michael Hecht) : >If QuickTime is present, assume you have an Alias Manager, subject to some : >limitations (NewAliasMinimalFromFullPath not present). Nearly all the : >FSSpec calls are available (except FSpExchangeFiles) in System 6 when : >QuickTime is installed. See for more information Technical Note : >M.QT.MovieTB.Q&As (QT 510). : : Is this still true of QuickTime 2.0? Have they "completed" the implementation? Don't shoot the messenger! :-) I have no idea if QT 2.0 implements the Alias Mgr and FSSpec calls. Would be nice, the gestalt selectors should then be installed also. So, simple check for the selectors now and perhaps you will support System 6/QT in the future? I myself use two procedures to determine if the Alias Mgr is partially or fully installed. Where I use the 'qtim' selector to see if it is partiallu installed. If someone has anymore info about this regarding QT 2.0 I would like to know. Or has someone the email address of 'the powers that be' at Apple? :-) The prese release didn't say anything about it, which doesn't surprise me. Rene +++++++++++++++++++++++++++ >From bc@wetware.com (monsieur HAINEUX) Date: Tue, 1 Mar 1994 00:45:14 GMT Organization: /usr/local/lib/rn/organization The problem with configuration problems is that most users will need more explanation than you can fit in a dialog box. Even if you can fit the whole explanation in a dialog box, most users will forget what the dialog says as soon as it's gone, or see all those words and call Tech Support before thinking anything through. The trick is to explain the situation in a pithy, easily-memorable way in the dialog, then explicitly point to the documentation for further explanation. For example: (STOP) Missing resources: cannot launch. Some necessary resources are not present in your Macintosh. Please check the "Configuration Requirements" section in your manual. ErrNo: <12345> (Quit) (STOP) No Color Available: cannot launch. cannot find a color screen connected to your Macintosh. Please chek the "Configuration Requirements" section in your Manual. ErrNo: <12347) (Quit) It's up to you to provide the documentation that explains the whole deal. For example, the documentation might read: CONFIGURATION REQUIREMENTS requires a Mac Minus or better to run, System 7.0 or newer, 4 bit color, 437 MB of RAM memory, and 34K of disk space (minimum). We recommend for best performance, however, that you turn off virtual memory and make sure your entire hard disk is blank. If your Mac doesn't have enough memory, throw it away and buy a new one. If it has the required memory, but still won't launch, try turning off memory-using INITs, quitting other apps, and waving a dead chicken over it. NOTE: Technically advanced users may be able to run by installing GreedManager 3.17 and FondleMonger 1.0d127c23 on System 6.x. If you would like support on how to set up this configuration, kindly submit your request on the back of a hundred-dollar bill to:... Later, in the appendix on Error Numbers, you have your choice. If you want to reserve a whole suite of errnos for launch fail, you can have separate messages in the index: ERNO Explanation 12345 GreedManager is missing. See "REQUIREMENTS" section of manual. 12346 FondleMonger is missing. See "REQUIREMENTS" section of manual. Or you can have just one: ERRNO Explanation 12345 Mac does not meet minimum configuration requirements. See "REQUIREMENTS" section of manual. bill coderre --------------------------- >From Joshua Joseph Marks Subject: small snag Date: Mon, 28 Feb 1994 18:43:17 -0500 Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA I have this one problem that is probably linked to not being familiar with writing code on the MAcintosh, or it could be just a big oversite. I have a structure defined as: struct branch { short type,xi,yi; } when running through the following code I get a BUS ERROR struct element *Init_Branch (short x, short y, float direction, short length) { struct element *new_element; new_element = (struct element*) malloc (sizeof (struct element)); if (new_element == NIL) ExitToShell(); new_element->xi = x_start; new_element->yi = y_start; new_element->type = BRANCH_LENGTH; .... The problem is of course the malloc, which screws everything up when it gets two lines later. I cant seem to trace where the problem is. I have the struct defined in a seperate header file that is included at the top, and I have a the segments placed so that 2 contains ANSI and the main portion, and 3 contains MacTraps and all suboordinate proceddures. Does the way you segment things matter? Does ANSI have to be somewhere. Thanks for any suggestions and thanks doubly for solutions. Josh +++++++++++++++++++++++++++ >From mssmith@afterlife.ncsc.mil (M. Scott Smith) Date: Tue, 1 Mar 1994 01:19:14 GMT Organization: The Great Beyond In article Joshua Joseph Marks writes: >I have this one problem that is probably linked to not being familiar >with writing code on the MAcintosh, or it could be just a big oversite. > > (problem described) > >The problem is of course the malloc, which screws everything up when it >gets two lines later. I cant seem to trace where the problem is. I >have the struct defined in a seperate header file that is included at >the top, and I have a the segments placed so that 2 contains ANSI and >the main portion, and 3 contains MacTraps and all suboordinate >proceddures. Does the way you segment things matter? Does ANSI have to >be somewhere. Thanks for any suggestions and thanks doubly for >solutions. > Josh > Josh, I'm going to take a very wild guess of what *might* be your problem, without studying your code too much. If you're not including , MAKE SURE you do. At the start of your program, do this: #include If you're not doing this, then I'd suspect that's your problem, because I've had the same problem in the past. If I recall correctly, there's a couple different versions of malloc out there, and unless you include stdlib.h you're not getting the right one. (I forget the exact reasoning behind this.) The standard libraries reference for Think C (as well as Think Reference 2.0 database module included w/Think C v6.0x) mentions that "if you have any problems with malloc(), make sure you #included stdlib.h in your source file. I believe it. So definitely do that if you aren't. If you are, well, umm, uhh.. Sorry to have gotten your hopes up. But to answer some of your questions, no, it doesn't matter how you segment things. Segments are transparent to the programmer, although if you know what you're doing you can fool around with placement of files in the segment to speed up programs. (For example, code segments are loaded into memory one at a time. You can "pre-load" segments that contain frequently-used code. You might toss code that prints a document in a separate code segment that you don't preload, since users don't print documents that much. When the user does print the document, there might be a pause as that segment is loaded from disk.) BUT, all of this is transparent to you. It's all memory management magic. You'll also benefit from learning about NewPtr and NewHandle, which are the "cool" ways of allocating memory on the Macintosh. Lots of people have problems with the ANSI routines. But few people use them. Most people use the Mac-specific routines, and few people have problems with them. (Huh?) :) Don't take too much faith in this, but this is how you can allocate structures using the Mac's NewPtr routine: (borrowed partially from Think Ref) struct MyStruct { short tall; } struct MyStruct *myStructPtr; myStructPtr = (struct myStruct *)NewPtr(sizeof(MyStruct)); then you can do.. x = myStructPtr->tall; And you'll eventually probably want to use Handles, but those can be tricky and I won't go into them now. Good luck! (And I hope the is all you need..) Scott --- M. Scott Smith (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu) Macintosh developer. Ski bum. Student. Eater of Cadbury Creme Eggs. --------------------------- End of C.S.M.P. Digest **********************