Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!elroy!mahendo!jplgodo!wlbr!scgvaxd!trwrb!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Re: Intuition's "dont mess with these" fields...
Message-ID: <1864@cadovax.UUCP>
Date: Thu, 12-Nov-87 17:27:49 EST
Article-I.D.: cadovax.1864
Posted: Thu Nov 12 17:27:49 1987
Date-Received: Sun, 15-Nov-87 07:35:50 EST
References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP>
Reply-To: keithd@cadovax.UUCP (Keith Doyle)
Organization: Contel Business Systems, Torrance, CA
Lines: 89
Keywords: Intuition verboten nopokenzefields

In article <33492@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>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.) 

Wait a minute!  The're SUPPOSED to go off the edge of your TV.  That's the
whole point of OVERSCAN.  Why do you think they call it OVERscan?  Only if
his monitor loses sync because of it could it ever be an issue.  And in
fact, you stress my point.  If the user want's to produce full overscan for
his videotapes, but his monitor cuts off much of it in that mode, I for
SURE don't want to force him to have to put his workbench in that mode
where he won't be able to find his menu bar, just so his videotapes will 
come out right.  If the images go off screen in VideoScape, then why doesn't
he just zoom back the camera position a bit making the whole image a little 
smaller?  I mean, what's the problem?  The VideoScape option screen is
640x200 normal screen just like it should be.

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

Except that if a user want's to do 704x464 full video in the application,
requiring him to set his workbench to that mode could get pretty unwieldly,
not to mention he's likely to eat up much of his valuable chip ram as well.

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

Why should I make that assumption?  The *user* decides where he should set
his workbench, and what kind of images he wishes to display.  Why should
I make him work with a 704x464 workbench (where he might not even be able
to see his menu bar) when he wants to run an application that does an image
for video where the 704x464 is important?

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

But if the result is to be videotaped, even if you can't see it all on the
monitor you have, you may still want to be sure that the video is coming
out full screen.

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

If he doesn't want to see images that get chopped of because they are too
big, he can decide not to create such images with DPaint.  You're
suggesting I pop up a requester that says "warning: use morerows to make
your workbench too big to be used" when a user tries to playback a VideoScape
ANIM, when he's got a normal workbench, and a small monitor?  Or I suppose 
I could do some kind of dynamic re-sizing of the image to force it to 
workbench size?  If you think writing a ShowANIM player is messy when they're 
changing the specs once a week, see how you like it when you try to readjust 
the screen resolution on the fly to boot.  (can you say S L O W ?)

>The guy I mentioned above has lost mucho respect for
>Aegis because they *assumed* he had a monitor, and that it handled overscan. 

Well I don't assume that.  But I don't assume he doesn't either.  This is
the first I've heard of such problems, even my home TV can handle it as
can my VCR.  I'd be inclined to think his monitor's broke if it loses sync,
and if he's just complaining about the size of his TV, well, the normal 
workbench won't fit its 80 columns on one old TV I have, but did I blame Amiga?
Nope, I resized my workbench window.  If doesn't work for him, all he has to 
do is create images as big as he CAN work with in DPaint (or wherever), it's 
totally up to him.  And I won't make him size his workbench to that if it's 
OVERSCAN which is *supposed* to extend beyond the edges of the viewable screen.

>If the Animation doesn't run in overscan mode then just open a non-overscan
>screen and run it,

Doing this on the fly with IFF ANIM's would slow down a process everyone
is counting CPU cycles trying to find ways to speed up.  And actually, with 
my package you CAN do that if you really want.  You can triple (or is it 
quadruple?) buffer a ShowANIM and cut a smaller screen out of it that fits 
on what you have.  Not terribly elegant, not at all automatic, but it can be 
done for that 1% of the market out there who couldn't afford a decent monitor.
I mean, jeez, C= was giving the monitors away free in the early days (package 
deals), and I've got one of those and it works just fine.  Tell your buddy
to get a job!

Keith Doyle
#  {ucbvax,decvax}!trwrb!cadovax!keithd  Contel Business Systems 213-323-8170