aaron@stat.tamu.edu (Aaron Hightower) (09/28/90)
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.
I have other ideas that I would like to implement, but would not be necessary
for the purpose that I have in mind. The editors I have seen have appeared
inadequete for some needs.
Please, I need your suggestions; programmers, what kind of functions do you need
in a sprite editor?
Please send all responses via mail to: aaron@stat.tamu.edu
The final product will be released to ShareWare.
Thank you for your support,
Aaron Hightower.trantow@csd4.csd.uwm.edu (Jerry J Trantow) (09/28/90)
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 _____________________________________________________________________________
peter@cbmvax.commodore.com (Peter Cherna) (09/28/90)
In 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: >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. Please consider using an IFF ILBM for external storage of your sprite. That way if your editor was missing a feature that existed in a Paint package (I dunno, maybe gradient fills, or perspective operations) then the sprite could be edited in (say) DPaint and then loaded into your editor to be saved as the sprite (I don't know what you spit out, if it's source code or if you set the pointer with SetPrefs()). Note that in 2.0, the pointer preferences are stored as an ILBM. > Aaron Hightower. Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "Very strange... the window is broken on both sides."
jimm@amiga.UUCP (Jim Mackraz) (09/29/90)
In 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.
Kind of makes it difficult to tell if my thoughts apply to your situation ...
)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.
I recommend using brush .ilbm's. This is the approach used in V2.0.
That's to specify the *system* pointer sprite. You might have other
needs if you're designing sprites for an application program's direct
use, such as animation. I'd recommend trying to go with the
AnimBrush format in that case, whatever that is. Note that the sprite hotspot
is encoded as the brush GRAB item, and you can set that easily in DPaint III.
You can basically ignore the "transparency" stuff, since you don't really
have a choice in it, but set the right bits if you *write* "sprite brushes".
)(2) There is no editor, to my knowledge, that allows creation of 15 color
) sprites.
Actually, most people use a brush-to-sprite tool, I think, so DPaint
creates 15 color sprites just fine.
)(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?
Again, brush-to-sprite doesn't screw with these. Are you trying to make
a sprite editor for users, to replace the preferences editor? Or are
you trying to make a developer's tool. If the former, I recommend you
look at V2.0 for comparisons. It has a nicer editor, and also supports
clipping a brush out of DPaint and saving it to ENV:sys/pointer.ilbm
for instant change to your system pointer (using V2.0 file notification).
For the developer, I think tools which work with ilbm's are the best.
Some sprite animations (position or movement direction changes) MIGHT
be doable by snipping the multiple frames out of a large grid-mapped
ilbm painting. I'm looking forward to using a little ray-traced
15 color image as my pointer under V2.0.
(Note: 15 color sprites are "not supported" under V2.0 because there
are a lot of limitations and uglinesses that can arise. Thus, you
won't see a 15 color sprite editor, but the system *will* accept
deeper .ilbm's and give you a 15 color sprite, if you can live with
the glitches.)
)At this time, my sprite editor incorporates the following:
)
)(1) An special IFF file for sprites (similar to the 8SVX format for sounds.)
NAK, unless you can identify reasons that ilbm or anim won't work.
)(2) Support for sprites of varying heights.
No big deal, if you use brushes.
)Please, I need your suggestions; programmers, what kind of functions do you need
)in a sprite editor?
Sprite animation. Multiple frames, not necessarily a linear sequence.
Types of sprite animation I can think of:
1) Time sequence: sawing wood, turning gears, clocks that tick
2) Position map: different pictures for odd and even positions, or
for positions modulo some number larger than two. Little guy
who walks around when he moves, for example.
3) Direction dependent: different images for movement to
the "north", "southeast", and so on.
4) Combinations of 1-3.
)Please send all responses via mail to: aaron@stat.tamu.edu
Oops, sorry.
)The final product will be released to ShareWare.
)
)Thank you for your support,
) Aaron Hightower.
All the best,
jimm
--
-------------------------------------------------- - opinions by me
"I've got great news. That gum you like is going to come back in style."
-the man from another place