Jump to content
A 2021 backup has been restored. Forums are closed and work in progress. Join our Discord server for more updates! ×
SoaH City Message Board

Proposal: 'Universal' sprite format for programmers


Recommended Posts

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=

Link to comment
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.

Link to comment
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=

Link to comment
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.

Link to comment
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=

Link to comment
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=

Link to comment
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!

Link to comment
Share on other sites

  • 1 month later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...