From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-043 Date: Sat, 9 Jul 1994 13:50:38 +0200 (MET DST) C.S.M.P. Digest Sat, 09 Jul 94 Volume 3 : Issue 43 Today's Topics: 7.5 Floating Window (How To use?) Can Mac's survive without AppleTalk? CodeWarrior and CODE Resources Fast full screen scrolling: impossible? MacPerl- Redirecting STDIN & STDOUT PowerPC floating point issue Q: Thread Manager - How do I benefit? prevent update when call TEDelete, TEInsert?? The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From denboer@cc.umanitoba.ca (David Den Boer) Subject: 7.5 Floating Window (How To use?) Date: 22 Jun 1994 01:49:42 GMT Organization: The University of Manitoba I have seen various discussions on the appearance of the 7.5 floater, but I don't care about that (although I find it quite attractive!) I want to know how to use it from my apps?!?! Is there a standard built in WDEF, or do I have to copy and paste it from some other resource? How to unlock the funkiness of the window is a more appropriate title... Thanks -- David A. denBoer University of Manitoba denboer@CC.UManitoba.CA Computer Services -- User Services +++++++++++++++++++++++++++ >From trygve@netcom.com (Trygve Isaacson) Date: Thu, 23 Jun 1994 03:30:39 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) The resource ID is 125. So when creating your window, specify a procID of 125*16 + variants to use it. The variants I've discovered are: 4 - adds a zoom box 8 - puts the title bar on the left (12 for both) Trygve Isaacson Wall Data Incorporated +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Wed, 22 Jun 1994 21:14:02 -0700 Organization: Infinity Systems In article <2u85bm$aik@canopus.cc.umanitoba.ca>, denboer@cc.umanitoba.ca (David Den Boer) wrote: > I have seen various discussions on the appearance of the 7.5 floater, but > I don't care about that (although I find it quite attractive!) > I want to know how to use it from my apps?!?! > Is there a standard built in WDEF, or do I have to copy and paste it from > some other resource? > > How to unlock the funkiness of the window is a more appropriate title... First, make sure the user is running System 7.5. It isn't available in eariler System versions -- Apple has said that they will release a 'compatibility' WDEF that you will be able to include in your App that will call through to the System floater WDEF if it is present (like the Movable Modal WDEF they released for compatibility with System 6). Second, call NewWindow: wind = NewWindow(wStorage, &rBounds, title, visFlag, wDefProcID, behind, goAwayFlag, refCon); For the wDefProcID, pass in: (125 * 16 + procID) 125 is the ID of the WDEF resource in the System file, and this is the equation Apple describes to make the Window Manager use a custom WDEF. The procID will modify the WDEF in the following way: Add To Get --- ------ 1 A windoid that hilights and dims depending on HiliteWindow. The default is for the titlebar to always show the pattern. (The default is bad if a dialog will appear in front of the floater because then the floater should appear dimmed.) 2 To get a grow box. 4 To get a zoom box. 8 For a titlebar down the left hand side. They can be added together to get a combination of the effects. Also, if you pass in a non-empty string in 'title', it will be displayed in Geneva 9 plain (assuming the titlebar is across the top). Note that if you use a grow box, there is a problem where the grow box will show through any windows in your application that appear above it. Appearantly, the new WDEF is not obeying the window's clipping region when drawing the grow box. Also, the grow box is one pixel narrower than the standard grow box, which means that a scroll bar will look strange when scaled to match it, and it doesn't dim then the rest of the windoid dims (when procID 1 is used). The titlebar flashes more than it needs to when being redrawn, and I have also heard that there are some problems with multiple monitors. _troy //////// //////___Troy Gaul_________________________tgaul@halcyon.com__ // // // Infinity Systems ; Redmond, Washington // // // // "Insert witty quote here." // // //////________________________________________________________ // +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Thu, 23 Jun 1994 15:35:07 +0800 Organization: NCRPDA, Curtin University In article <2u85bm$aik@canopus.cc.umanitoba.ca>, denboer@cc.umanitoba.ca (David Den Boer) wrote: >I have seen various discussions on the appearance of the 7.5 floater, but >I don't care about that (although I find it quite attractive!) >I want to know how to use it from my apps?!?! >Is there a standard built in WDEF, or do I have to copy and paste it from >some other resource? > >How to unlock the funkiness of the window is a more appropriate title... Use WDEF 125, ie proc id 125*16+x where x is between 0 and 15 depending on whether you want a left hand title bar, with or without close/zoom boxes. wp:=NewWindow(nil,bounds,"'Hello',true,125*16,pointer(-1),true,0); Enjoy, Peter. _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 --------------------------- >From mxmora@unix.sri.com (Matt Mora) Subject: Can Mac's survive without AppleTalk? Date: 16 Jun 1994 11:56:40 -0700 Organization: SRI International, Menlo Park, CA They are about to re-do the networks around here, putting in fiber and ethernet everywhere. They were saying that they would no longer support AppleTalk. Of course I went into a tizzy and started sending memo's everywhere to whom ever I thought was in charge (which at SRI could be anybody or nobody). They mention the AppleTalk support would only be supported in the near future and that you could do appletalk on subnets. Is Apple moving away from AppleTalk? They seem to be under the impression that Apple is going away from appletalk and are moving to something else. I was at the WWDC and I don't remember any thing mentioned like this. So if I only have a MacTCP connection from my mac to the network will I still be able to print, File Share, do PowerTalk stuff, connect to other programs running on other macs, use the new MovieTalk, network backup and other cool things? What would happen if Appletalk wasn't supported on your net? Maybe I'm blowing this thing out of proportion and other companies are doing the same things. Does this sound like a logical thing to do? Is this going to save money? Thanks Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From stan@astro.ocis.temple.edu (Stan Horwitz) Date: 16 Jun 1994 20:19:57 GMT Organization: Temple University, Academic Computer Services Matt Mora (mxmora@unix.sri.com) wrote: : They are about to re-do the networks around here, putting in : fiber and ethernet everywhere. They were saying that : they would no longer support AppleTalk. Of course I went : into a tizzy and started sending memo's everywhere to whom : ever I thought was in charge (which at SRI could be anybody or nobody). : They mention the AppleTalk support would only be supported in the : near future and that you could do appletalk on subnets. Macs can survive without Appletalk just fine. The Mac I am using now is ethernetted and it works fine in general and its much faster than Appletalk. The only thing I hate about this setup is that when the network service you are using, or the network itself, goes down or slows up, it can make your Mac look like it hangs until things on the network normalize again. This may just be a quirk in the ethernet card (Asante) my Mac has in it though. -- My name is Stan Horwitz and my E-mail address is stan@astro.ocis.temple.edu My opinions are all mine. They do not reflect those of my employer. +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Thu, 16 Jun 1994 22:49:15 GMT Organization: National Renewable Energy Laboratory In article <2tq798$s6t@unix.sri.com> Matt Mora, mxmora@unix.sri.com writes: >They are about to re-do the networks around here, putting in >fiber and ethernet everywhere. They were saying that >they would no longer support AppleTalk. Of course I went >into a tizzy and started sending memo's everywhere to whom >ever I thought was in charge (which at SRI could be anybody or nobody). >They mention the AppleTalk support would only be supported in the >near future and that you could do appletalk on subnets. > >Is Apple moving away from AppleTalk? They seem to be under the impression >that Apple is going away from appletalk and are moving to something else. >I was at the WWDC and I don't remember any thing mentioned like this. It is very common to confuse to completely different terms -- AppleTalk and LocalTalk. AppleTalk is a network protocol, and LocalTalk is a method of network wiring. AppleTalk can operate over LocalTalk, Ethernet or through a modem using ARA, for example. Modern Ethernet routers are multiprotocal, which means they know how to deliver packets for a variety of protocols, including AppleTalk. I suspect that what your networking types meant was that they would no longer support LocalTalk wiring (or PhoneNet, for that matter) which runs at about 240 kbs. I really don't see Apple sacking AppleTalk (the protocol). +++++++++++++++++++++++++++ >From Sean McMains Date: 16 Jun 1994 22:02:06 GMT Organization: University of North Texas In article <2tq798$s6t@unix.sri.com> Matt Mora, mxmora@unix.sri.com writes: >Is Apple moving away from AppleTalk? They seem to be under the impression >that Apple is going away from appletalk and are moving to something else. >I was at the WWDC and I don't remember any thing mentioned like this. It looks like some folks are getting confused on the AppleTalk vs. LocalTalk distinction. Ready? Everyone together: "AppleTalk is a protocol. LocalTalk is a transport." :-) With that out of my system, your question would seem to indicated that the net boys at your place are planning not to route AppleTalk from subnet to subnet on an ethernet network. In the current networking incarnation, this would mean that all the network stuff that doesn't rely on MacTCP would not work. Apple has something called Open Transport in the works which will allow use of other transports to provide various functionality in a modular form (sort of a souped up, network-studly communication toolbox kinda thing). I don't know how backward compatible it will be, but the presentation I saw made it clear that they would not be replacing AppleTalk. I would suggest you fight as hard as you can to keep Appletalk routing on your networks until we see what Open Transport will do (and how backward-compatible it is with existing software). ======================================================================== Sean McMains | P.O. Box 13495 | Phone:817.565.2039 Macintosh Support | Denton TX 76203 | Fax :817.565.4060 University of North Texas | EMail: mcmains@unt.edu | WWW: http://gaia.nms.unt.edu/cchome/mcmains/mcmains.html +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 16 Jun 1994 14:07:46 -0700 Organization: SRI International, Menlo Park, CA In article <2tqc5d$av@cronkite.ocis.temple.edu> stan@astro.ocis.temple.edu (Stan Horwitz) writes: >Macs can survive without Appletalk just fine. The Mac I am using now is >ethernetted and it works fine in general and its much faster than Appletalk. >The only thing I hate about this setup is that when the network service you >are using, or the network itself, goes down or slows up, it can make your >Mac look like it hangs until things on the network normalize again. This >may just be a quirk in the ethernet card (Asante) my Mac has in it though. I just want to make it clear I'm talking about AppleTalk not LocalTalk. LocalTalk is the Twisted Pair wiring that runs a 230kb. I'm talking about the AppleTalk protocol that runs on any network medium be it LocalTalk Ethernet or what ever. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From aelman@cs.stanford.edu (Adam Elman) Date: Thu, 16 Jun 1994 16:38:31 -0800 Organization: Residential Computing, Stanford University In article <2tqc5d$av@cronkite.ocis.temple.edu>, stan@astro.ocis.temple.edu (Stan Horwitz) wrote: > Matt Mora (mxmora@unix.sri.com) wrote: > : They are about to re-do the networks around here, putting in > : fiber and ethernet everywhere. They were saying that > : they would no longer support AppleTalk. Of course I went > : into a tizzy and started sending memo's everywhere to whom > : ever I thought was in charge (which at SRI could be anybody or nobody). > : They mention the AppleTalk support would only be supported in the > : near future and that you could do appletalk on subnets. > > Macs can survive without Appletalk just fine. The Mac I am using now is > ethernetted and it works fine in general and its much faster than Appletalk. > The only thing I hate about this setup is that when the network service you > are using, or the network itself, goes down or slows up, it can make your > Mac look like it hangs until things on the network normalize again. This > may just be a quirk in the ethernet card (Asante) my Mac has in it though. There is some confusion on this point: AppleTalk is the software protocol, which is critical to standard Mac networking (printing, AppleShare, the new PowerTalk stuff, etc.). The standard Mac hardware network wiring protocol, which was originally named AppleTalk, was renamed LocalTalk. Farallon markets a version of LocalTalk which runs over standard phone wire and is called PhoneNet; this has generally become much more common than Apple's original LocalTalk wiring. AppleTalk runs just fine over Ethernet, fiber, whatever. Apple is definitely moving away from LocalTalk -- all new Macs except for the lowest models have built-in Ethernet ports. But Apple is certainly not moving away from the software protocol. -- Adam Elman | WWW: http://rescomp.stanford.edu/~elmanad/ aelman@cs.stanford.edu | Finger me or check out my Web page for PGP key!!! - ------------------------------------------------------------------------ "Sometimes I lie awake at night and ask 'Why me?' Then a voice answers 'Nothing personal, your name just happened to come up.'" -- Peanuts +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Thu, 16 Jun 1994 19:18:36 -0700 Organization: Internet for the Olympic Peninsula In article <2tq798$s6t@unix.sri.com>, mxmora@unix.sri.com (Matt Mora) wrote: > They are about to re-do the networks around here, putting in > fiber and ethernet everywhere. They were saying that > they would no longer support AppleTalk. Of course I went > into a tizzy and started sending memo's everywhere to whom > ever I thought was in charge (which at SRI could be anybody or nobody). > They mention the AppleTalk support would only be supported in the > near future and that you could do appletalk on subnets. > > Is Apple moving away from AppleTalk? They seem to be under the impression > that Apple is going away from appletalk and are moving to something else. > I was at the WWDC and I don't remember any thing mentioned like this. Well, the new machines have EtherNet built in. One could certainly read a long-term trend away from AppleTalk in that. And it makes sense...AppleTalk was fine 10 years ago...it's slow now, and not really likely to get faster (it's stressing the serial connection as it is). > > What would happen if Appletalk wasn't supported on your net? I'd plug in the EtherNet connection on my 8100, and buy an EtherNet card for my IIci. I may anyhow. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Fri, 17 Jun 1994 11:13:22 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Matt Mora (mxmora@unix.sri.com) wrote: > Is Apple moving away from AppleTalk? They seem to be under the impression > that Apple is going away from appletalk and are moving to something else. > I was at the WWDC and I don't remember any thing mentioned like this. Open Transport (remember them? You got a T shirt at the netter's dinner) is only intended to replace MacTCP and the software layers, not the actual AppleTalk protocol. Definately put up a fight. I know that network guys just hate AppleTalk's constant address pinging. ;) As Nixon always said, " them." Don't let them demote AppleTalk to a second class protocol. Jon +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 17 Jun 1994 11:45:44 -0700 Organization: SRI International, Menlo Park, CA In article jonpugh@netcom.com (Jon Pugh) writes: >Matt Mora (mxmora@unix.sri.com) wrote: > >> Is Apple moving away from AppleTalk? They seem to be under the impression >> that Apple is going away from appletalk and are moving to something else. >> I was at the WWDC and I don't remember any thing mentioned like this. > >Open Transport (remember them? You got a T shirt at the netter's >dinner) is only intended to replace MacTCP and the software layers, >not the actual AppleTalk protocol. Yes I remember the shirt. I was wearing it yesterday at the standards meeting when I stood up and officially protested. >Definately put up a fight. I know that network guys just hate AppleTalk's >constant address pinging. ;) As Nixon always said, " >them." Don't let them demote AppleTalk to a second class protocol. Well I talked to our network guru (the actual engineer here that is resposible for the new net) and he said that they have to pass Appletalk if we are going to continue to have Macs here. What does he care its just another protocol. He also said that he could install one gatorbox to just broadcast zone names if need be. As always management has its collective head up a dark orafice. :-) Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From doc@miracle.farallon.com (eric doc kampman) Date: Fri, 17 Jun 1994 17:44:49 -0800 Organization: farallon In article , jonpugh@netcom.com (Jon Pugh) wrote: > Matt Mora (mxmora@unix.sri.com) wrote: > > > Is Apple moving away from AppleTalk? They seem to be under the impression > > that Apple is going away from appletalk and are moving to something else. > > I was at the WWDC and I don't remember any thing mentioned like this. > > Open Transport (remember them? You got a T shirt at the netter's > dinner) is only intended to replace MacTCP and the software layers, > not the actual AppleTalk protocol. uh oh. anybody know what this means for custom 'mdev's? (alternate LAP layer interfaces for MacTCP). -- doc@miracle.farallon.com Farallon didn't write this, Farallon isn't responsible for its con- tents, besides, who's Farallon anyway? ****************************************************************** Look for the thing you can't find/Seeing with eyes makes you blind You know you're out of your mind +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Sun, 19 Jun 1994 01:46:44 +1200 (NZST) Organization: (none) jwbaxter@olympus.net (John W. Baxter) writes: > > Is Apple moving away from AppleTalk? They seem to be under the impression > > that Apple is going away from appletalk and are moving to something else. > > I was at the WWDC and I don't remember any thing mentioned like this. > > Well, the new machines have EtherNet built in. One could certainly read a > long-term trend away from AppleTalk in that. And it makes > sense...AppleTalk was fine 10 years ago...it's slow now, and not really > likely to get faster (it's stressing the serial connection as it is). > > > > > What would happen if Appletalk wasn't supported on your net? > > I'd plug in the EtherNet connection on my 8100, and buy an EtherNet card > for my IIci. I may anyhow. Aaarrggghhhh!!!! Those EtherNet connections *are* running AppleTalk (99% of them, anyway) Matt was quite clearly talking about AppleTalk-the-protocol-stack, and not AppleTalk-the-low-speed-wiring-system. Even if you didn't know that the wiring has been called LocalTalk for at least five years now, it was pretty clear that he was talking about TCP/IP vs AppleTalk and not EtherTalk vs LocalTalk. -- Bruce +++++++++++++++++++++++++++ >From ce_rupn@pavo.concordia.ca (RUPNIK, CHRISTOPHER E.) Date: Sat, 18 Jun 1994 16:20:00 GMT Organization: Concordia University In article <2854835204@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes... >jwbaxter@olympus.net (John W. Baxter) writes: >> > Is Apple moving away from AppleTalk? They seem to be under the impression >> > that Apple is going away from appletalk and are moving to something else. >> > I was at the WWDC and I don't remember any thing mentioned like this. >> >> Well, the new machines have EtherNet built in. One could certainly read a >> long-term trend away from AppleTalk in that. And it makes >> sense...AppleTalk was fine 10 years ago...it's slow now, and not really >> likely to get faster (it's stressing the serial connection as it is). >> >> > >> > What would happen if Appletalk wasn't supported on your net? >> >> I'd plug in the EtherNet connection on my 8100, and buy an EtherNet card >> for my IIci. I may anyhow. > >Aaarrggghhhh!!!! > >Those EtherNet connections *are* running AppleTalk (99% of them, anyway) > >Matt was quite clearly talking about AppleTalk-the-protocol-stack, and not >AppleTalk-the-low-speed-wiring-system. Even if you didn't know that the >wiring has been called LocalTalk for at least five years now, it was pretty >clear that he was talking about TCP/IP vs AppleTalk and not EtherTalk vs >LocalTalk. > >-- Bruce Yes, he is correct. It appears that mac people will never learn the appletalk/localtalk/ethertalk differences and what whey actually mean. As for Appletalk being "dead" the original poster is correct. Apple is supposed to implement a completely rewritten new stack called Oxx something The reason for this is that the appletalk stack is not native powerpc, this means that an appleshare server based on powermac is just not going give a reasonable performance.... Chris Rupnik ce_rupn@pavo.concordia.ca +++++++++++++++++++++++++++ >From jep@unlinfo.unl.edu (Stephen Panarelli) Date: 19 Jun 1994 11:30:40 GMT Organization: University of Nebraska--Lincoln Carl R. Osterwald (carl_osterwald@nrel.gov) wrote: : In article <2tq798$s6t@unix.sri.com> Matt Mora, mxmora@unix.sri.com : writes: : >They are about to re-do the networks around here, putting in : >fiber and ethernet everywhere. They were saying that : >they would no longer support AppleTalk. Of course I went : >into a tizzy and started sending memo's everywhere to whom : >ever I thought was in charge (which at SRI could be anybody or nobody). : >They mention the AppleTalk support would only be supported in the : >near future and that you could do appletalk on subnets. : > : >Is Apple moving away from AppleTalk? They seem to be under the impression : >that Apple is going away from appletalk and are moving to something else. : >I was at the WWDC and I don't remember any thing mentioned like this. : It is very common to confuse to completely different terms -- AppleTalk : and LocalTalk. AppleTalk is a network protocol, and LocalTalk is a : method of network wiring. AppleTalk can operate over LocalTalk, Ethernet Then there's LocalTalk Link Access Protocall....(: : or through a modem using ARA, for example. Modern Ethernet routers are : multiprotocal, which means they know how to deliver packets for a variety : of protocols, including AppleTalk. I suspect that what your networking : types meant was that they would no longer support LocalTalk wiring (or : PhoneNet, for that matter) which runs at about 240 kbs. I really don't : see Apple sacking AppleTalk (the protocol). steve. -- _/_/_/_/_/ _/ _/ _/_/_/_/ | Stephen Kemal Panarelli _/ _/ _/ _/ _/ | University of Nebraska _/_/_/_/_/ _/_/_/ _/_/_/_/ | Electrical Engineering _/ _/ _/ _/ | jep@unlinfo.unl.edu _/_/_/_/_/ _/ _/ _/ | panzar@yoda.unl.edu +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 20 Jun 94 17:15:51 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , jonpugh@netcom.com (Jon Pugh) writes: > > Definately put up a fight. I know that network guys just hate AppleTalk's > constant address pinging. ;) That pinging is the sound of AppleTalk configuring itself, so you don't have to! We have maybe 500 Macs on campus. Nearly every one is an AppleTalk node, and most of them are TCP/IP nodes as well. There are a roughly equal number of Intel-based machines, workstations and the like, which are also TCP/IP nodes. So the ratio of TCP/IP nodes to AppleTalk nodes is 2:1. What do you think the administration overhead is? More like 10:1 in terms of personnel, time spent on address housekeeping, sorting out configuration stuffups by stupid users, and general aggro. AppleTalk still remains the world's easiest-to-use local area networking protocol. No contest. 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+12:00 Where would we be without rhetorical questions? +++++++++++++++++++++++++++ >From somogyi@ziff.com (Stephan Somogyi) Date: Mon, 20 Jun 1994 06:32:10 GMT Organization: Digital Media In article , jonpugh@netcom.com (Jon Pugh) wrote: > Open Transport (remember them? You got a T shirt at the netter's dinner) > is only intended to replace MacTCP and the software layers, not the > actual AppleTalk protocol. Nonono! OpenTransport comes with brand new protocol stacks for both AppleTalk and TCP/IP. OT has a compatibility mode that allows existing software using today's AppleTalk and MacTCP API's to function, but internally it's all new stuff. OT will also be the only native AppleTalk protocol stack. Back to Matt's original question: even if they ban AppleTalk off the backbone, you can still use it locally; it just won't be propagated through the router that connects you to the rest of your organization. This isn't necessarily a fundamentally Bad Thing -- it depends on whether you use AppleTalk services that are on the far end of your backbone router. ____________________________________________________________________________ Stephan Somogyi Vorsprung durch Technik Digital Media +++++++++++++++++++++++++++ >From somogyi@ziff.com (Stephan Somogyi) Date: Mon, 20 Jun 1994 06:33:31 GMT Organization: Digital Media In article , doc@miracle.farallon.com (eric doc kampman) wrote: > uh oh. anybody know what this means for custom 'mdev's? (alternate LAP > layer interfaces for MacTCP). Check out the OpenTransport docs on the WWDC CD. Methinks there should be some info in there on how such stuff is handled under OT. ____________________________________________________________________________ Stephan Somogyi Vorsprung durch Technik Digital Media +++++++++++++++++++++++++++ >From poorman@convex.com (Peter W. Poorman) Date: 20 Jun 94 16:50:10 GMT Organization: CONVEX Computer Corporation, Richardson, TX USA In doc@miracle.farallon.com (eric doc kampman) writes: >uh oh. anybody know what this means for custom 'mdev's? (alternate LAP >layer interfaces for MacTCP). The docs I looked at said that custom mdevs would NOT be supported. This may have changed -- it's been awhile. The docs were ftp-able from seeding.apple.com. -- Pete poorman@convex.com +++++++++++++++++++++++++++ >From gabe@shiva.com (Gabriel Lawrence) Date: Mon, 20 Jun 94 21:47:28 GMT Organization: Shiva Corporation >>uh oh. anybody know what this means for custom 'mdev's? (alternate LAP >>layer interfaces for MacTCP). > >The docs I looked at said that custom mdevs would NOT be supported. This >may have changed -- it's been awhile. The docs were ftp-able from >seeding.apple.com. As far as I can know, adevs, mdevs, and CommToolBox tools are all rendered obsolete by the Open Transport architecture. Adevs and mdevs are both LAP layer protocol switching mechanisms which are redundant under Streams. In general, Streams allows a lot more flexibility in constructing protocol stacks. Rather than just switching among the bottom (LAP) layers, you can construct a complete custom stack that contains the protocol layers you need to use. This design also allows you to run multiple protocol stacks simultaneously. CTB tools are considered flawed because you cannot layer them. Personally, I never much cared for the interfaces either. Streams provides a standard way to layer modules so that you can customize your comm tools to your hearts content. =Gabe= - ---------------------- Gabriel Lawrence Shiva Corporation Software Tool "All Disclaimers Apply" gabe@shiva.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 21 Jun 1994 16:11:01 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Jun20.171551.29956@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: >AppleTalk still remains the world's easiest-to-use local area networking >protocol. No contest. Definitely. Until you want to change zones names of course ): -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Who's changed zone names twice in the past year and is getting very bitter and twisted about it. +++++++++++++++++++++++++++ >From garryh@seeding.apple.com (Garry Hornbuckle) Date: 21 Jun 1994 16:17:55 GMT Organization: Apple Computer > In article , doc@miracle.farallon.com > (eric doc kampman) wrote: > > > uh oh. anybody know what this means for custom 'mdev's? (alternate LAP > > layer interfaces for MacTCP). 1 - AppleTalk is not going away or dying. Apple still feels that AppleTalk is important and useful. 2 - We are making a conscious effort at bringing our support of other protocols, especially TCP/IP, a more visibile and 'expected' thing. Such as moving MacTCP into system software. I'd like people to begin to think of the Macintosh as not just the machine with 'built-in networking', but the machine with 'multiprotocol built-in networking' 3 - Down with protocol prejudice of all kinds. AppleTalk, TCP/IP, etc. each have their strengths and weaknesses. Perhaps even more importantly, they were designed with different goals and different environments in mind. One size does not fit all. 4 - Open Transport is designed to make it easier to write one application that can use the protocol of choice (AppleTalk, TCP, IPX, etc.) without having to make changes to the program source code to change protocols. It does this by providing a common set of APIs, and by offering a very fast dynamic linking and loading mechanism. An application that is written to the new APIs can then "make up its mind" about the protocol it wants at run time. 5 - Open Transport will offer outstanding backward compatibility for those developers that write to the AppleTalk and MacTCP parameter block APIs, and for those developers who write 'adevs', who write to .enet, .tokn, etc. and who write to the LAPManager. 6 - mdev backward compatibility is still under review. We'd like to figure this out, but there are some hard problems. I have a list of the 'top 10' (like the SLIP and PPP mdevs). But if there are other mdevs out there, it would be helpful if you'd send me an email letting me know about you mdev and your backward compatibility needs and desires.... 7 - As Stephan said, more info is available on Open Trnasport by anonymous ftp to 'seeding.apple.com. - --------------------------------------------------------------------- Garry Hornbuckle Product Manager, Communications & Collaboration - --------------------------------------------------------------------- "If I told you that I | email garryh@seeding.apple.com spoke only for myself | applelink HORNBUCKLE1 would you believe me?" | fax (408) 974-1211 - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From gabe@shiva.com (Gabriel Lawrence) Date: Wed, 22 Jun 94 04:42:11 GMT Organization: Shiva Corporation >>AppleTalk still remains the world's easiest-to-use local area networking >>protocol. No contest. > >Definitely. Until you want to change zones names of course ): I would agree. Unfortunately, the biggest advantage to using AppleTalk (its dynamic configurability) is also it's biggest drawback. The "user friendliness" of AppleTalk prevents it from scaling well. Intelligent routers that "learn" things like zone names are great - until your network becomes very large and you want to change zone names or network numbers. Then you have to go through a tedious process of shutting down routers, restarting seed routers, etc... It's certainly no picnic. Emerging AppleTalk standards like AURP help to alleviate some of these difficulties but they all work by imposing some sort of static network mapping on interconnected networks. That of course means that these are typically not "plug and play" solutions. Oh well. =Gabe= - ---------------------------------------------------------------- Gabriel Lawrence gabe@shiva.com Software Tool Shiva Corporation --------------------------- >From Peter Vanags Subject: CodeWarrior and CODE Resources Date: 23 Jun 1994 01:41:23 GMT Organization: UCB >From reading all the raves about CodeWarrior here, I have no doubt that it's the environment of choice for applications development. But what about stand-alone CODE resource development? Symantec's environment doesn't really give me all of what I need. Their C++ compiler doesn't support virtual functions in CODE resources, which dramatically cripples the object design. I can use C with Object Extensions to get virtual functions, but then I lose lots of desireable C++ features, like templates, constructor arguments, multiple inheritance, passing by reference, and so on. But I do get inline assembler in switching back to C. The A4-based globals in Symantec's environment are a great feature. Does CodeWarrior support A4 globals like Symantec? How about inline (not function-call) assembler in C++? (Very important due to strange calling conventions of some CODE resources.) Custom CODE resource headers? (This would probably require inline assembler.) Virtual functions? The lack of templates in CW is a bummer, since I use a lot of container classes. If CW had all these features, I'd switch in a minute. As I understand it, the only missing thing is the inline assembler. I assume it's because CW supports 68K/PPC development simultaneously. Will some clever CW feature make this possible soon? Would I have to write companion PPC assembler to the 68K stuff, and use pragmas to make sure the right version is compiled to each? Also, how easy is it to compile these hybrid PPC/68K CODE resources in CW? I haven't delved into the PPC code fragment business yet, but to judge from the number of pages written about it in the develop article, it's not simple. What tools does CW provide to aid this process? Peter +++++++++++++++++++++++++++ >From Jens Miltner Date: 24 Jun 1994 23:49:38 GMT Organization: Pole Position Software In article <2uap83$ghe@agate.berkeley.edu> Peter Vanags, peterv@uclink.berkeley.edu writes: >From reading all the raves about CodeWarrior here, I have no doubt that >it's the environment of choice for applications development. But what >about stand-alone CODE resource development? > >Symantec's environment doesn't really give me all of what I need. Their >C++ compiler doesn't support virtual functions in CODE resources, which >dramatically cripples the object design. I can use C with Object >Extensions to get virtual functions, but then I lose lots of desireable >C++ features, like templates, constructor arguments, multiple >inheritance, passing by reference, and so on. But I do get inline >assembler in switching back to C. The A4-based globals in Symantec's >environment are a great feature. I guess the problem with virtual functions in CODE resources is that someone has to set up the virtual jump tables (which is usually done by the initialization code in an app - but there aint no such thing in a code resource...) >Does CodeWarrior support A4 globals like Symantec? How about inline (not >function-call) assembler in C++? (Very important due to strange calling >conventions of some CODE resources.) Custom CODE resource headers? (This >would probably require inline assembler.) Virtual functions? The lack of >templates in CW is a bummer, since I use a lot of container classes. If >CW had all these features, I'd switch in a minute. Yes, they do support A4 globals as well as some sort of inline assembly. The only drawback I found is that the inline assembler only works at function level, i.e. you have to define a complete function as being inline assembler. Also, there is no way to generate CODE resources with a custom header. Each CODE resource will have a standard header (as proposed by Apple, I think). However, this means you can't write things like an RDEV, since they need some different header... >As I understand it, the only missing thing is the inline assembler. I >assume it's because CW supports 68K/PPC development simultaneously. Will >some clever CW feature make this possible soon? Would I have to write >companion PPC assembler to the 68K stuff, and use pragmas to make sure >the right version is compiled to each? Actually, there is little or no need to use assembler with the PowerPC, since for PPC, a C-Interface exists for all known/important functions and callbacks - even for those that used to need assembly routines. >Also, how easy is it to compile these hybrid PPC/68K CODE resources in >CW? I haven't delved into the PPC code fragment business yet, but to >judge from the number of pages written about it in the develop article, >it's not simple. What tools does CW provide to aid this process? What do you mean by 'hybrid CODE resources'? If you talk about e.g. fat binaries, there is no direct support yet. There is however an easy way to build native CODE resources with MW. Calling either CODE res type from either architecture is actually not really difficult. I guess there are samples out there that show how to use MixedMode and the CodeFragmentManager... If you've got it right once, it's peanuts the next time ;-) -- Jens --------------------------- >From y-tony@bu.edu (Yan Lee) Subject: Fast full screen scrolling: impossible? Date: 8 Jun 1994 20:59:27 GMT Organization: Boston University Hello, I have been reading a bit about animation and the Mac. I have read that full screen scrolling is almost impossible to do well on the Mac. I do understand that game machines have chips that specialize in such activities. Howver, is it still not possible for the Mac to do it? Did C64 and PCs have special chips/functions that helped them to do rapid full-screen scrolling? I would like to try to do rapid full-screen scroilling on the Mac , but I am wondering if this ambition is a waste of time. I need opinions please! Tony +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 9 Jun 1994 10:13:06 GMT Organization: The Royal Institute of Technology In <2t5bff$fnp@news.bu.edu> y-tony@bu.edu (Yan Lee) writes: >Hello, > I have been reading a bit about animation and the Mac. I have >read that full screen scrolling is almost impossible to do well on the >Mac. I do understand that game machines have chips that specialize in >such activities. Howver, is it still not possible for the Mac to do it? >Did C64 and PCs have special chips/functions that helped them to do rapid >full-screen scrolling? I would like to try to do rapid full-screen No; the PC instead has an "inferior" video mode with large pixels which makes the amount of data to move smaller. The smallest Mac color screen is 512x384 pixels, and most are 640x480 or larger (13" or more) The PC screens are 320x200 pixels, so you have only 1/4 as many pixels to move. On the other hand, Mac graphics are much less blocky. On the PowerPC, scrolling 640x400 or so is quite doable; put interesting borders around it if you want even better FPS (smaller area) Cheers, / h+ Jon W{tte -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- I offer a pot of gold for Gates' head on a pole. Naah - bashing Microsoft is "out." Love, Peace and Understanding! +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) Date: Thu, 9 Jun 1994 12:33:48 GMT Organization: DCRT, NIH, Bethesda, MD In article <2t5bff$fnp@news.bu.edu>, y-tony@bu.edu (Yan Lee) writes: > > I have been reading a bit about animation and the Mac. I have >read that full screen scrolling is almost impossible to do well on the >Mac. I do understand that game machines have chips that specialize in >such activities. Howver, is it still not possible for the Mac to do it? >Did C64 and PCs have special chips/functions that helped them to do rapid >full-screen scrolling? I would like to try to do rapid full-screen >scroilling on the Mac , but I am wondering if this ambition is a waste of >time. I need opinions please! The Commodore 64 had special hardware that allowed the programmer to shift the screen, either horizontally or vertically or both (independantly), in one-pixel increments, up to a delta of 8 pixels from 'normal.' In combination with 32x32 hardware sprites and funky text-based graphics modes, this made relatively advanced graphics quite feasible even on the old CBM 6510 chip that it used. PC graphics cheat. :-) They use a low resolution graphics mode. DOOM, for example (the premier animated DOS game at present), draws the screen at 320x200 pixels. Note that the smallest Macintosh screen is 512x342, which is more than twice as many pixels as 320x200. A 640x400 screen is four times as many, and the (fairly standard) 640x480 screen is even more than that. PowerMacs have the horsepower to scroll large portions of the screen at once. - -------------------------------------------------------------------------- Christopher Tate | "There are 0 grams of fat in Mountain Dew. MSD, Inc. | That means it's good for you, right?" fixer@faxcsl.dcrt.nih.gov | - Mike Wellman, in c.s.m.p +++++++++++++++++++++++++++ >From y-tony@bu.edu (Yan Lee) Date: 9 Jun 1994 14:59:00 GMT Organization: Boston University Chris Gonna' Find Ray Charles Tate (fixer@faxcsl.dcrt.nih.gov) wrote: : In article <2t5bff$fnp@news.bu.edu>, y-tony@bu.edu (Yan Lee) writes: : > : The Commodore 64 had special hardware that allowed the programmer to : shift the screen, either horizontally or vertically or both (independantly), : in one-pixel increments, up to a delta of 8 pixels from 'normal.' In : combination with 32x32 hardware sprites and funky text-based graphics : modes, this made relatively advanced graphics quite feasible even on : the old CBM 6510 chip that it used. Oh yeah, I remember the shifting-screen stuff. I used to do that to make the whole screen shake for earthquake effects :) : PC graphics cheat. :-) They use a low resolution graphics mode. DOOM, : for example (the premier animated DOS game at present), draws the screen : at 320x200 pixels. Note that the smallest Macintosh screen is 512x342, : which is more than twice as many pixels as 320x200. A 640x400 screen : is four times as many, and the (fairly standard) 640x480 screen is even : more than that. Is there a source code for the Mac for lowres modes? It must be possible since Pathways into darkness has that mode to double the speed. : PowerMacs have the horsepower to scroll large portions of the screen : at once. Unfortunately I have no access or money for a PPC even though it is reasonably price. Maybe next year.... : ---------------------------------------------------------------------------- : Christopher Tate | "There are 0 grams of fat in Mountain Dew. : MSD, Inc. | That means it's good for you, right?" : fixer@faxcsl.dcrt.nih.gov | - Mike Wellman, in c.s.m.p Thanks for all the responses. +++++++++++++++++++++++++++ >From bericksn@ac.dal.ca Date: 9 Jun 94 14:47:34 -0300 Organization: Dalhousie University, Halifax, Nova Scotia, Canada In article <2t5bff$fnp@news.bu.edu>, y-tony@bu.edu (Yan Lee) writes: > Hello, > > I have been reading a bit about animation and the Mac. I have > read that full screen scrolling is almost impossible to do well on the > Mac. I do understand that game machines have chips that specialize in > such activities. Howver, is it still not possible for the Mac to do it? > Did C64 and PCs have special chips/functions that helped them to do rapid > full-screen scrolling? I would like to try to do rapid full-screen > scroilling on the Mac , but I am wondering if this ambition is a waste of > time. I need opinions please! > Machines like the C64 have hardware assistance, and PCs have a 320x200 graphics mode & page flipping. It's still possible on the Mac, though--check out the demo for Deliverance. The technique the programmer uses seems to be to render frames at 320x200 and then blow them up. It still looks pretty good, it was very playable at 640x400x16 on my LC 475. You'd have to do a lot of assembly optimization to get such performance, I'd bet. Sean +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 10 Jun 94 16:30:59 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2t6pvi$oie@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) writes: > In <2t5bff$fnp@news.bu.edu> y-tony@bu.edu (Yan Lee) writes: > >> I have been reading a bit about animation and the Mac. I have >>read that full screen scrolling is almost impossible to do well on the >>Mac. I do understand that game machines have chips that specialize in >>such activities. Howver, is it still not possible for the Mac to do it? >>Did C64 and PCs have special chips/functions that helped them to do rapid >>full-screen scrolling? > > No; the PC instead has an "inferior" video mode with large pixels > which makes the amount of data to move smaller. The smallest Mac color > screen is 512x384 pixels, and most are 640x480 or larger (13" or more) > The PC screens are 320x200 pixels, so you have only 1/4 as many pixels > to move. On the other hand, Mac graphics are much less blocky. Here's a thought: some Macs have a hardware pixel-doubling feature built into their on-board video (I think the IIvi and IIvx have it). This was introduced for use with QuickTime, but as I recall the driver calls are documented in some QuickTime release notes somewhere, so you could use it for other purposes... 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+12:00 +++++++++++++++++++++++++++ >From mgr@aggroup.aggroup.com (Mike Russell) Date: Fri, 10 Jun 1994 12:43:32 -0800 Organization: the ag group, inc. Live scrolling, where the text moves immediately instead after the thumb is released, is no problem on Mac or PC. Processor speed has more than kept up with increases in display depth and resolution. Several years ago live scrolling was considered not Mac-like. Now it seems to be accepted. +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 11 Jun 1994 07:50:43 GMT Organization: (none) y-tony@bu.edu (Yan Lee) writes: > I have been reading a bit about animation and the Mac. I have >read that full screen scrolling is almost impossible to do well on the >Mac. I do understand that game machines have chips that specialize in >such activities. Howver, is it still not possible for the Mac to do it? I'm afraid it is impossible, except perhaps on some video boards. In general, you must do it by rewriting the entire screen every frame. CopyBitsing the entire screen won't be fast enough, and writing a custom blitter doesn't help much, if at all. The options you have are: - Make it possible to step down to fewer bits per pixel. Running in 16 colors instead of 256 means twice the speed. Actually, it is possible to make decent scrolling in 16 colors in a 512*340 area on a slow LC. In b/w, it's 8 times faster! - Make your graphics in a way that makes it possible to update only some parts of the screen for each frame. That means big smooth areas. Sky Shadow used that trick (but still didn't get quite the frame rate we had ideally wanted), and so did OIDS. - Run in a rather small area. This is what Bolo does. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Sat, 11 Jun 1994 10:50:42 GMT Organization: Best Before Yesterday In article , mgr@aggroup.aggroup.com (Mike Russell) wrote: > Live scrolling, where the text moves immediately instead after the thumb > is released, is no problem on Mac or PC. Processor speed has more > than kept up with increases in display depth and resolution. > > Several years ago live scrolling was considered not Mac-like. Now it > seems to be accepted. I missed the original post, but if it's about full screen scrolling at 30fps, that's still pretty much impossible. There are several solutions people have used, such as the draw-every-other-line approach in Deliverance to improve speed on slower Macs. Also, QuickTime 2 does it, though that doesn't count (I think it doesn't really redraw all the screen all the time). Someone sent me a test result from a PowerMac: straight blitting a 640x480 image to the screen and doing nothing else, the frame rate was only about 25fps. Games would also do lots of drawing offscreen. Alex -- Alex Metcalf, Best Before Yesterday Mac programmer in C, C++, HyperTalk, assembler Juggler, 3-ball tricks Internet: alex@metcalf.demon.co.uk Fax (UK): (0570) 45636 Fax (US / Canada): 011 44 570 45636 +++++++++++++++++++++++++++ >From misc173@csc.canterbury.ac.nz Date: 13 Jun 94 10:33:49 +1200 Organization: University of Canterbury, Christchurch, New Zealand > I missed the original post, but if it's about full screen scrolling at > 30fps, that's still pretty much impossible. There are several solutions > people have used, such as the draw-every-other-line approach in Deliverance > to improve speed on slower Macs. Also, QuickTime 2 does it, though that > doesn't count (I think it doesn't really redraw all the screen all the > time). > > Someone sent me a test result from a PowerMac: straight blitting a 640x480 > image to the screen and doing nothing else, the frame rate was only about > 25fps. Games would also do lots of drawing offscreen I couldn't believe this post when I read it yesterday, so I went home and wrote a 640x480x8bit RAM scroller, it starts at 0 and scrolls up through RAM, copying it to the screen, one line per frame. It got 40 fps on my 605, and I know that it could be optimised more, unrolling the inner loop, etc. I tried a variety of resolutions and interpolation techniques and gained some interesting insights. If you reduce the screen size the speed increases proportionaly, 320x240x8bit at 150fps. Using alternate lines doubles the speed again ( and looks fairly good against black ), pixel doubling is very slow, I havent tried using movep yet, but it should speed things up ( if it works ). This routine uses only move.l, as I intend to program for 040's I will try move16, which should speed things up about 3x. The final conclusion is that whoever wrote that ppc blitter ain't very good, I know enough assembly to this, and other simple graphics routines, but it still goes reasonably fast ( at least 10% faster than copybits ). Full screen scrolling is possible, and if someone asks for it I'll even post my code. Jon. +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Mon, 13 Jun 1994 00:13:44 GMT Organization: The World Public Access UNIX, Brookline, MA ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >> No; the PC instead has an "inferior" video mode with large pixels >> which makes the amount of data to move smaller. The smallest Mac color >> screen is 512x384 pixels, and most are 640x480 or larger (13" or more) >> The PC screens are 320x200 pixels, so you have only 1/4 as many pixels >> to move. On the other hand, Mac graphics are much less blocky. >Here's a thought: some Macs have a hardware pixel-doubling feature built into >their on-board video (I think the IIvi and IIvx have it). This was introduced >for use with QuickTime, but as I recall the driver calls are documented in >some QuickTime release notes somewhere, so you could use it for other >purposes... Yeah, this feature is available - it's not, however, widely available enough to be of any use to anyone writing games. It is *definitely* in the LC II and the Color Classic (I think you're right about the vi/vx, but not altogether sure). It actually went in at first *only* because it was needed by the Apple IIe card and was undocumented (ie twiddle this memory mapped register) until QT 1.5, where video driver calls for them were defined, as well as the GDHasScale/GetScale/SetScale calls. Oh, at least in the LC II it only works in 16bpp mode, which is another problem (since the flimsy VRAM capacity allows 16bpp only with the 12-inch monitor, which most people don't have anyway). So although the feature is there in theory, it is useless for practical purposes for games. Plus the fact that the 16bpp restriction means that at quarter screen zoom you're blasting the same amount of memory as if you were doing half-screen "letterboxed" at the non-hw-zoom resolution. Plus the fact that the LC II has the crippled 16-bit-wide data bus to the CPU, adding to the problem. Plus ... nah, I could go on ... I'd explore instead the trick the MacPlay people mentioned at the WWDC that is used in AstroChase 3D: interlaced animation, which allows you to blast every other line in a given animation frame, cutting your blitting bandwith needs by half... -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 12 Jun 94 18:28:03 MST Organization: (none) In article <1994Jun13.103349.1@csc.canterbury.ac.nz>, misc173@csc.canterbury.ac.nz writes: > >> I missed the original post, but if it's about full screen scrolling at >> 30fps, that's still pretty much impossible. There are several solutions >> people have used, such as the draw-every-other-line approach in Deliverance >> to improve speed on slower Macs. Also, QuickTime 2 does it, though that >> doesn't count (I think it doesn't really redraw all the screen all the >> time). >> >> Someone sent me a test result from a PowerMac: straight blitting a 640x480 >> image to the screen and doing nothing else, the frame rate was only about >> 25fps. Games would also do lots of drawing offscreen > > I couldn't believe this post when I read it yesterday, so I went home > and wrote a 640x480x8bit RAM scroller, it starts at 0 and scrolls up through > RAM, copying it to the screen, one line per frame. It got 40 fps on my 605, and > I know that it could be optimised more, unrolling the inner loop, etc. I tried > a variety of resolutions and interpolation techniques and gained some > interesting insights. If you reduce the screen size the speed increases > proportionaly, 320x240x8bit at 150fps. Using alternate lines doubles the speed > again ( and looks fairly good against black ), pixel doubling is very slow, I > havent tried using movep yet, but it should speed things up ( if it works ). > This routine uses only move.l, as I intend to program for 040's I will > try move16, which should speed things up about 3x. > The final conclusion is that whoever wrote that ppc blitter ain't very > good, I know enough assembly to this, and other simple graphics routines, but > it still goes reasonably fast ( at least 10% faster than copybits ). Full > screen scrolling is possible, and if someone asks for it I'll even post my > code. > > Jon. > d e v e l o p 18 claims that the PPC blitter that they used was slower than CopyBits because it didn't (presumably, for some unknown reason, *couldn't*) take advantage of the 64-bit path of video. For this same reason, *BlockMove* was also slower. What is going on with the memory subsystem in the PowerMacs? Is it or isn't it 64-bit? Is the DRAM video 64-bit? Is the AV video? Is the non-AV PDS video? What is the actual and theoretical maximum speeds of a customized full-screen (ala Doom/PID game) blitter from RAM into any of the three standard videos at 8, 16 and 32-bit? (I'm aware that DRAM video can't do 32-bit -leave that entry blank). For that matter, why can't BlockMove move data in 64-bit chunks when it is most optimal to do so? And finally, what happened to the load/store multiple instructions that are (I assume?) faster on the 601, but will probably be slower "in future implementations?" I assume that all the boundry conditions to make these the most efficient way to move memory in the 601 are met by the various video options? Certainly, one can guarantee that a buffer can meet them by insuring that the beginning address referenced starts on a 4-K boundry? Is CopyBIts supposed to be faster than using a sequence of load/store multiple instructions on the 601? (the article in d e v e l o p already suggested that one should test for maximum speed anyways, so what harm to optimize for the 601?) Lawson +++++++++++++++++++++++++++ >From seanmcd@ac.dal.ca Date: 12 Jun 94 23:22:57 -0300 Organization: Dalhousie University, Halifax, Nova Scotia, Canada In article , ivanski@world.std.com (Ivan M CaveroBelaunde) writes: > > I'd explore instead the trick the MacPlay people mentioned at the WWDC > that is used in AstroChase 3D: interlaced animation, which allows you > to blast every other line in a given animation frame, cutting your > blitting bandwith needs by half... > I think Chuck Yeager's Air Combat does this too. You can see interlacing in the terrain if you rock the plane back and forth. Sean +++++++++++++++++++++++++++ >From Cameron Esfahani Date: Mon, 13 Jun 1994 05:47:46 GMT Organization: Apple Computer, Inc. In article Anton Rang, rang@winternet.com writes: > Unless you're using the floating-point registers, you can't use the > full 64-bit path efficiently, because there's no 64-bit integer load. > I haven't looked at NQDCopyBits to see if it uses the FP registers; I > suppose that it *could*, in cases where there is no scaling, shifting, > etc. but it seems unlikely that it would. It does... Cameron Esfahani dirty@apple.com +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 13 Jun 1994 06:44:15 GMT Organization: The Royal Institute of Technology In <1994Jun13.103349.1@csc.canterbury.ac.nz> misc173@csc.canterbury.ac.nz writes: >again ( and looks fairly good against black ), pixel doubling is very slow, I Pixel doubling is not slow; remember; you only have to read one quarter as much memory. A co-worker of mine blits 320x200 into 640x400, using C, in 21 milliseconds for a 48 fps frame rate. Using the interesting bit-splice instructions in the 601, you'd probably get even better frame rates; no current Mac C compiler knows those instructions :-) -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "Don't stick a Fork in your Eye." +++++++++++++++++++++++++++ >From stay@park.uvsc.edu (Steve Taylor) Date: Mon, 13 Jun 1994 16:17:47 GMT Organization: Utah Valley State College, Orem, Utah >From article <1994Jun12.232257.24853@dal1>, by seanmcd@ac.dal.ca: > In article , ivanski@world.std.com (Ivan M CaveroBelaunde) writes: >> >> I'd explore instead the trick the MacPlay people mentioned at the WWDC >> that is used in AstroChase 3D: interlaced animation, which allows you >> to blast every other line in a given animation frame, cutting your >> blitting bandwith needs by half... >> > I think Chuck Yeager's Air Combat does this too. You can see interlacing > in the terrain if you rock the plane back and forth. > > Sean Could someone describe this technique in more detail? Are you talking about leaving the other lines there and blitting the other half or are you talking about doubling the height of the lines or what? Thanks. -- -- Steve Taylor (stay@wahoo.com or stay@park.uvsc.edu) -- -- Life is the Dress Rehearsal for Hell. -- +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Mon, 13 Jun 1994 14:05:46 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA y-tony@bu.edu (Yan Lee) writes: > Is there a source code for the Mac for lowres modes? It must be > possible since Pathways into darkness has that mode to double the speed. Pathways does this in software. It renders offscreen at half resolution, and then doubles the pixels in software before putting them on the screen. Amanda Walker InterCon Systems Corporation +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 13 Jun 1994 13:22:29 -0700 Organization: SRI International, Menlo Park, CA In article <1994Jun13.103349.1@csc.canterbury.ac.nz> misc173@csc.canterbury.ac.nz writes: > The final conclusion is that whoever wrote that ppc blitter ain't very >good, I know enough assembly to this, and other simple graphics routines, but >it still goes reasonably fast ( at least 10% faster than copybits ). Full >screen scrolling is possible, and if someone asks for it I'll even post my >code. Well, post your code then. I'll run it on my 8100 and see how fast your hand tuned assember is running emulated. If you have the c code, I can recompile it and see if it faster than CopyBits. Here's a clue use a fp register. Anyway, I'm tweeking the PPC blitter code to try an experiment using the dirty rectangle approach for animation using the PPC blitter to blit a fixed sized rect to the screen when that rect becomes dirty. The question is when drawing in the gWorld, whats a fast way to flag that a rect has become dirty? Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 13 Jun 1994 15:00:37 -0700 Organization: SRI International, Menlo Park, CA In article stay@park.uvsc.edu (Steve Taylor) writes: >Could someone describe this technique in more detail? Are you talking >about leaving the other lines there and blitting the other half or >are you talking about doubling the height of the lines or what? >Thanks. In astroChase 3d (or whatever its called) they paint only every other line in the screen display. This speeds up the drawing by not having to write half the data and makes it look like your viewing the action from a tv monitor. I'm assuming that other game is writing first the odd lines in one pass and then the even lines in another pass. These are clever way to reduce the amount of data that needs to be written. As programmers we try to come of with these workaround because of the basic limitation that the Mac can't paint the screen fast enough. Plain and Simple. The goal is to write as little data to the screen as possible so that we can concentrate on the rest of the game. If you thought about it hard enough you probaly could come up with a way to paint the whole screen but then it wouldn't be much of a game. Also, there seems to be a magic equation that we strive for that can write the most pixels in the least amount of time. So to gain any speed we need top find out what pixels not to draw. If on the PPC we can write a 64 bit word to memory, in 256 colors that's 8 pixels in a row. So if we were going to write one pixel we might as well write 8. So its a balance of testing to see what needs to be drawn and just blindy drawing. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 13 Jun 1994 16:58:42 -0700 Organization: SRI International, Menlo Park, CA In article <2tif65$s62@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes: >Anyway, I'm tweeking the PPC blitter code to try an experiment using the >dirty rectangle approach for animation using the PPC blitter to blit >a fixed sized rect to the screen when that rect becomes dirty. The question >is when drawing in the gWorld, whats a fast way to flag that a rect has become >dirty? Doing some quick test on a 8100/80av in 256 color mode, using the PPC blitter in develop, it can blit approximatly 2383 8x8 rects in one tick. If you want 30fps you can probably double the number of rects. This still won't let you do scrolling backgrounds unless your real clever in designing your backgrounds. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From misc173@csc.canterbury.ac.nz Date: 14 Jun 94 13:24:59 +1200 Organization: University of Canterbury, Christchurch, New Zealand > Pixel doubling is not slow; remember; you only have to read one > quarter as much memory. A co-worker of mine blits 320x200 into > 640x400, using C, in 21 milliseconds for a 48 fps frame rate. > Using the interesting bit-splice instructions in the 601, you'd > probably get even better frame rates; no current Mac C compiler > knows those instructions :-). What cpu is this on, possibly an 840av, if you look at the timings involved you will see that doubling 320x240 to 640x480 cannot go as fast as just moving 640x480 Moving: Move.l (a0)+, (a1)+ Move.l (a0)+, (a1)+ moves 8 pixels from Ptr a0 to Ptr a1. Assuming a 68000 this takes 24 clock cycles ( I dont have timing for anything else ). Expanding: Move.l (a0)+, d0 ;expand the pixels into another register Move.l d1, (a1)+ Move.l d2, (a1)+ this uses three reg->mem operations, 8 clkcs each, 24 total. The time required to shift the data is just as much, and it doesn't include any code to double the pixels. So why use pixel doubling? Because when you're creating the offscreen image you only have to do a quater the work. This is the only benefit, and it will not outway the slowdown of the blit all the time, each case has to be determined individually. Personally I'm interested in the hardware expander in some Macs, much more potential than software. For those who asked for my blitter, I'll turn it into a procedure that takes arguements and checks rowbytes and post it when I get my modem in a couple of days. Jon. as just shifting 640x480. +++++++++++++++++++++++++++ >From seanmcd@ac.dal.ca Date: 13 Jun 94 21:29:36 -0300 Organization: Dalhousie University, Halifax, Nova Scotia, Canada In article , stay@park.uvsc.edu (Steve Taylor) writes: > From article <1994Jun12.232257.24853@dal1>, by seanmcd@ac.dal.ca: >> In article , ivanski@world.std.com (Ivan M CaveroBelaunde) writes: >>> >>> I'd explore instead the trick the MacPlay people mentioned at the WWDC >>> that is used in AstroChase 3D: interlaced animation, which allows you >>> to blast every other line in a given animation frame, cutting your >>> blitting bandwith needs by half... >>> >> I think Chuck Yeager's Air Combat does this too. You can see interlacing >> in the terrain if you rock the plane back and forth. >> >> Sean > > Could someone describe this technique in more detail? Are you talking > about leaving the other lines there and blitting the other half or > are you talking about doubling the height of the lines or what? > Thanks. > Well the description given above makes AstroChase 3D sound like CYAC, although the only thing I've seen in AstroChase 3D is the venetian blind style, rendering the frame onto every other line. Deliverance also has the option to do this, as does a game called Gate. It looks to me like CYAC does interlacing, i.e., there are no black lines alternating with the graphics, but if you rock the plane or turn rapidly, you can see the interlacing effect fairly easy in large polygons. I don't know enough about 3D graphics to know whether you could actually render even/odd scanlines or whether he's just splitting an off-screen drawing into two blits. Sean +++++++++++++++++++++++++++ >From misc173@csc.canterbury.ac.nz Date: 14 Jun 94 23:05:14 +1200 Organization: University of Canterbury, Christchurch, New Zealand > Well, post your code then. I'll run it on my 8100 and see how fast your > hand tuned assember is running emulated. If you have the c code, I can > recompile it and see if it faster than CopyBits. > Here's a clue use a fp register. > Anyway, I'm tweeking the PPC blitter code to try an experiment using the > dirty rectangle approach for animation using the PPC blitter to blit > a fixed sized rect to the screen when that rect becomes dirty. The question > is when drawing in the gWorld, whats a fast way to flag that a rect has become > dirty? Yea, I'll post it soon, please note that I dont think I know enough assembly to optimise it very well, I'll put unrolling notes in it to keep the size down, I dont want to pay for 160 move.l 's. I dont know what you're doing, but with respect to a game I'd keep a list of currently valid rectangles and if the movement routine does stuff set a flag in the list to true, you could add some code to combine the updated rectangles into one ( in non-sprite situations ), or even just asume that all sprites are moving. The code will be here soon, at the moment I'm netting off a Vax, with my modem, yes I have it, I'll be able to post much more easily. Jon. +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 14 Jun 1994 13:04:10 GMT Organization: The Royal Institute of Technology In <1994Jun14.132459.1@csc.canterbury.ac.nz> misc173@csc.canterbury.ac.nz writes: >> Pixel doubling is not slow; remember; you only have to read one >> quarter as much memory. A co-worker of mine blits 320x200 into >> 640x400, using C, in 21 milliseconds for a 48 fps frame rate. > What cpu is this on, possibly an 840av, if you look at the timings >involved you will see that doubling 320x240 to 640x480 cannot go as fast >as just moving 640x480 This was a 6100/60. .... > this uses three reg->mem operations, 8 clkcs each, 24 total. The time > required to shift the data is just as much, and it doesn't include any > code to double the pixels. > So why use pixel doubling? Because when you're creating the offscreen >image you only have to do a quater the work. This is the only benefit, and it You can't just count clocks out of the book; overlapping reads/writes, caches, writeback, stalls, etc etc etc all have their effect. And doubling doesn't just mean doubling on an X axis; you double on the Y axis as well to achieve square 2x2 pixels. As long as pixel doubling N pixels in registers is faster than N*3 read cycles in memory, you'll gain blitting speed from the doubling as well as having much less to render. In a world of slow DRAM and fast CPUs (PowerPC) this is really important. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- Not speaking for the Liberian Government. +++++++++++++++++++++++++++ >From glalonde@vnet.ibm.com (Glen Lalonde) Date: 14 Jun 1994 13:05:07 GMT Organization: IBM Toronto Lab. In a program I am working on(at home) I managed to double the frame rate by using custom routines to draw into a off screen gworld. Using quickdraw was just too slow. My routines just moves bytes. After this is done, copybits is used to move the image to the users screen. Even with everything aligned correctly and color tables(& index) matching, copybits still takes way to long. I think having a 'use only quickdraw' option will be added which will allow me to use a custom copybits unless the user asked me not to. I can't post exact frame rates since when the program runs(in none test mode) only the part of the screen which has changed gets copybits to the users screen. Any comments one what is the 'minimum' frame rate needed so that the action looks reasonably smooth? Glen. +++++++++++++++++++++++++++ >From enry@dcs.qmw.ac.uk (Henry) Date: 14 Jun 1994 16:42:39 GMT Organization: Queen Mary & Westfield College, London, UK Shuffling bytes about in memory just puts a huge burden on the processor when it should be calculating something far less menial. Why can I not change the video hardware's screen base pointer, and fill in the newly exposed part of the screen. This eliminates as much bit copying as we like (give enough vram set asside)... It also has the added advantage of having an offscreen pixmap, and being able to display it instantly without blasting bytes through the proccessor, allowing sencible (fast) screen buffering. Is it possible to reliably direct the macs hardware to a different screen buffer? (You can do it on a Mac512k :-) If not, can I do it unreliably? If not, you are all destined to fester in the mouldy crevis of a mac games industry that has about as much chance of producing a decent game, as a cheese sandwich has of sneaking its way past the doorman at the Hilton. Morgan, -- Did I say I was a sardine? Or a bus? +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 15 Jun 1994 03:01:36 +1200 (NZST) Organization: (none) mxmora@unix.sri.com (Matt Mora) writes: > Anyway, I'm tweeking the PPC blitter code to try an experiment using the > dirty rectangle approach for animation using the PPC blitter to blit > a fixed sized rect to the screen when that rect becomes dirty. The question > is when drawing in the gWorld, whats a fast way to flag that a rect has become > dirty? An approach I've used: keep an array with one element per scanline. Each element consists of two integers: the first dirty pixel in the line, and the last dirty pixel in the line. Unless there's some particular reason for always blitting a rect, I'd just blit a scanline at a time, however much is needed. When blitting the line, round the start down and the end up to the nearest transfer unit. -- Bruce +++++++++++++++++++++++++++ >From larsg@edb.tih.no (Lars Garden) Date: 14 Jun 1994 18:03:14 GMT Organization: Trondheim College of Engineering Jon Wätte (d88-jwa@dront.nada.kth.se) wrote: : In <2t5bff$fnp@news.bu.edu> y-tony@bu.edu (Yan Lee) writes: : >Hello, : > I have been reading a bit about animation and the Mac. I have : >read that full screen scrolling is almost impossible to do well on the : >Mac. I do understand that game machines have chips that specialize in : >such activities. Howver, is it still not possible for the Mac to do it? : >Did C64 and PCs have special chips/functions that helped them to do rapid : >full-screen scrolling? I would like to try to do rapid full-screen : No; the PC instead has an "inferior" video mode with large pixels : which makes the amount of data to move smaller. "Inferior" video modes are quite useful when you want to sacrifice resolution for speed. Is the Mac really not capable of using video modes with a resolution less than 512x384? -- // Lars Gaarden. Student at Trondheim College of Engineering. \\ // email: larsg@edb.tih.no IRC: Lynet \X/ "But I will rise and I will return like a phoenix from the flame." - Sinéad O'Conner +++++++++++++++++++++++++++ >From julian@cs.aukuni.ac.nz (Julian Ross Harris) Date: 14 Jun 1994 23:37:59 GMT Organization: University of Auckland ingemar@lysator.liu.se (Ingemar Ragnemalm) writes: >The options you have are: >- Make it possible to step down to fewer bits per pixel. Running in 16 >colors instead of 256 means twice the speed. Actually, it is possible to >make decent scrolling in 16 colors in a 512*340 area on a slow LC. In >b/w, it's 8 times faster! >- Run in a rather small area. This is what Bolo does. Yes, I know it's hardly relevant these days, but i wrote this game on the Mac Plus that used offscreen bitmaps and fullscreen scrolling. The trick was to scroll in 32 pixel increments (Ultima-type game). Then full screen scrolling was instantaneous. Trouble is, 8 bit is 8x slower, and smooth means minimum of 2 pixels at a time, which is a whole lot harder without hardware assistance. -- Julian, Programmer, Comp. Sci, Univ. Auckland, julian@cs.auckland.ac.nz +++++++++++++++++++++++++++ >From dwareing@apanix.apana.org.au (David Wareing) Date: 14 Jun 94 15:21:50 GMT Organization: Apanix Public Access Unix, +61 8 373 5485 (5 lines) seanmcd@ac.dal.ca writes: >In article , ivanski@world.std.com (Ivan M CaveroBelaunde) writes: >> >> I'd explore instead the trick the MacPlay people mentioned at the WWDC >> that is used in AstroChase 3D: interlaced animation, which allows you >> to blast every other line in a given animation frame, cutting your >> blitting bandwith needs by half... >> >I think Chuck Yeager's Air Combat does this too. You can see interlacing >in the terrain if you rock the plane back and forth. And of course there's always Deliverance. That demo still surprises me every time I check it out. Just not used to scrolling graphics on the mac I guess. -- David Wareing Adelaide, South Australia dwareing@apanix.apana.org.au - ------------------------------------------------------------ Overflight Software - Macintosh Games & Multimedia Programming +++++++++++++++++++++++++++ >From Malicious_Monarch@nile.com (Malicious Monarch) Date: Tue, 14 Jun 94 14:54:56 MDT Organization: The Nile BBS <<"Inferior" video modes are quite useful when you want to sacrifice resolution for speed.>> That's true, but I don't know many people who would like to take a game with pixelated graphics over one that has very precise -shall I say 'crisp'? :) - graphics. There's always more than one way to make a game... -Eric A. Drumbor- Opinions posted are of the user, not the administration. +++++++++++++++++++++++++++ >From Malicious_Monarch@nile.com (Malicious Monarch) Date: Tue, 14 Jun 94 14:58:44 MDT Organization: The Nile BBS <> Haha ;) Nice. But since when does a minor limitation make a computer completely inferior for decent games? Come come, let's be a little more optimistic... -Eric A. Drumbor- Opinions posted are of the user, not the administration. +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 15 Jun 1994 11:51:39 GMT Organization: The Royal Institute of Technology In <2tkmlv$602@beta.qmw.ac.uk> enry@dcs.qmw.ac.uk (Henry) writes: >Why can I not change the video hardware's screen base pointer, and fill in the >newly exposed part of the screen. This eliminates as much bit copying as we >like (give enough vram set asside)... 1) because then you'd have locked yourself into a specific screen hardware setup. A MacPlus is different from a Toby Framebuffer is different from a THinder/24 is different from a 8100/AV. >Is it possible to reliably direct the macs hardware to a different >screen buffer? Only if you want to special-case for dozens of video cards. Not to mention that half of them don't have enough extra RAM to put any extra pixels in. >If not, you are all destined to fester in the mouldy crevis of a mac games >industry that has about as much chance of producing a decent game, as a >cheese sandwich has of sneaking its way past the doorman at the Hilton. Well, the PowerPC does some pretty decent frame rates. And I think Prince of Persia was a decent game, and SimCity 2000 still is. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "Practice random kindness, and senseless acts of beauty." +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 15 Jun 1994 11:53:11 GMT Organization: The Royal Institute of Technology In <2tkrd2$nk3@astfgl.edb.tih.no> larsg@edb.tih.no (Lars Garden) writes: >"Inferior" video modes are quite useful when you want to sacrifice >resolution for speed. Is the Mac really not capable of using video modes >with a resolution less than 512x384? Worse. Most screen cards stop at 640x480; the 512x384 mode is only for the Mac LC 12" color monitor and the Color Classic 10" built-in color, none of which sold well. A Mac has square pixels at 72 dpi, and that's it! Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "Practice random kindness, and senseless acts of beauty." +++++++++++++++++++++++++++ >From mikec@mv.mv.com (Mike Callaghan) Date: Wed, 15 Jun 1994 12:32:19 GMT Organization: MV Communications, Inc. In article <2t5bff$fnp@news.bu.edu>, y-tony@bu.edu (Yan Lee) writes: > I have been reading a bit about animation and the Mac. I have >read that full screen scrolling is almost impossible to do well on the >Mac. I do understand that game machines have chips that specialize in >such activities. Howver, is it still not possible for the Mac to do it? What about programs like Stepping Out? It did great full-screen scrolling relatively quickly even on a Mac Plus. I realize that doing this in a window is a completely different story, but how did Stepping Out accomplish it? Is it possible to set up a giant bitmap (or pixmap) and simply alter the address where the Mac thinks its screen is? MikeC -- Michael D. Callaghan Nashua, New Hampshire - -------------------------------------------------------------------- RULE: "(sqrt(-1)) before (2.71828), except after (186,000 miles/sec)." [THE DANGERS OF MIXING GRAMMAR AND SCIENCE] +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Wed, 15 Jun 1994 15:42:51 GMT Organization: The World Public Access UNIX, Brookline, MA Malicious_Monarch@nile.com (Malicious Monarch) writes: ><<"Inferior" video modes are quite useful when you want to sacrifice resolution >for speed.>> > That's true, but I don't know many people who would like to take a game with >pixelated graphics over one that has very precise -shall I say 'crisp'? :) - >graphics. There's always more than one way to make a game... I would. In a second. While it might be feasible to do a full-screen textured map game a la DOOM/PID with good performance on a PowerMac, it's not on a 25MHz 030 at 640x480. The higher performance machines you require in order to deliver acceptable playability, the more you shrink your potential market and the harder it is to justify the effort of developing a game like that. Sometimes crispness is more important than fps, and viceversa (there are different tradeoffs with different performance levels, different kind of games, etc). The sole *availability* of an "inferior" video mode would allow the game designer the choice of sacrificing one for the other - a choice we don't have right now. -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Wed, 15 Jun 1994 16:11:31 GMT Organization: Apple Computer, Inc. In article <2tmq0b$t70@news.kth.se> Jon W!tte, d88-jwa@mumrik.nada.kth.se writes: >>In <2tkmlv$602@beta.qmw.ac.uk> enry@dcs.qmw.ac.uk (Henry) writes: >>If not, you are all destined to fester in the mouldy crevis of a mac games >>industry that has about as much chance of producing a decent game, as a >>cheese sandwich has of sneaking its way past the doorman at the Hilton. Hmm. I ordered a grilled cheese sandwich from room service once. ... but seriously In many cases you simply cannot change the video base address because of limitations and/or differences in the video hardware. However, there is absolutely nothing wrong with slamming bits into the frame buffer directly. -Dave Falkenburg -Apple Computer, Inc. +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 15 Jun 94 16:55:18 GMT Organization: SRI International, Menlo Park, CA In article mikec@mv.mv.com (Mike Callaghan) writes: >What about programs like Stepping Out? It did great full-screen scrolling >relatively quickly even on a Mac Plus. I realize that doing this in a >window is a completely different story, but how did Stepping Out accomplish >it? Is it possible to set up a giant bitmap (or pixmap) and simply alter >the address where the Mac thinks its screen is? Stepping out only had 22k of data to blit to worry about. Color Macs have about 300k of data to blit. Big difference. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mkelly@cs.uoregon.edu (Michael A. Kelly) Date: 15 Jun 1994 10:42:31 -0700 Organization: High Risk Ventures In article <2tmq0b$t70@news.kth.se>, Jon Wätte wrote: > >>Is it possible to reliably direct the macs hardware to a different >>screen buffer? > >Only if you want to special-case for dozens of video cards. What? I was under the impression that it can't be done in any case (except for some of the classic Macs of course) because the pointer to the video buffer is in hardware. So you're saying it's possible to do page-flipping on a Mac? How do you swap the pointer? It sounds like you're also saying that the second page has to be in video memory, right? >>If not, you are all destined to fester in the mouldy crevis of a mac games >>industry that has about as much chance of producing a decent game, as a >>cheese sandwich has of sneaking its way past the doorman at the Hilton. > >Well, the PowerPC does some pretty decent frame rates. >And I think Prince of Persia was a decent game, and SimCity 2000 >still is. Not to mention Space Madness and Cyclone. ;-) But it's true, if we didn't have to go to such great lengths to produce flicker-free animation on the Mac, we could have some pretty hot games that just aren't feasible now. We might even be able to scroll full screen at a decent frame rate, and still have time for all the other game computations. Mike. -- _____________________________________________________________________________ Michael A. Kelly President/CEO mkelly@cs.uoregon.edu High Risk Ventures _____________________________________________________________________________ +++++++++++++++++++++++++++ >From mkelly@cs.uoregon.edu (Michael A. Kelly) Date: 15 Jun 1994 10:54:21 -0700 Organization: High Risk Ventures In article , Ivan M CaveroBelaunde wrote: >><<"Inferior" video modes are quite useful when you want to sacrifice resolution >>for speed.>> >kind of games, etc). The sole *availability* of an "inferior" video mode >would allow the game designer the choice of sacrificing one for the other - >a choice we don't have right now. But we can still pretend we do. As was mentioned previously in this thread, we can gain considerable speed by keeping the game at 320x240 offscreen and blowing it up (or not) to 640x480 on screen. I've played around with this, and there *is* a significant speedup. You're doing 1/4 the work offscreen, and maybe around 3/4 the work onscreen. With the right application (and prehaps a combination of high- and low-resolution graphics on screen) this technique can be acceptable to even the typical 'snotty' Mac user (of which I am one!) who dry heaves at the thought of 320x240 games. Deliverance is probably a pretty good example of how and when to use this technique, and how to present it (they give the user the option to play in a 320x240 window at high resolution or in a 640x480 window at low resolution). Mike. -- _____________________________________________________________________________ Michael A. Kelly President/CEO mkelly@cs.uoregon.edu High Risk Ventures _____________________________________________________________________________ +++++++++++++++++++++++++++ >From mkelly@cs.uoregon.edu (Michael A. Kelly) Date: 15 Jun 1994 11:10:23 -0700 Organization: High Risk Ventures In article <2tnei7$t1u@majestix.cs.uoregon.edu>, Michael A. Kelly wrote: >In article <2tmq0b$t70@news.kth.se>, >Jon Wätte wrote: >> >>Well, the PowerPC does some pretty decent frame rates. >>And I think Prince of Persia was a decent game, and SimCity 2000 >>still is. > >Not to mention Space Madness and Cyclone. ;-) BTW, Space Madness and Cyclone both run flicker-free at 60 fps on '040 Macs, at 8-bit 640x480 resolution. And, like most action games on the Mac, they easily run at 30 fps on lesser machines. Prince of Persia tended to slow down quite noticeably on my IIcx when there was a slicer on the screen, but I suspect it was using Quickdraw. It should be easy to achieve at least 30 fps on slow machines with a game like PoP, which has a textured background, but few objects with relatively little movement, if you draw direct to screen. Of course, a scrolling background is quite a different story... Mike. -- _____________________________________________________________________________ Michael A. Kelly President/CEO mkelly@cs.uoregon.edu High Risk Ventures _____________________________________________________________________________ +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 15 Jun 1994 16:49:30 GMT Organization: The Royal Institute of Technology In mikec@mv.mv.com (Mike Callaghan) writes: >What about programs like Stepping Out? It did great full-screen scrolling >relatively quickly even on a Mac Plus. I realize that doing this in a Ah, but that was in black-and-white. Everyone can scroll a screen in black-and-white. >window is a completely different story, but how did Stepping Out accomplish No, it's no harder scrolling in a window that scrolling a screen. >it? Is it possible to set up a giant bitmap (or pixmap) and simply alter >the address where the Mac thinks its screen is? For the MacPlus, you can do something close to that, but with limitations. For some video cards, in some modes, you can do it as well. However, it's not something that all video cards/drivers support, and most cards don't have enought memory for it. -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "My boss made me say it. He dares you to sue!" +++++++++++++++++++++++++++ >From sly@fly2.berkeley.edu (Cyrus Harmon) Date: Wed, 15 Jun 1994 11:51:11 -0700 Organization: UC Berkeley In article <2tmq37$t75@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte) wrote: > Most screen cards stop at 640x480; the 512x384 mode is only for the > Mac LC 12" color monitor and the Color Classic 10" built-in color, > none of which sold well. > > A Mac has square pixels at 72 dpi, and that's it! Except with the multiple scan monitors that let you select video modes. I guess for the first time Apple is now offering "inferior" video modes :->. Cyrus Harmon sly@fly2.berkeley.edu +++++++++++++++++++++++++++ >From larsg@edb.tih.no (Lars Garden) Date: 16 Jun 1994 13:33:13 GMT Organization: Trondheim College of Engineering Malicious Monarch (Malicious_Monarch@nile.com) wrote: : <<"Inferior" video modes are quite useful when you want to sacrifice resolution : for speed.>> : That's true, but I don't know many people who would like to take a game with : pixelated graphics over one that has very precise -shall I say 'crisp'? :) - : graphics. There's always more than one way to make a game... I know a lot of people that would prefer a 320*200 20fps DOOM over a 640x480 4fps DOOM. -- // Lars Gaarden. Student at Trondheim College of Engineering. \\ // email: larsg@edb.tih.no IRC: Lynet \X/ "But I will rise and I will return like a phoenix from the flame." - Sinéad O'Conner +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 14 Jun 94 14:22:46 MST Organization: (none) In article <2tkmlv$602@beta.qmw.ac.uk>, enry@dcs.qmw.ac.uk (Henry) writes: > > Shuffling bytes about in memory just puts a huge burden on the processor > when it should be calculating something far less menial. > Why can I not change the video hardware's screen base pointer, and fill in the > newly exposed part of the screen. This eliminates as much bit copying as we > like (give enough vram set asside)... > It also has the added advantage of having an offscreen pixmap, and being > able to display it instantly without blasting bytes through the proccessor, > allowing sencible (fast) screen buffering. > > Is it possible to reliably direct the macs hardware to a different > screen buffer? > (You can do it on a Mac512k :-) > If not, can I do it unreliably? > If not, you are all destined to fester in the mouldy crevis of a mac games > industry that has about as much chance of producing a decent game, as a > cheese sandwich has of sneaking its way past the doorman at the Hilton. > And of course, Apple didn't provide any standard, or at least, *documented*, way to do it on the PowerMacs because we all know how worried they are about the games industry... And telling me to go look in the book on creating hardware add-on cards for information about the potential for page-flipping in a Mac video card is hardly contributing to the upliftment of Apple games-writing, although it could be seen as a way of telling potential games-writers on the Mac to bugger-off -we don't want you here... Lawson +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Thu, 16 Jun 1994 19:42:43 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA larsg@edb.tih.no (Lars Garden) writes: > I know a lot of people that would prefer a 320*200 20fps DOOM over > a 640x480 4fps DOOM. Would anyone like a 640x480 15-20fps DOOM in greyscale ... but anti-aliased? This is actually a serious question. Amanda Walker InterCon Systems Corporation +++++++++++++++++++++++++++ >From shirleyd@cognos.COM (Dieter Shirley) Date: Thu, 16 Jun 1994 19:49:57 GMT Organization: Cognos Incorporated, Ottawa CANADA Michael A. Kelly (mkelly@cs.uoregon.edu) wrote: : In article <2tmq0b$t70@news.kth.se>, : Jon Wätte wrote: : > : >>Is it possible to reliably direct the macs hardware to a different : >>screen buffer? : > : >Only if you want to special-case for dozens of video cards. : What? I was under the impression that it can't be done in any case (except : for some of the classic Macs of course) because the pointer to the video : buffer is in hardware. So you're saying it's possible to do page-flipping : on a Mac? How do you swap the pointer? It sounds like you're also saying : that the second page has to be in video memory, right? Yeah, there is a call, documented in the legendary IM: Cards and Drivers that video card developers can support which allows page flipping. Of course, all of the card developers do it a little bit differently. (Not the page flipping, but drawing to the different pages.) Add to this that most (if not all) internal video Macs don't support this and not all video cards do, and you've got to write normal code for those cases anyways. But, it can and has been done. Try playing OIDS on a slower machine, like a IIci or IIcx with a Toby 8-bit card, then install MaxAppleZoom, which uses the extra VRAM for it's own purposes and see what OIDS looks like *without* the page flipping. Very hideous. Later, -dete +++++++++++++++++++++++++++ >From y-tony@bu.edu (Yan Lee) Date: 17 Jun 1994 02:11:39 GMT Organization: Boston University Amanda Walker (amanda@intercon.com) wrote: : larsg@edb.tih.no (Lars Garden) writes: : > I know a lot of people that would prefer a 320*200 20fps DOOM over : > a 640x480 4fps DOOM. : Would anyone like a 640x480 15-20fps DOOM in greyscale ... but anti-aliased? : This is actually a serious question. Would grayscale actually make a difference in speed? It is still following 8-bits of color/shades. : Amanda Walker : InterCon Systems Corporation P.S. Thanks for the enormous responses about scrolling. I never expected so much input! Tony +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Fri, 17 Jun 1994 18:22:36 +1200 Organization: HyperMedia Unit, Auckland University In article <2tnbpm$f24@unix.sri.com>, mxmora@unix.sri.com (Matt Mora) wrote: > In article mikec@mv.mv.com (Mike Callaghan) writes: > > >What about programs like Stepping Out? It did great full-screen scrolling > >relatively quickly even on a Mac Plus. I realize that doing this in a > >window is a completely different story, but how did Stepping Out accomplish > >it? Is it possible to set up a giant bitmap (or pixmap) and simply alter > >the address where the Mac thinks its screen is? > > > Stepping out only had 22k of data to blit to worry about. Color Macs > have about 300k of data to blit. Big difference. Is it possible to use the MMU to scroll without blitting? This may only work with RBV (and even then I think I remember something about the hardware getting frame buffer data from physical address $00000000). Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From byrne1@husc8.harvard.edu (Laurence Byrne) Date: 17 Jun 94 14:17:16 GMT Organization: Harvard University, Cambridge, Massachusetts y-tony@bu.edu (Yan Lee) writes: >Amanda Walker (amanda@intercon.com) wrote: >: larsg@edb.tih.no (Lars Garden) writes: >: > I know a lot of people that would prefer a 320*200 20fps DOOM over >: > a 640x480 4fps DOOM. >: Would anyone like a 640x480 15-20fps DOOM in greyscale ... but anti-aliased? >: This is actually a serious question. >Would grayscale actually make a difference in speed? It is still >following 8-bits of color/shades. I would imagine that the purpose of going to grayscale is not to directly speed up the graphics - as you point out, it's still 8 bits - but instead to make the anti-aliasing more effective/less noticeable. (The human eye having a limit to its ability to resolve shades of gray.) Personally, to get back to the original question, I think I'd find that a gray Doom lost about 30% of its entertainment value - it'd probably be almost as much fun to play, but there's still a world of difference between colour and b/w.... -- - ----------------------------------------------------------------------------- Laurence Byrne un chien andalusia byrne1@husc.harvard.edu Hist/CS *finger @byrne1.student.harvard.edu for PGP pubkey* A zygote is a gamete's way of producing more gametes. This may be the purpose of the universe. - Lazarus Long +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 17 Jun 1994 20:30:07 GMT Organization: The Royal Institute of Technology In <2tnei7$t1u@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes: >buffer is in hardware. So you're saying it's possible to do page-flipping >on a Mac? How do you swap the pointer? It sounds like you're also saying >that the second page has to be in video memory, right? Yes. There are DOCUMENTED video driver calls to do that, but not all video cards support them, and almost no video cards have enough memory to make the feature useful. >We might even be able to scroll full screen at a decent frame rate, and still >have time for all the other game computations. When scrolling is a big matter, those "other game computations" usually shring to insignificance (on the order of one line of scrolling pixels...) Anyway, locking yourself to a specific blitter is OK for machines with a short usable life span, but for anything that's supposed to improve and stay compatible, it's not really a good idea. However, Apple COULD HAVE put a blitter in the lower-power models and had it accellerate CopyBits. I guess another $50-100 in the retail channel wasn't deemed worth it. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "My boss made me say it. He dares you to sue!" +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 17 Jun 1994 20:34:55 GMT Organization: The Royal Institute of Technology In byrne1@husc8.harvard.edu (Laurence Byrne) writes: >I would imagine that the purpose of going to grayscale is not to directly >speed up the graphics - as you point out, it's still 8 bits - but instead >to make the anti-aliasing more effective/less noticeable. (The human eye >having a limit to its ability to resolve shades of gray.) Personally, to Actually, I think black/white means 4-bit mode, in which you can do page flippin on many vide cards, and palette flipping on the others. -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "My boss made me say it. He dares you to sue!" +++++++++++++++++++++++++++ >From lewistot@netcom.com (John Lewis) Date: Sat, 18 Jun 1994 07:04:43 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) 103t_english@west.cscwc.pima.edu wrote: : And of course, Apple didn't provide any standard, or at least, *documented*, : way to do it on the PowerMacs because we all know how worried they are about : the games industry... Actually, Apple is very concerned about the game industry. At Maxis (the SimCity people), we receive pre-release documentation and beta software almost weekly. Our experience is not unique either. At a recent PowerMac hands-on development seminar I went to, one third of the companies invited were game companies. Using some "dirty rectangle" techniques, I can acheive some fairly decent fps rates on slower Macs and some damn spectacular fps rates on PowerMacs. : And telling me to go look in the book on creating hardware add-on cards for : information about the potential for page-flipping in a Mac video card is : hardly contributing to the upliftment of Apple games-writing, although it could : be seen as a way of telling potential games-writers on the Mac to bugger-off : -we don't want you here... You might try going back to the books to investigate other means of doing fast scrolling other than page flipping. With a little care, Copybits can do some amazing things. Also, try actually finding out what people in the game industry think of Apple BEFORE you go flaming them. -- - ------------------------------------------------------------------------- John "I'ld rather be skydiving" Lewis|#include "standard .sig BS" |Witty | lewistotle@netcom.com <- prefered |Blue Skies to all skydivers.|text | jlewis@maxis.com <- work |USPA 87419, C-22826 |picture| lewistotle@aol.com <- rarely | |comming| +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Sat, 18 Jun 1994 11:20:49 GMT Organization: Best Before Yesterday In article <1994Jun13.103349.1@csc.canterbury.ac.nz>, misc173@csc.canterbury.ac.nz wrote: > > > I missed the original post, but if it's about full screen scrolling at > > 30fps, that's still pretty much impossible. There are several solutions > > people have used, such as the draw-every-other-line approach in Deliverance > > to improve speed on slower Macs. Also, QuickTime 2 does it, though that > > doesn't count (I think it doesn't really redraw all the screen all the > > time). > > > > Someone sent me a test result from a PowerMac: straight blitting a 640x480 > > image to the screen and doing nothing else, the frame rate was only about > > 25fps. Games would also do lots of drawing offscreen > > I couldn't believe this post when I read it yesterday, so I went home > and wrote a 640x480x8bit RAM scroller, it starts at 0 and scrolls up through > RAM, copying it to the screen, one line per frame. It got 40 fps on my 605, and > I know that it could be optimised more, unrolling the inner loop, etc. I tried > a variety of resolutions and interpolation techniques and gained some > interesting insights. If you reduce the screen size the speed increases > proportionaly, 320x240x8bit at 150fps. Using alternate lines doubles the speed > again ( and looks fairly good against black ), pixel doubling is very slow, I > havent tried using movep yet, but it should speed things up ( if it works ). > This routine uses only move.l, as I intend to program for 040's I will > try move16, which should speed things up about 3x. > The final conclusion is that whoever wrote that ppc blitter ain't very > good, I know enough assembly to this, and other simple graphics routines, but > it still goes reasonably fast ( at least 10% faster than copybits ). Full > screen scrolling is possible, and if someone asks for it I'll even post my > code. I've left all my news to the weekend to answer, so I've finally got round to reading it to find I haven't been holding up my side fo the argument. :-) Full screen scrolling IS impossible for a game, because you don't take into account the huge amount of offscreen drawing which is done before the image is blitted to the screen. Often only 20 percent or even less of the time is for copying to the screen, and the rest is drawing masked objects, new areas, etc. to the offscreen worlds. But you're right about direct copying: if you wanted to, you can redraw a whole screen >30 fps. Bit of a boring game, though. :-) Best wishes, Alex -- Alex Metcalf, Best Before Yesterday Mac programmer in C, C++, HyperTalk, assembler Juggler, 3-ball tricks Internet: alex@metcalf.demon.co.uk Fax (UK): (0570) 45636 Fax (US / Canada): 011 44 570 45636 +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Mon, 20 Jun 1994 17:06:08 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA In article <2tr0or$j5a@news.bu.edu>, y-tony@bu.edu (Yan Lee) writes: > Would grayscale actually make a difference in speed? It is > still following 8-bits of color/shades. For anti-aliased texture mapping, 8-bit gray scale takes a lot less memory than 24-bit color, and is somewhat faster... Amanda Walker InterCon Systems Corporation +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Mon, 20 Jun 1994 17:07:14 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA d88-jwa@mumrik.nada.kth.se (Jon W”tte) writes: > Actually, I think black/white means 4-bit mode, in which you can do > page flippin on many vide cards, and palette flipping on the others. Nope, I meant 8-bit gray scale. This way I don't need 24 bit texture maps, and don't have to reduce it to an 8-bit palette, both of which would increase the possible speed. Amanda Walker InterCon Systems Corporation +++++++++++++++++++++++++++ >From s3026557@titanic.mpce.mq.edu.au (Duncan Anker) Date: 23 Jun 1994 09:33:53 GMT Organization: Macquarie University, School of Mathematics, Physics, Computing and Electronics Amanda Walker (amanda@intercon.com) wrote: : larsg@edb.tih.no (Lars Garden) writes: : > I know a lot of people that would prefer a 320*200 20fps DOOM over : > a 640x480 4fps DOOM. : Would anyone like a 640x480 15-20fps DOOM in greyscale ... but anti-aliased? : This is actually a serious question. Given that the Mac I normally use (apart from those cute powerbooks :-) has a greyscale moniter, I hardly think I'd miss the colour. So a serious answer to a serious question. Yes, I would like a 640x480 15-20fps DOOM in greyscale. Are you writing one, Amanda? -- s3026557@titanic.mpce.mq.edu.au * Duncan Anker * duncan@newling2-00.une.edu.au O.K. Scotty, real funny. Now beam down my clothes! --------------------------- >From gneufeld@superior.carleton.ca (Grant Neufeld) Subject: MacPerl- Redirecting STDIN & STDOUT Date: Sat, 25 Jun 1994 17:22:23 GMT Organization: Carleton University I haven't managed to figure out how to redirect STDIN and STDOUT in MacPerl. I have a script that runs as follows in UNIX: myscript myoutputfile I want to be able to specify at least mysourcefile (I can save the contents of the MacPerl console for the output) without having to do anything drastic to my source code. Any direction (including where to look in the docs/help so I can RTFM) would be much appreciated. -- Grant Neufeld - gneufeld@ccs.carleton.ca - Ottawa, Ontario, Canada Grant Neufeld Apple Research Partnership Program, +1 (613) 788-2600 extenstion 3537 My views are too extreme to be anyone else's +++++++++++++++++++++++++++ >From grbr@arapaho.ucsc.edu (Terry Gritton) Date: Sat, 25 Jun 94 17:48:47 GMT Organization: University of California, Santa Cruz In Article , gneufeld@superior.carleton.ca (Grant Neufeld) wrote: >I haven't managed to figure out how to redirect STDIN and STDOUT in >MacPerl. I have a script that runs as follows in UNIX: > > myscript myoutputfile > >I want to be able to specify at least mysourcefile ... You could just use drag and drop, drag the input file onto the icon of the program. Then in the perl program you need to read the first argument. Something like #!/usr/bin/perl # Useage(commandline): Prog file1 # Useage(Mac GUI): drop input file on Prog icon $file1 = @ARGV[0]; open(FILE, $file1) || die "Can't open $file: $!\n"; while () { foreach $i (split) { $file1contents{ $i } = 'file1'; } } close(FILE); - ---------------------------------------------------------------- Terry Gritton "the reason people so often lie Interests: is that they lack imagination: glycoproteins as they don't realize that the truth, too, intercellular is a matter of invention." interregulatory Antonio Machado messages --------------------------- >From peskin@caip.rutgers.edu (Richard L. Peskin) Subject: PowerPC floating point issue Date: 21 Jun 94 18:20:39 GMT Organization: Rutgers Univ. Can anyone give me a "simple" explanation for the very poor floating point performance of the PowerPC's (native code) when transcendental funtions are involved? Is this just a poor library implementation problem? Is Apple planning to address this issue anytime soon? --dick peskin ================================= R. L. Peskin, Rutgers Univ. ; ; 908/932-3685 "Good work is always done in defiance of management." R. Woodward +++++++++++++++++++++++++++ >From weare@galaxy.ucr.edu (christopher weare) Date: 21 Jun 1994 15:04:58 -0700 Organization: University of California, Riverside In article , Richard L. Peskin wrote: >Can anyone give me a "simple" explanation for the very poor floating >point performance of the PowerPC's (native code) when transcendental >funtions are involved? Is this just a poor library implementation >problem? Is Apple planning to address this issue anytime soon? >--dick peskin >================================= >R. L. Peskin, Rutgers Univ. ; ; 908/932-3685 >"Good work is always done in defiance of management." R. Woodward The simple reason is that MathLib (the library supplied by apple) is very slow. IBM's equivalent lib is about 10 times faster. Apple says they "are aware of the problem" and are working on a fix. If anyone knows when that might be I'd love to hear. Personaly, I think apple should have tried to license the IBM lib, but ofcourse, I have no idea what was involoved in the creation of MathLib. I serriously doubt that apple will do as good a job on their lib as IBM did, but I hope I am wrong. Ofcourse i mean FAST when i say good. Chris weare@galaxy.ucr.edu +++++++++++++++++++++++++++ >From Todd M. Morin Date: 24 Jun 1994 15:38:55 GMT Organization: Truevision Inc., Indianapolis, IN I saw the below announcement on Compuserve a couple days ago, and it's relevant to this issue. I haven't contacted him yet, so I don't know what his license fees are. --ToddM. - ------------------------------------------------------------------------ - --------------------- Announcement to anyone using the Math Library provided for Power PC Macintoshes! After recompiling a piece of scientific code for the PowerPC which spends most of its time computing transcendental functions and sqrts and achieving very poor performance, I investigated the Apple Math Library for the Power PC's. I found it to be extremely slow, and am not sure why. However, I have since produced a library of my own for computing functions about 4-5 times faster than the Apple library. This library currently implements sin(), cos(), exp(), pow(), sqrt(), log(), tan(), atan(), sinh(), cosh(), log1p(), and expm1(), along with low level functions ldexp() and frexp(). It does not (presently) do any IEEE-754/NCEG (etc) exception handling, but in all cases correctly handles and returns NaN's, Inf's and denorms as appropriate. The accuracy of the functions is typically about 1-2 LSB (i.e. about 1-2e-16) for most input values. This library is available as an xcoff file (compatible with MPW linking and, hence, Symantec C++ and MPW). It consists of routines of my own design, and is therefore assured to not be pirated or to infringe on any copyrights. The routines were compiled on and IBM RS/6000 601-based workstation, using the highly optimizing level of the xlc compiler. They contain no POWER instructions, so they should be compatible with 601, 603, 604 & 620 (etc.) machines as they become available. If you are interested, please contact me about licensing, either for single machine licenses, licenses to distribute in compiled code, or licenses to distribute in object form to accompany development environments. Also, if you are interested in seeing other functions beyond my 'top ten' list added to the library, I would be glad to do so. Also, Xenotek has expertise in writing fast numerical algorithms and data acquisition/control systems. If you have need of such custom development, please contact us. Marcus Mendenhall, Ph.D., Xenotek, Inc. (615)297-5756 or via Compuserve mail (76344,251) +++++++++++++++++++++++++++ >From weare@galaxy.ucr.edu (christopher weare) Date: 24 Jun 1994 12:21:18 -0700 Organization: University of California, Riverside [bunch o stuff deleted describing a faster lib replacement for MathLib] Some questions for the developer: 1) How does your library compare to IBM's math library? Post on this channel sugest that the IBM lib is about 10 times faster than apple's when running the savage (is that the name?) benchmark. Could you compare your lib to IBM's usingthat benchmark please. 2) Are you aware that apple is promising to upgrade thier library "soon". 3) Could you write a lib using floats instead of doubles so we have a choice of fast vs accurate? Thanks Chris weare@galaxy.ucr.edu +++++++++++++++++++++++++++ >From AppleGG@lamg.com (Gordon Apple) Date: 25 Jun 1994 12:06:20 -0000 Organization: Los Angeles Macintosh Group BBS >3) Could you write a lib using floats instead of doubles so we have a choice >of fast vs accurate? I doubt that floats are any faster than doubles on the PPC although they would certainly be faster on a non-FPU 68K. However, please, please, please give us the fastest trancedentals possible, even at an (optional) sacrafice of accuracy. There are many signal processing applications where 8-bit accurachy is overkill and floats are way overkill. (You'd be amazed at things we used to do in space and military programs with three-bit A/D converters.) --------------------------- >From bb@lightside.com (Bob Bradley) Subject: Q: Thread Manager - How do I benefit? Date: Wed, 22 Jun 1994 06:10:21 -0800 Organization: Lightside, Inc. In Develop 17, in the article about concurrent processing with the Thread Manager, it says I'll be able to do other processing while a modal dialog is up. In my app, I have 2 event queues, the normal WNE event queue and a custom event queue that I've created. I've set these up as YieldToUserProcess() and YieldToCustomProcess() which simple pull the event out of the queue (if one exists) and process the event. During my ModalDialog() loop, I call my YieldToCustomProcess() routine each time thru. How would I benefit from using the Thread Manager (PowerPC)? From what I've gathered it appears to do just what I've done but, in a more generalized manner (ie not stuck with just my limited event queue). How does calling YieldToAnyThread() differ in functionality? +++++++++++++++++++++++++++ >From Ken Prehoda Date: 23 Jun 1994 15:13:50 GMT Organization: Univ of Wisc-Madison In article Bob Bradley, bb@lightside.com writes: >How would I benefit from using the Thread Manager (PowerPC)? From what I've >gathered it appears to do just what I've done but, in a more generalized >manner (ie not stuck with just my limited event queue). How does calling >YieldToAnyThread() differ in functionality? The case that you give is a small benefit of the thread manager. As you have shown, it is possible to get similar results for modal dialogs without using the thread manager (although it's simpler with the thread manager). However, the thread manager lets you process a couple thousand fourier transforms (or any other time consuming process in your app) while still having the interface very responsive. Unfortunately, the powerpc version doesn't have preemptive threads and that makes it a little less attractive. Oh, if you're asking how YieldToAnyThread() is different, it is different in the sense that control is passed on to multiple threads in a round-robin fashion (cooperatively speaking) whereas your control functions just switch between two event queues. Preemptive threads snatch time from each cooperative thread in a round-robin fashion. -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 23 Jun 1994 17:36:54 GMT Organization: Apple Computer Bob Bradley, bb@lightside.com writes: > How would I benefit from using the Thread Manager (PowerPC)? From what I've > gathered it appears to do just what I've done but, in a more generalized > manner (ie not stuck with just my limited event queue). How does calling > YieldToAnyThread() differ in functionality? The Thread Manager is a much smoother implementation of what you've done. Your stuff relies on external objects you call 'events'. You have to interrupt your processing to handle an event, and can't continue with what you were doing until that event finishes. Threads, on the other hand, have different stacks and can switch in and out. When a thread calls Yield, other threads get a chance to run, but the thread that called Yield also keeps running as soon as its time comes around when another thread yields. Think of how your stuff would (not) work if one of your custom events involved downloading a 10 megabyte file. What if you got two of these events? One would have to wait until the first one finished. Your stuff can handle events sequentially but can't interleave them, whereas threads can. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Thu, 23 Jun 1994 10:11:21 -0800 Organization: Lightside, Inc. In article <1994Jun23.173654.22435@gallant.apple.com>, Jens Alfke wrote: > Think of how your stuff would (not) work if one of your custom events > involved downloading a 10 megabyte file. What if you got two of these events? > One would have to wait until the first one finished. Your stuff can handle > events sequentially but can't interleave them, whereas threads can. When using only cooperative threads, could I use a single thread to download a 10 meg file and would calling YieldToAnyThread() stop that large thread to process other threads or would I have to add a lot of YieldToAnyThread() calls within that large thread? I'm a little confused about how other threads would get time while one thread is executing. I thought cooperative threads would still have to execute one after the other. Am I totally lost? +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 24 Jun 1994 08:36:40 GMT Organization: The Royal Institute of Technology In bb@lightside.com (Bob Bradley) writes: >about how other threads would get time while one thread is executing. I >thought cooperative threads would still have to execute one after the >other. Am I totally lost? Sort of. Calling YieldToAnyThread() basically says "I can take a pause now, let another thread continue from where it was created/yielded last." Then, when that thread calls YieldToAnyThread(), you'll eventually get back to the first thread, which will continue from the Yield call. When you do downloads, the serial port is usually so slow that it's DEFINATELY worthwile to do async reads and yield. With the async SCSI manager, you can do that on file I/O as well. -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi --------------------------- >From soetji+@G.GP.CS.CMU.EDU (Soetjianto) Subject: prevent update when call TEDelete, TEInsert?? Date: Thu, 23 Jun 1994 22:01:31 GMT Organization: School of Computer Science, Carnegie Mellon I am doing all sorts of manipulation on a TE, using TEScroll, TEDelete, TEInsert. I want the user only see the final state of the TE after all manipulations have been done. Is there a way to do this? I have tried ValidRect(), but it doesn't work. Any idea how to do it? thanks! soetji@g.gp.cs.cmu.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 24 Jun 1994 17:02:08 GMT Organization: Apple Computer Soetjianto, soetji+@G.GP.CS.CMU.EDU writes: > I am doing all sorts of manipulation on a TE, > using TEScroll, TEDelete, TEInsert. I want > the user only see the final state of the TE after > all manipulations have been done. Is there a way to > do this? You could either set the TE record's viewRect to an empty Rect, or set the port's clipping region to an empty region (call ClipRect with an empty rect.) Of course, you have to set them back to normal afterwards. You may find this rather slow if you are doing a lot of work. If you're using monostyled Text (i.e. you called TENew rather than TEStylNew) you can speed things up by directly munging the text in the hText handle, then calling TECalText at the end. The Munger trap is the best way to do this kind of insertion/substitution/deletion on a handle, although its interface is somewhat hard to figure out at first. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- End of C.S.M.P. Digest **********************