Sign in to follow this  
Followers 0
Smidge204

Proposal: 'Universal' sprite format for programmers

12 posts in this topic

http://smidge204.homeftp.net:84/SIF_File_Format.html

Wow, it's been two YEARS since I first came up with this. Where does the time go?

Anyway, this is Version 2.0 of my "Sprite Image Format" (*.SIF) file format specification. Originally, it was just a data file that my CCA file sprite ripper utility used to save animation data from te sprites it ripped. A few months later it evolved into version 1.0 with a standalone sprite editor I wrote that supported it.

Wanting to start a project that actualy uses the SIF data format, I decided it was inadequate and could be improved... so now it's version 2.0 - a pretty significant change from the previous.

The idea was to create an open and well documented sprite format that could be used in many projects, allowing for the creation of a library much like the collection of Clickteam-based sprites we have now.

Input and criticism from people who 'roll their own' is appreciated!

=Smidge=

Share this post


Link to post
Share on other sites

My current system is quite similar to that, but is based on XML because I found it to be more flexible, and also easy to write by hand. It also makes it easier to add new things to the spec without breaking all existing data.

Images are stored seperately, and all animations and objects have names in a namespace style format, such as "Game.Objects.ObjectName.Resource" so it's easier to read and maintain.

Animations specify what image they use, as well as how many times it should loop (if at all) and what the default speed is. Each frame of the animation states what image frame it uses, what direction (left/right) and angle (0 to 359) it uses as well as how long it will be displayed (in milliseconds). The main reasons for including the angle were speed/prettyness (not all images rotate nicely programatically) and because it sounded like a good idea at the time. I've not run into any major problems yet, so it still seems like a good idea.

The SIF format looks quite robust, and I can't see any problems with it, although they might come to light once it's been used by a few projects.

Share this post


Link to post
Share on other sites

A good way would be edit it using XML data, and then compile it to binary.

Maybe it could even be converted to MMF format or something, if we could reverse engineer it.

Share this post


Link to post
Share on other sites

XML is overated and bloated, IMHO. The SIF format does not have nor require "rich formatting" for presentation. It also does not lend itself to inclusion of binary data, which must be encoded or reference external files (breaks encapsulation). There is also additional overhead for parsing which can be completely avoided. XML is great when used for what it was designed to be used for, but I don't plan for kludge my data into a format that isn't designed to hold it just because it's trendy.

I have already reversed-engineered the MMF 1.2/1.5 CCA file format enough to extract image and animation data - that's actually what inspired the initial draft of this format. I haven't tried to create CCA files yet, though... and MMF2 files might prove difficult.

=Smidge=

Share this post


Link to post
Share on other sites

I used XML because it was the quickest and easiest way to get something working, not because it's trendy. The parsing overhead isn't a major problem as far as I'm concerned, and I wasn't bothered about encapsulation. It's not the greatest solution by any means, but it does the job. Perhaps in future I'll switch to a completely binary solution, but for now it's just extra work that I don't need.

I'd be more than happy to write a .SIF parser for Blitz once you get an example file online to play with.

Share this post


Link to post
Share on other sites

I'm developing a SIF editor now, based on the current specification. Might have a bit of trouble getting PNG support in VisualBasic though :P

Also, I'm going to explicitly detail how RLE compression is implemented since there is no standard way to do it.

=Smidge=

Share this post


Link to post
Share on other sites

It looks neat enough, but show me words like WORD, BYTE, and DWORD in person and I will make you go AGHHHHHHHHH until you convert it to good ol' standardness. ;)

Share this post


Link to post
Share on other sites

Those ARE standards. If you are referring to "Char," "Int" and "Long" -- those are not standards.

=Smidge=

Share this post


Link to post
Share on other sites

I mean like "unsigned 32-bit" kind of standards. In the One True Lingo, a "word" happens to be whatever the processor takes natively (that is, 16 bits on 8086, 32 on 386, 64 on ppc64, etc.).

Share this post


Link to post
Share on other sites

That's odd, 'cause on 386/486/Pentium & Compatable chips, WORD is still 16-bit and DWORD is 32-bit (QWORD would be 64-bit) Same on Z80 and 8051 micros. I know the Motorola 68k used "long-word" instead of DWORD but that's the only exception I'm aware of.

Can't speak for PPC though.

=Smidge=

Share this post


Link to post
Share on other sites

Well, it reeks of MSVC-style code anyways. Obviously Microsoft wouldn't change the size of their all-caps types (because breaking working code like that is stupid). But the "int" type is supposed to be a word, which varies from processor to processor.

Oh, and I didn't even touch the endianness issue.

EDIT: grrr I was going to set about implementing a libsif, but the system is down!

Share this post


Link to post
Share on other sites
I haven't tried to create CCA files yet, though... and MMF2 files might prove difficult.

=Smidge=

Dont use the MMF2 format, just make CCA files, as MMF2 can open them.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0