[comp.sys.amiga.tech] Intuition questions

jimm@amiga.UUCP (Jim Mackraz) (06/29/88)

In article <709@pdp.cs.OHIOU.EDU> arp@pdp.cs.OHIOU.EDU (John Gordos) writes:
)	I would like to do something similar to the "lines" demo on the 
)standard workbench; but it seems to have a larger raster than the window. 
)This has started me thinking, so I have some general questions concerning
)Intuition that I haven't seen addressed anywhere, and I'd appreciate some
)enlightenment. 

You are interested in SUPERBITMAP windows.  See the Intuition Reference
Manual.  Koan: all superbitmap windows must also be gimmezerozero.  

)	Just what is a window?  

You ask a very deep question.  It can have no answer.  The Window is
the misunderstood and the undefined.  It is everything, yet nothing
at all.

)	Is it a viewport? 

I can tell you this: It is not a viewport.

)Can I do many of the same things to a window that I can to viewports?

What would you do?

)Can there be multiple resolution
)windows on a Screen, or is a screen more like a viewport?

No.

)Can you give a window
)a larger raster than will appear inside the window? It would seem that you can,
)I was concerned about the "correct" way to do it.

SUPERBITMAP.

)   Any and all help along these lines would be appreciated.

            ^^^ -- not so sure about that anymore, are you? 

)John A. Gordos, III					cbatt!oucs!arp

OK, I'll try a little harder.

The World has two halves: rendering and video.  The world is centered
around the bitmap.  The rendering side of bitmaps is managed by
a RastPort.  The video display side is a ViewPort.

A RastPort/ViewPort pair, together with a single bitmap, is presented
to the Intuition programmer as a Screen.

Screens don't (yet!) do everything you can do with a ViewPort: they
don't scroll so well, but they do drag up and down (and around?),
determine their own independent resolution, depth, and color pallete.
Viewports themselves represent a small subset of the video effects
you can program the Amiga display hardware to do.

Viewports are implemented by beam-synchronized reloading of the display
controller register by the display coprocessor, or Copper.  They
take a couple of scan lines to set up, which explains why they are
always horizontally separated, not vertically.

Rendering through a screen rastport is highest performance.  It
undergoes no clipping.

Underlying Windows are Layers (managed by the rather incredible Layers
library).  Layers provides clipping and a depth arranged rectangular
region metaphor.  Clipped rendering is done through a RastPort
associated to a Layer (or Window) rather than a Screen.  Layers library
manages obscured bitmap save areas, large "superbitmaps", and presents a
metaphor of independent rendering regions.  

As an end result, the visible portion of rendering done to the layers
is affected in the contiguous bitmap associated with the Screen
containing the Layer or Window.

Superbitmap layers are an extension of the visible/obscured region
clipping using a separate, contiguous bitmap. This bitmap can be
kept in sync with rendering which modifies pixels in the onscreen
bitmap, the obscured save areas, and the portions of the
superbitmap beyond the logical boundaries of the window.

The Superbitmap window "scrolls" by the copying of data from the offscreen
bitmaps.  This is done by the blitter, and has nothing to do with
the display coprocessor or controller hardware.  It is a trick.
Bits are being copied around, rather than pointers changed.

Fools some of the people some of the time.  But one thing that
the Amiga does NOT do (yet) is perform display controller changes on 
vertical seams, which is sometimes called "hardware windowing."

Intuition Windows are basically Layers plus an input path and activation
metaphor.

And some other stuff.

Oh yeah, GimmeZeroZero windows are two layers each, and getting better
all the time.

	jimm
-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.

peter@sugar.UUCP (Peter da Silva) (06/30/88)

Thank you, Jimm. That was a very Zen discussion, and it illuminated certain
aspects of the Amiga that I have been in the twilight about. It's just how
you look at things, I guess.

Now, on to the meat. Here are some of those nasty "what" and "when" queries.
I don't expect answers, but it'd be nice:

(1) So, will we be seeing hardware windows in the Amiga?

(1a) When?

(2) Is there currently work being done on a hardware independent graphics
    library?

(2a) Does it emulate the blitter?

(2b) When can we expect to see it?

(3) What about the rumor of AMigaDOS and UNIX concurrently at some trade show?

(3a) How much of a bozo am I for giving it any credibility?
-- 
-- `-_-' Peter (have you hugged your wolf today?) da Silva.
--   U   Mail to ...!uunet!sugar!peter, flames to /dev/null.
-- "A foolish consistancy is the hobgoblin of little minds".

cmcmanis%pepper@Sun.COM (Chuck McManis) (07/03/88)

In article <2239@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
> OK, when will we have horizontally stackable screens?

It's less obvious when Peter is being sarcastic than it is when Tom is
being sarcastic. I assume Peter wasn't serious when he said this because
if he knew anything about Amiga Video, and he seems to, he would know it 
is impossible. 

To change a screen you need to change The colormap and the bitmap 
pointers. even if both screens were 1 bitplane the best resolution
on placement would be something like 64 pixels. The best way to get
a horizontal "screen" is to lay all the sprites side by side. Then you
can have one 128 X n X 2 lo-res screen that is draggable horizontally.
(Oh but you lose the mouse pointer, so you maybe want to keep to a 112
pixel wide low resolution "screen")

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

trh@lexicon.UUCP (Tom Hegg) (01/06/89)

Many thanks to the people who sent responses to my last
set of questions.  Now I've got a few more - mostly about
Intuition:

    1.  There is no support in Intuition for drawing
	an Image structure in something like "COMPLEMENT"
	mode for IntuiText.  I COULD use DrawImage() and
	then something like DrawRect() (I forget the name)
	in COMPLEMENT mode, but this would probably flash
	the display.  I would prefer to use the graphics
	functions to take the same data from my Image
	structure and draw it in whatever mode I like,
	but I can't find any simple graphics function(s)
	to do this.  (Do I have to use QBlit?).

    2.  I would like to make a "fader" Gadget that looks a little
	bit more interesting than the ones I've been able to
	get Intuition to produce.  I already have my own knob
	image, but it still has a bland	looking border
	around the select box and I can't seem to put any pattern
	in the slider area (the knob will just erase it).  While
	I'm usually against comparing, the M*C programs I've seen
	usually have more aesthetically pleasing proportional gadgets.
	Any suggestions?

    3.  Is there a "canned" function to print the screen to
	the printer somewhere?  If not, any PD source examples?

Thanks for any help ....

-- 
Tom Hegg
{harvard,linus,ima,bbn,m2c}!spdcc!lexicon!trh

olva@geocub.UUCP (Olivier Vayssettes ) (01/09/89)

>    1.  There is no support in Intuition for drawing
>	an Image structure in something like "COMPLEMENT"
>	mode for IntuiText.  I COULD use DrawImage() and
>	then something like DrawRect() (I forget the name)
>	in COMPLEMENT mode, but this would probably flash
>	the display.  I would prefer to use the graphics
>	functions to take the same data from my Image
>	structure and draw it in whatever mode I like,
>	but I can't find any simple graphics function(s)
>	to do this.  (Do I have to use QBlit?).

    What do you want do to? You cannot draw an Image complementing
    the background because you erase it. It is not the same as printing
    text or drawing lines,etc. The only way to do this is to use a 1
    bit plane image that will not be drawn on the background, but will
    be used as a pattern for complementing. This is not possible with a
    built-in function so, you will have write your own. But you are not
    obliged to use QBlit (unless if you want your function to be very fast)

    If you want to avoid flashes while drawing, try WaitTOF() just
    before drawing.

>    2.  I would like to make a "fader" Gadget that looks a little
>	bit more interesting than the ones I've been able to
>	get Intuition to produce.  I already have my own knob
>	image, but it still has a bland	looking border
>	around the select box and I can't seem to put any pattern
>	in the slider area (the knob will just erase it).  While
>	I'm usually against comparing, the M*C programs I've seen
>	usually have more aesthetically pleasing proportional gadgets.
>	Any suggestions?

    I had this problem too. There is no way to avoid erasing the background
    while moving the knob. I tried a solution consisting in waiting
    MOUSEMOVE messages, and after each one, re-drawing the background. 
    But the result was not very good. The only solution I found until now
    is creating a pseudo-gadget whose knob is a simple sprite (not VSprite).
    This requires some mouse clicks and movement managing and is not really
    equivalent to a real gadget but it is the less bad solution.

>    3.  Is there a "canned" function to print the screen to
>	the printer somewhere?  If not, any PD source examples?

    What does "canned" mean? (I am french, nobody's perfect :-) ). You can
    print an Image with DPaintII but if you want to print a workbench
    screen... I have been told about a function that does this, but it is
    very long. I will contact you when y have more information.

				Olivier Vayssettes
				Universite de Bordeaux, France

dbk@teroach.UUCP (Dave Kinzer) (01/25/89)

   So, how high is a window title bar anyway?  It appears to be the font
height plus 2.  Is this always going to be valid, or is there another place
to get the bar height?  [Nice article on fonts in transami, Betty.  I'm
trying, I'm trying.]

   If anybody can point me in the direction of a good public domain file
requestor I'd be most appreciative.  Also, a pallette requestor too (4 color
2 bitplane would be nice, but anything with source can be changed to work).

   Thanks all!


|    // GOATS - Gladly Offering All Their Support  Dave Kinzer (602)897-3085|
|   //  >> In Hell you need 4Mb to Multitask!  <<  uunet!nud!fbog!dbk       |
| \X/   #define policy_maker(name) (name->salary > 3 * dave.salary)         |

jesup@cbmvax.UUCP (Randell Jesup) (01/26/89)

In article <10036@teroach.UUCP> dbk@teroach.UUCP (Dave Kinzer) writes:
>
>   So, how high is a window title bar anyway?  It appears to be the font
>height plus 2.  Is this always going to be valid, or is there another place
>to get the bar height?  [Nice article on fonts in transami, Betty.  I'm
>trying, I'm trying.]

	Look at the window structure, it has what you want (all the border
widths).

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup