Path: utzoo!utgpu!water!watmath!dalcs!garfield!john13
From: john13@garfield.UUCP (John Russell)
Newsgroups: comp.sys.amiga
Subject: Re: Christmas questions cause considerable consternation
Keywords: IFF iff ARP.LIBRARY arp.library cheath
Message-ID: <4317@garfield.UUCP>
Date: 24 Dec 87 20:23:36 GMT
References: <4306@garfield.UUCP> <656@agora.UUCP>
Reply-To: john13@garfield.UUCP (John Russell)
Distribution: na
Organization: Memorial University of Newfoundland, St. John's
Lines: 67

In article <656@agora.UUCP> dmose@.UUCP (Dan Mosedale) writes:
>In article <4306@garfield.UUCP> john13@garfield.UUCP (John Russell) writes:
>:A NewPicture structure with pointer to rendering 
>:rastport or null if one should be created, pointer to newwindow structure if 
>:rendering should be done in a new window, constraints on size, # colours, 
>:viewmodes etc? Why not? Look for one Real Soon Now (right after I finish 
>:typing this all in :-). You know, I think I'll do that!
>
>This is an excellent idea!  Since IFF is fairly integral to the amiga,
>perhaps the above mentioned routines ought to be added into ARP.library!
>(Are you out there cheath? :)

Actually this is about the only project of any complexity that has caught my
interest so I was hoping to follow up with flexible, extensible code
examples. I jotted down ~250 lines of structure definitions, flag values,
and gave some thought to general outlines of functions; real code will have to
wait a little while, I'm finally absorbing those chapters in the RKM I just
skimmed before and want to finish before I start anything major.

I have no objections to someone else implementing the same idea, though. I 
would like to have some input if they do decide to go ahead with it.

The main points that have occurred to me are:

	- NewPicture structure containing pointers to display structures you
	  have created or NULL if they are to be created for you, and flags
	  giving a description of the actions you want performed during
	  picture manipulation
	- the routines I mentioned in my earlier letter could be controlled
	  by "master" routines like OpenPicture(), ClosePicture(), etc which
	  would use the NewPicture structure: much like OpenScreen() and
	  OpenWindow() save you from initializing the ViewPort, Copperlists,
	  and Layers
	- OpenPicture() returns Picture structure which you can examine and
	  use to call other manipulation routines
	- you specify which parameters are taken from the file, and which
	  file parameters you might override, through flags
	- each possible failure case (eg picture too big) can have an action
	  associated with it, whether it's "fail", "clip in a certain way", etc
	- when the picture is opened, the special actions that were taken such
	  as clipping or colour remapping are signalled by flags in the picture
	  structure; also such things as unusual viewmodes can be tested for
	  easily

Pictures would be considered as either disk-resident or ram-resident.
There would be routines for various types of operations on pictures that
were already displayed, such as saving, resizing, rotating, bending...
(sound familiar? :-). A global list of pictures would make it simple for
multiple programs using these routines to share rastports, swap (parts of) 
pictures, and so on. 

This ties in to an earlier idea, the idea of having rastports independent of
programs so that you could do some object-oriented plotting followed by
painting followed by image processing ad infinitum all on a globally-
accessible display structure. You could wind up with some killer images this
way!

If this were to be done as code to link into your own programs, another way
to make it flexible is to have sections dealing with, say, HAM mode left out
by compiling with a symbol like NO_HAM defined so that someone only concerned
with certain types of pictures or certain types of behaviour could still write
tight programs.

John
-- 
"...and intuition, in a case such as this, is of crucial importance."
			-- William Gibson, _Count_Zero_