ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-043

Text File | 2010-09-21 | 130KB | 3,269 lines

Received-Date: Sat, 9 Jul 1994 13:50:45 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-043
To: [e-mail]
Date: Sat, 9 Jul 1994 13:50:38 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 46

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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] (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
[e-mail]            Computer Services -- User Services

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (Troy Gaul)
Date: Wed, 22 Jun 1994 21:14:02 -0700
Organization: Infinity Systems

In article <2u85bm$[e-mail]>, [e-mail]
(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 [e-mail]__ //
  //    //       Infinity Systems ; Redmond, Washington                //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 23 Jun 1994 15:35:07 +0800
Organization: NCRPDA, Curtin University

In article <2u85bm$[e-mail]>, [e-mail]
(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 <[e-mail]>       Ph: [phone]

---------------------------

>From [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Stan Horwitz)
Date: 16 Jun 1994 20:19:57 GMT
Organization: Temple University, Academic Computer Services

Matt Mora ([e-mail]) 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 [e-mail]
My opinions are all mine. They do not reflect those of my employer.


+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Thu, 16 Jun 1994 22:49:15 GMT
Organization: National Renewable Energy Laboratory

In article <2tq798$[e-mail]> Matt Mora, [e-mail]
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 <[e-mail]>
Date: 16 Jun 1994 22:02:06 GMT
Organization: University of North Texas

In article <2tq798$[e-mail]> Matt Mora, [e-mail]
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:[phone]
Macintosh Support         | Denton TX 76203         | Fax  :[phone]
University of North Texas | EMail: [e-mail]  |
WWW: http://gaia.nms.unt.edu/cchome/mcmains/mcmains.html

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 16 Jun 1994 14:07:46 -0700
Organization: SRI International, Menlo Park, CA

In article <2tqc5d$[e-mail]> [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Adam Elman)
Date: Thu, 16 Jun 1994 16:38:31 -0800
Organization: Residential Computing, Stanford University

In article <2tqc5d$[e-mail]>, [e-mail]
(Stan Horwitz) wrote:

> Matt Mora ([e-mail]) 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/
[e-mail] | 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 [e-mail] (John W. Baxter)
Date: Thu, 16 Jun 1994 19:18:36 -0700
Organization: Internet for the Olympic Peninsula

In article <2tq798$[e-mail]>, [e-mail] (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.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Fri, 17 Jun 1994 11:13:22 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Matt Mora ([e-mail]) 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, "<expletive deleted>
them."  Don't let them demote AppleTalk to a second class protocol.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 17 Jun 1994 11:45:44 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Jon Pugh) writes:
>Matt Mora ([e-mail]) 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, "<expletive deleted>
>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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (eric doc kampman)
Date: Fri, 17 Jun 1994 17:44:49 -0800
Organization: farallon

In article <[e-mail]>, [e-mail] (Jon Pugh)
wrote:

> Matt Mora ([e-mail]) 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).

--
[e-mail]
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 [e-mail] (Bruce Hoult)
Date: Sun, 19 Jun 1994 01:46:44 +1200 (NZST)
Organization: (none)

[e-mail] (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 [e-mail] (RUPNIK, CHRISTOPHER E.)
Date: Sat, 18 Jun 1994 16:20:00 GMT
Organization: Concordia University

In article <[e-mail]>, [e-mail] (Bruce Hoult) writes...
>[e-mail] (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
  [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Stephen Panarelli)
Date: 19 Jun 1994 11:30:40 GMT
Organization: University of Nebraska--Lincoln

Carl R. Osterwald ([e-mail]) wrote:
: In article <2tq798$[e-mail]> Matt Mora, [e-mail]
: 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
         _/  _/    _/    _/            | [e-mail]
_/_/_/_/_/  _/      _/  _/             | [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 20 Jun 94 17:15:51 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (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: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Where would we be without rhetorical questions?

+++++++++++++++++++++++++++

>From [e-mail] (Stephan Somogyi)
Date: Mon, 20 Jun 1994 06:32:10 GMT
Organization: Digital Media

In article <[e-mail]>, [e-mail] (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 [e-mail] (Stephan Somogyi)
Date: Mon, 20 Jun 1994 06:33:31 GMT
Organization: Digital Media

In article <doc-170694174449@163.176.12.68>, [e-mail]
(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 [e-mail] (Peter W. Poorman)
Date: 20 Jun 94 16:50:10 GMT
Organization: CONVEX Computer Corporation, Richardson, TX USA

In <doc-170694174449@163.176.12.68> [e-mail] (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
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (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"             [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Tue, 21 Jun 1994 16:11:01 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail]
(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!"      <[e-mail]>     "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 [e-mail] (Garry Hornbuckle)
Date: 21 Jun 1994 16:17:55 GMT
Organization: Apple Computer

> In article <doc-170694174449@163.176.12.68>, [e-mail]
> (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      [e-mail]
 spoke only for myself  | applelink  HORNBUCKLE1
 would you believe me?" | fax        [phone]
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (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                                    [e-mail]
                            Software Tool
                          Shiva Corporation

---------------------------

>From Peter Vanags <[e-mail]>
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 <[e-mail]>
Date: 24 Jun 1994 23:49:38 GMT
Organization: Pole Position Software

In article <2uap83$[e-mail]> Peter Vanags,
[e-mail] 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 [e-mail] (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 [e-mail] (Jon Wdtte)
Date: 9 Jun 1994 10:13:06 GMT
Organization: The Royal Institute of Technology

In <2t5bff$[e-mail]> [e-mail] (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, [e-mail], 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 [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Thu, 9 Jun 1994 12:33:48 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <2t5bff$[e-mail]>, [e-mail] (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?"
[e-mail]    |         - Mike Wellman, in c.s.m.p

+++++++++++++++++++++++++++

>From [e-mail] (Yan Lee)
Date: 9 Jun 1994 14:59:00 GMT
Organization: Boston University

Chris Gonna' Find Ray Charles Tate ([e-mail]) wrote:
: In article <2t5bff$[e-mail]>, [e-mail] (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?"
: [e-mail]    |         - Mike Wellman, in c.s.m.p


Thanks for all the responses.

+++++++++++++++++++++++++++

>From [e-mail]
Date: 9 Jun 94 14:47:34 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

In article <2t5bff$[e-mail]>, [e-mail] (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 [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Jun 94 16:30:59 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <2t6pvi$[e-mail]>, [e-mail] (Jon Wdtte) writes:
> In <2t5bff$[e-mail]> [e-mail] (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: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (Ingemar Ragnemalm)
Date: 11 Jun 1994 07:50:43 GMT
Organization: (none)

[e-mail] (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: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Sat, 11 Jun 1994 10:50:42 GMT
Organization: Best Before Yesterday

In article <[e-mail]>, [e-mail]
(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:          [e-mail]
Fax (UK):          (0570) 45636
Fax (US / Canada): 011 44 570 45636

+++++++++++++++++++++++++++

>From [e-mail]
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 [e-mail] (Ivan M CaveroBelaunde)
Date: Mon, 13 Jun 1994 00:13:44 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (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 ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail]
Date: 12 Jun 94 18:28:03 MST
Organization: (none)

In article <[e-mail]>, [e-mail] 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 [e-mail]
Date: 12 Jun 94 23:22:57 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

In article <[e-mail]>, [e-mail] (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 <[e-mail]>
Date: Mon, 13 Jun 1994 05:47:46 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Anton Rang,
[e-mail] 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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 13 Jun 1994 06:44:15 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] 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, [e-mail], Mac Software Engineer Deluxe --
 "Don't stick a Fork in your Eye."

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail]:
> In article <[e-mail]>, [e-mail] (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 ([e-mail]  or  [e-mail])
--
-- Life is the Dress Rehearsal for Hell.
--

+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Mon, 13 Jun 1994 14:05:46 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

[e-mail] (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 [e-mail] (Matt Mora)
Date: 13 Jun 1994 13:22:29 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] 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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 13 Jun 1994 15:00:37 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 13 Jun 1994 16:58:42 -0700
Organization: SRI International, Menlo Park, CA

In article <2tif65$[e-mail]> [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail]
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 [e-mail]
Date: 13 Jun 94 21:29:36 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

In article <[e-mail]>, [e-mail] (Steve Taylor) writes:
> From article <1994Jun12.232257.24853@dal1>, by [e-mail]:
>> In article <[e-mail]>, [e-mail] (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 [e-mail]
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 [e-mail] (Jon Wdtte)
Date: 14 Jun 1994 13:04:10 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] 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, [e-mail], Mac Software Engineer Deluxe --
    Not speaking for the Liberian Government.

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (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 [e-mail] (Bruce Hoult)
Date: Wed, 15 Jun 1994 03:01:36 +1200 (NZST)
Organization: (none)

[e-mail] (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 [e-mail] (Lars Garden)
Date: 14 Jun 1994 18:03:14 GMT
Organization: Trondheim College of Engineering

Jon Wdtte ([e-mail]) wrote:
: In <2t5bff$[e-mail]> [e-mail] (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: [e-mail]  IRC: Lynet
  \X/   "But I will rise and I will return like a phoenix from the flame."
         - Siniad O'Conner


+++++++++++++++++++++++++++

>From [e-mail] (Julian Ross  Harris)
Date: 14 Jun 1994 23:37:59 GMT
Organization: University of Auckland

[e-mail] (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, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: 14 Jun 94 15:21:50 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

[e-mail] writes:

>In article <[e-mail]>, [e-mail] (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         [e-mail]
- ------------------------------------------------------------
Overflight Software - Macintosh Games & Multimedia Programming

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (Malicious Monarch)
Date: Tue, 14 Jun 94 14:58:44 MDT
Organization: The Nile BBS

<<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.>>

   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 [e-mail] (Jon Wdtte)
Date: 15 Jun 1994 11:51:39 GMT
Organization: The Royal Institute of Technology

In <2tkmlv$[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

  "Practice random kindness, and senseless acts of beauty."

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 15 Jun 1994 11:53:11 GMT
Organization: The Royal Institute of Technology

In <2tkrd2$[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

  "Practice random kindness, and senseless acts of beauty."

+++++++++++++++++++++++++++

>From [e-mail] (Mike Callaghan)
Date: Wed, 15 Jun 1994 12:32:19 GMT
Organization: MV Communications, Inc.

In article <2t5bff$[e-mail]>, [e-mail] (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 [e-mail] (Ivan M CaveroBelaunde)
Date: Wed, 15 Jun 1994 15:42:51 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (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 ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 15 Jun 1994 16:11:31 GMT
Organization: Apple Computer, Inc.

In article <2tmq0b$[e-mail]> Jon W!tte, [e-mail]
writes:
>>In <2tkmlv$[e-mail]> [e-mail] (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 [e-mail] (Matt Mora)
Date: 15 Jun 94 16:55:18 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Michael A. Kelly)
Date: 15 Jun 1994 10:42:31 -0700
Organization: High Risk Ventures

In article <2tmq0b$[e-mail]>,
Jon Wdtte <[e-mail]> 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
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Michael A. Kelly)
Date: 15 Jun 1994 10:54:21 -0700
Organization: High Risk Ventures

In article <[e-mail]>,
Ivan M CaveroBelaunde <[e-mail]> 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
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Michael A. Kelly)
Date: 15 Jun 1994 11:10:23 -0700
Organization: High Risk Ventures

In article <2tnei7$[e-mail]>,
Michael A. Kelly <[e-mail]> wrote:
>In article <2tmq0b$[e-mail]>,
>Jon Wdtte <[e-mail]> 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
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 15 Jun 1994 16:49:30 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

 "My boss made me say it. He dares you to sue!"

+++++++++++++++++++++++++++

>From [e-mail] (Cyrus Harmon)
Date: Wed, 15 Jun 1994 11:51:11 -0700
Organization: UC Berkeley

In article <2tmq37$[e-mail]>, [e-mail] (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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lars Garden)
Date: 16 Jun 1994 13:33:13 GMT
Organization: Trondheim College of Engineering

Malicious Monarch ([e-mail]) 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: [e-mail]  IRC: Lynet
  \X/   "But I will rise and I will return like a phoenix from the flame."
         - Siniad O'Conner


+++++++++++++++++++++++++++

>From [e-mail]
Date: 14 Jun 94 14:22:46 MST
Organization: (none)

In article <2tkmlv$[e-mail]>, [e-mail] (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 [e-mail] (Amanda Walker)
Date: Thu, 16 Jun 1994 19:42:43 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

[e-mail] (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 [e-mail] (Dieter Shirley)
Date: Thu, 16 Jun 1994 19:49:57 GMT
Organization: Cognos Incorporated, Ottawa CANADA

Michael A. Kelly ([e-mail]) wrote:
: In article <2tmq0b$[e-mail]>,
: Jon Wdtte <[e-mail]> 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 [e-mail] (Yan Lee)
Date: 17 Jun 1994 02:11:39 GMT
Organization: Boston University

Amanda Walker ([e-mail]) wrote:
: [e-mail] (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 [e-mail] (Chris Burns)
Date: Fri, 17 Jun 1994 18:22:36 +1200
Organization: HyperMedia Unit, Auckland University

In article <2tnbpm$[e-mail]>, [e-mail] (Matt Mora)
wrote:

> In article <[e-mail]> [e-mail] (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: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Laurence Byrne)
Date: 17 Jun 94 14:17:16 GMT
Organization: Harvard University, Cambridge, Massachusetts

[e-mail] (Yan Lee) writes:

>Amanda Walker ([e-mail]) wrote:
>: [e-mail] (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        [e-mail]
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 [e-mail] (Jon Wdtte)
Date: 17 Jun 1994 20:30:07 GMT
Organization: The Royal Institute of Technology

In <2tnei7$[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

 "My boss made me say it. He dares you to sue!"

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 17 Jun 1994 20:34:55 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

 "My boss made me say it. He dares you to sue!"

+++++++++++++++++++++++++++

>From [e-mail] (John Lewis)
Date: Sat, 18 Jun 1994 07:04:43 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] 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  |
[e-mail] <- prefered    |Blue Skies to all skydivers.|text   |
[e-mail]      <- work        |USPA 87419, C-22826         |picture|
[e-mail]    <- rarely      |<Fnord>                     |comming|

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Sat, 18 Jun 1994 11:20:49 GMT
Organization: Best Before Yesterday

In article <[e-mail]>,
[e-mail] 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:          [e-mail]
Fax (UK):          (0570) 45636
Fax (US / Canada): 011 44 570 45636

+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Mon, 20 Jun 1994 17:06:08 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

In article <2tr0or$[e-mail]>, [e-mail] (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 [e-mail] (Amanda Walker)
Date: Mon, 20 Jun 1994 17:07:14 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

[e-mail] (Jon Wtte) 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 [e-mail] (Duncan Anker)
Date: 23 Jun 1994 09:33:53 GMT
Organization: Macquarie University, School of Mathematics, Physics, Computing and Electronics

Amanda Walker ([e-mail]) wrote:
: [e-mail] (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?

--
[e-mail] * Duncan Anker * [e-mail]

O.K. Scotty, real funny. Now beam down my clothes!

---------------------------

>From [e-mail] (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 <mysourcefile >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 - [e-mail] - Ottawa, Ontario, Canada
<A HREF="http://arpp1.carleton.ca/Grant/Grant.html">Grant Neufeld</A>
Apple Research Partnership Program, [phone] extenstion 3537
My views are too extreme to be anyone else's

+++++++++++++++++++++++++++

>From [e-mail] (Terry Gritton)
Date: Sat, 25 Jun 94 17:48:47 GMT
Organization: University of California, Santa Cruz

In Article <[e-mail]>, [e-mail]
(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 <mysourcefile >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 (<FILE>) {
  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 [e-mail] (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. ; <[e-mail]>;  908/932-3685
"Good work is always done in defiance of management."  R. Woodward

+++++++++++++++++++++++++++

>From [e-mail] (christopher weare)
Date: 21 Jun 1994 15:04:58 -0700
Organization: University of California, Riverside

In article <[e-mail]>,
Richard L. Peskin <[e-mail]> 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. ; <[e-mail]>;  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
[e-mail]



+++++++++++++++++++++++++++

>From Todd M. Morin <[e-mail]>
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.
[phone]
or via Compuserve mail (76344,251)

+++++++++++++++++++++++++++

>From [e-mail] (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
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (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 <[e-mail]>
Date: 23 Jun 1994 15:13:50 GMT
Organization: Univ of Wisc-Madison

In article <[e-mail]>
Bob Bradley, [e-mail] 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
[e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 23 Jun 1994 17:36:54 GMT
Organization: Apple Computer

Bob Bradley, [e-mail] 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 [e-mail] (Bob Bradley)
Date: Thu, 23 Jun 1994 10:11:21 -0800
Organization: Lightside, Inc.

In article <[e-mail]>, Jens Alfke
<[e-mail]> 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 [e-mail] (Jon Wdtte)
Date: 24 Jun 1994 08:36:40 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (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, [e-mail], Mac Software Engineer Deluxe --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi

---------------------------

>From [e-mail] (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!
[e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 24 Jun 1994 17:02:08 GMT
Organization: Apple Computer

Soetjianto, [e-mail] 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
**********************