🚀 go-pugleaf

> You seem to have missed the point; what is important is not
> flexibility for manipulation and calculation so much as flexibility
> for interchange.  This is to be an _Interchange_ File Format, so it
> should be designed for maximum transportability.  Regardless of the
> usefulness of floating point numbers, extra code is required to handle
> them.  No sense in forcing a program which would use fixed point to
> handle floating point for the IFF file when it has no other use for
> floating point.  It's sort of like creating an IFF format which uses
> EBCDIC for text because you want to be creating the data on an IBM
> mainframe -- sure, it's more convenient, but less workable, in the
> long run...

Let me turn your argument around - 'No sense in forcing a program which
could use the extra precision of IEEE floating point to lose it'
It is not AT ALL like using EBCDIC; IEEE is a mandated standard,
vis the name.  It holds across a variety of architectures and
operating systems, at least as much as two's complement fixed point
integers.

> Integers certainly ARE more natural than floating point, from the
> perspective of the processor -- the 68000 certainly can't deal with
> IEEE as easily as fixed point...  Yes, you can compile in the IEEE
> code, but it increases code size and complexity, which is an
> undesirable consequence if the program has no use for floating point
> internally...

How would your argument change if you were talking about a 68020/68881
system?  A 68040 with on-chip floating point?  An 8088/8087 system?
For the latter, I suspect that single precision IEEE floating point
is MORE natural than 32-bit fixed point integers.

Here's a little routine to convert IEEE single-precision floating point
numbers to a fixed-point representation given the position of the
decimal point (in bits).  It took about 5 minutes to write.  It uses
NO floating point arithmetic.  It compiles to around 200 bytes of object
code.  It *is* a little compiler specific wrt the bit order of bitfields,
but that's easy to massage.  It wouldn't be any harder to write the
inverse transformation:

	typedef union {
	    struct {
		unsigned int	Sign :  1;
		unsigned int	Exp  :  8;
		unsigned int	Mant : 23;
	    }
		Bits;
	    long
		Long;
	} IEEE;


	long ScaleIEEE( val, mag )
	long val;
	int mag;
	{
	    IEEE num;
	    unsigned long base;
	    long res;
	    int nshift;

	    num.Long = val;
	    if( num.Long == 0 )		return 0;

	    base = 0x800000;		/* Implicit leading '1' */
	    base |= num.Bits.Mant;	/* Get entire number */

	    /* Calculate amount to shift: excess 127, 23 bits precision, */
	    /* plus scale factor */
	    nshift = ((int)num.Bits.Exp) - 127 + mag - 23;

	    /* Shift it: left or right */
	    if( nshift < 0 )	res = base >> -nshift;
	    else		res = base << nshift;

	    /* Add in the sign */
	    if( num.Bits.Sign )	res = -res;

	    return res;
	}

There.  Was that so bad?

(regarding layers)
> I'd also suggest using PROPs in a LIST -- more "IFF-like"...

I think here you're going overboard in the IFF philosophy.  I think
it is much easier to parse the file without all that extra LIST, etc.
clutter around.  I agree about the nested object stuff, but the
layering seems so much simpler as a 16-bit ID for each object.

> Please bear in mind that these bits of data (DSYM, XTRN, etc.) have no
> meaning beyond the context of the FORM DR2D, and that FORMs are a
> top-level construct.  Apart from the general undesirability of
> cluttering the FORM namespace, you would have little use for an IFF
> file consisting solely of FORM XTRN, ne?

Oops.  You're correct.  How about:

		FORM {
			DR2D
			DRHD {
				...		-- various drawing attributes
			}
			...			-- root level objects
			FORM {
				DR2D
				GRUP {
					...	-- various group attributes
				}
				...		-- grouped objects
			}
			...
			FORM {
				DR2D
				XTRN {
					...	-- various extern attributes
				}
				...		-- grouped objects
			}
		}

and so on.  It would be nice if there was some requirement that the
GRUP, XTRN, etc. chunks be the first ones in their forms, but I'm
not sure that IFF allows any mandates like that.

I still haven't gotten a chance to look at FTXT.FONS; I'll do that
and report later (I do have the Commodore IFF document).

> Deven

				Ross