Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Intuition's "dont mess with these" fields...
Message-ID: <33492@sun.uucp>
Date: Tue, 10-Nov-87 14:24:44 EST
Article-I.D.: sun.33492
Posted: Tue Nov 10 14:24:44 1987
Date-Received: Thu, 12-Nov-87 23:37:12 EST
References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 53
Keywords: Intuition verboten nopokenzefields

[ I'll try and edit it alot, for more context track down the references ]
Keith = >
My original comments = >>

>>One of the problems with 'overscan' is that not all monitors can handle
>>it. 
>Except when I'm playing back IFF ShowANIM files, the overscan mode is 
>explicitly defined.  I open up a screen of whatever size is specified
>in the IFF file.  If the users monitor can't handle it, he'd better get
>a new monitor or throw away his copy of Videoscape 3D.  I do not hard-code
>screen sizes anywhere in my application, they are defined by the IFF picture
>and ANIM files specified by the user.

And at least one user I know of has 'thrown away' (actually taken it back)
his copy of V3D because the pictures went off the edges of his TV (he doesn't
have a monitor yet and he was quite irritated that Aegis expected him to buy
one.) You should not hard code the maximum screen size in your code, you
should simply check GfxBase -> NormalDisplay[Rows|Columns] before you open
a screen. If it won't fit, then warn the user that it won't fit and explain
in the manual how morerows can increase that limit on 1.2 systems. 

>>For pre-1.2+ systems you supply morerows ( which last time I checked was
>>freely redistributable) and explain to the user how to set up the maximum
>>screen size that they are comfortable with on their monitor. 
>Assuming he only wants to work in one resolution, which is not a very
>good assumption.

No, the Assumption is you can always safely open a screen that is smaller
than the workbench. You cannot always open one that is larger and expect
it to work. All the user has done with morerows is told you "I can't see
pictures that are bigger than my workbench". If you have one that is larger
than that you *know* it won't be displayable on the system. 

>Even this wouldn't help with my application.  You can mix resolutions as
>you please, including overscan with non-overscan images.  100% dynamic.
>Should I force you to convert your overscan workbench to non-overscan
>while you run certain animations, but not when you run others?  Doesn't
>sound very user-friendly to me.

No, No, and again No. If the image is overscan and larger than the 
screen size the User has defined, then you should warn him that this
image cannot be displayed on his monitor. That is much friendlier than
having him get pissed off because *your* program chops off the bottom/side
of the images. The guy I mentioned above has lost mucho respect for
Aegis because they *assumed* he had a monitor, and that it handled overscan. 
If the Animation doesn't run in overscan mode then just open a non-overscan
screen and run it, or run it in an overscan screen and leave the borders alone.
In either case you win, your compatible, the user likes it, and your code
still works under 1.3.  

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.