Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi-s0.msi.umn.edu!srcsip!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!trantow
From: trantow@csd4.csd.uwm.edu (Jerry J Trantow)
Newsgroups: comp.sys.amiga
Subject: Re: A Sprite Editor?
Keywords: SPRITE EDITOR
Message-ID: <6653@uwm.edu>
Date: 28 Sep 90 13:35:38 GMT
References: <8615@helios.TAMU.EDU>
Sender: news@uwm.edu
Reply-To: trantow@csd4.csd.uwm.edu (Jerry J Trantow)
Organization: University of Wisconsin-Milwaukee
Lines: 67

n article <8615@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
>I am currently developing, of all things, a sprite editor.  The reason that I 
>began developing this program is to suit my own needs.  After seeing the
>existing software to edit sprites, I realized the following things:
>
>(1) There is no IFF standard for a sprite data file, although there is a
>    "SPRT" ID for the ILBM IFF spec.
>(2) There is no editor, to my knowledge, that allows creation of 15 color
>    sprites.
>(3) There is no editor, again to my knowledge, that allows the creation of
>    sprites with variable heights.  IE: Why waste space with NULL data because
>    of a set sprite height.  Or more importantly, why limit your sprite height?
>
>At this time, my sprite editor incorporates the following:
>
>(1) An special IFF file for sprites (similar to the 8SVX format for sounds.)
>(2) Support for sprites of varying heights.
>
>   Aaron Hightower.

What a coincidence, I was recovering from the death flu yesterday and was 
working on improving the animated 4 bit-plane, variable width/height sprites
found on FF364 under SNAG_Pointers and AniPtrs2.  This disk contains some
really nice animated pointers, but the IFF implementation needs improvement.
They are stored as follows

FORM
  ILBM
  [ATXT]
  BMHR   /* This isn't quite right, it's a BitMapHeader */
  CMAP
  BODY

Since the body contains multiple images, HEIGHT gets passed either as
a tooltype or a CLI arg.  The other ToolTypes are SPEED for cycling, XOFFSET,
and YOFFSET for the hotspot.  I am trying to improve this implementation
by changing the XOFFSET and YOFFSET into a GRAB chunk and GRAB ToolType.
I am also adding the SPRT chunk.  According to the old Exec manual there is
an old chunk CCR? (color cycle registers) that I was thinking of adding to
hold the cycle speed information.  If I used the BitMapHeader.x field to
hold the height, all the information could be encapsulated in the current
definitions.  The improved IFF file looks like this:

FORM
  ILBM
  [ATXT]
  BMHR?  /* whatever the ID for a BitMapHeader is */
 *GRAB
 *SPRT
 *CCR?   /* whatever the GraphicCraft color cycle ID was */
  CMAP
  BODY

This is a bit of a hack because the BitMapHeader.x field and CCR??? chunk
were not meant to be used this way.  I almost forgot, I also need to store
the priority of the task that spins the pointer.  Maybe it would be better
to define a new chunk that would hold the sprite height, number of images,
time between images, and priority of image cycling.

Has this been done already?  (I'm in the process of getting the IFF disk 
off the FF disk)
_____________________________________________________________________________
Jerry J. Trantow          |Here the ways of men part; if you wish to strive  
1560 A. East Irving Place |for peace of soul and pleasure, then believe;   
Milwaukee, Wi 53202-1460  |If you wish to be a devotee of truth, then inquire.  
(414) 289-0503            |                               Nietzsche 
_____________________________________________________________________________