Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ncar!noao!mcdsun!mcdchg!amtfocus!jeffle
From: jeffle@amtfocus.UUCP (Jeff Leitheiser)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A modest proposal (was IFF/Quickdraw)
Summary: Lets make it expandable
Keywords: PostScript
Message-ID: <134@amtfocus.UUCP>
Date: 23 May 88 19:52:20 GMT
References: <4083@gryphon.CTS.COM>
Organization: Motorola Inc. GSG/AMT, Schaumburg, Illinois
Lines: 112

In article <4083@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
> 
> In article <53552@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
> >In article <132@amtfocus.UUCP> jeffle@amtfocus.UUCP (Jeff Leitheiser) writes:
> >> I agree that there NEEDS to be ONE standard for storing semi-intelligent
> >> graphics....is postscript the answer? I'm not an expert on postscript,
> >> but what about 3D objects? Yes, most of what people do today is 2D, but
> >
> >Whoa! There are several problems here that everyone is trying to solve
> >with *one* solution. (You may recall during the IPC discussion the same
> >phenomena occurred). The two big ones in Jeff's message are "rendering
> >to the screen" and "storing object definitions".
> >
> >Rendering to the Screen :
> >
> >The Amiga screen rendering routines are raster based and fast. This 
> >works well with the screen because they operate at the full resolution
> >of the screen. This is not true for printers because chances are that
> >the routines do *not* work at the printers resolution. Apple's solution
.
.
.
> >the problem is to provide a set of graphics calls that can be directed
> >at *any* device and they will render on that device at the maximum 
> >resolution of that device. The sub problems come in the form : Are these
> >commands or are they simple values? Can you define the appropriate
> >subset of commands that give you the require capabilities? etc.
> >
> >PostScript was suggested as the drawing language but in case you haven't 
> >noticed, even Apple doesn't use native PostScript on the Macintosh because
> >it cannot be rendered quickly enough. So the goal becomes to come up with
> >a flexible drawing language that can be rendered quickly, but contains
> >sufficient flexibility that most (where most is arbitrarily set to 85%)
> >of the things you want to render, can be, without resorting to 'going
> >around' the language. NOTE : For screens and printers etc two dimensions
> >are sufficient. 
> 
> Thank god. Somebody else understands this too.
I agree that most instances of graphics are simple, and 2D....most usages 
are too. In those cases only simple commands will do nicely. What I'm afraid
of is the simplicity of these files will cause MANY dedicated storage formats
to be developed and all of them being incompatable. The example of Apollo's
domain 2D and 3D graphics formats was brought up as in support for seperation.
I think its better for the inclusion argument:
     - different naming conventions.
     - locations in 2D are in frations-of-bitmap vs 3D's logical device coord.
     - different color definition methods
     - 3D supports only 1 font 
Why are they different? Why can't you build one format and let it be extendable
to include other types of information? an example of this type of format is
IGES or EDIF. Both of these formats are clumzy, but they have entity types
such as 2d_strings , 3d_strings, sub_figure_def and sub_figure_loc that can be
used or ignored by a client program. Later additions come in the form of new 
entity types, these are not supported and therefore not used by older routines.

> For inclusion into IFF files, I propose that types (or hunks or whatever
> the appropos terminology is) be invented that correspond directly to
> PS primitives. What we end up with then, is essentially Amiga quickdraw,
> except we dont call it quickdraw.
> 
I agree, we should define a header file that maps entity types to integer valuesso that a select case statement can easily be used to seperate the usage     
code blocks.....the default will catch the unknown entity types if you want to
report/log them. I think the entity type should be stored in the front of the 
entity description so the rest of the entity doesn't need to be parsed if you
can't understand or want to ignore it.
This does mean that a simple interpreter/reformater will always be needed to
keep other devices from barfing ( stripping/expanding higher level entities,
 adding the postscript entity type text to the end of the string, and scaling
 the stored ( compressed to scaled integer ) locations to the proper size.
 The format of all the interpreters will be the same shell with unique code
 to render the graphic primititives to the device. This also allows the 
 reduction of 3D to 2D: ignore an axis for any on std view or use transform
 equations for special angles.
  
> If you look at the trend in peripheral, over the last 10 years, and
> where the peripherals industry is going, you will notice that more
> and more intelligence is being built into peripherals, and this
> is especially true of printers.

By first writing a generic interpretter, new device drivers become a simple
matter of "what do I send it to do this". If the device has new features
we can add support for them with a new entity type. Older drivers can then be
easily retrofitted with a new case clause for the feature. Note that other
graphical standards can be looked at as devices, It would be easy to write an
IGES or CGM format converter.
  
> If there were any NAPLPS or CGI/CGM or what have you peripherals,
> that "spoke" these standards, they might be worthy of consideration.

I wrote a graphics displayer for a CGI graphics card for a VME system,
It was nice to off load the main CPU but there is very little feedback
for when the graphics were ready....impossible to do some of the current
Amiga twiddles. Also there is no support for rendering multiple copies of
an object without actually coping the full object description.

> >Storing Objects and such :
> >
> >This is the area that Jeff expounds upon and I agree it could use some
> >standardization. The Videoscape 3D and Sculpt 3D people seem to have 
> >the most to gain at the moment however all of us would benefit if one
> >3D object specification format existed. Jeffs 'scaled' integers is an 

I'm glad you agree. The time savings are just as true for 2D objects. If I
take my storage scaling factor and multiply it by my display scaling factor
I then get an int * int (+ int offset ) operation for finding pixel locations.
What could be faster and still resolution independant?

> One thing at a time please. It's much easier that way.

One final implementation at a time......but lets keep an eye on the big picture.If we need to create a format lets try and make it short, fast, and expandable.

Jeff Leitheiser (312) 576-0836       chinet!mcdchg!amtfocus!jeffle