"re-ripping" sprites; quest for a common description format

Apprentice
Posts: 5
Joined: 2008.12
Post: #1
Hi everyone! I'm new to the forum. I signed up here in fact just so I would have a place to ask these questions!

There is a lot of game art out there. I'm going to be talking about orthogonal 2D game art specifically. So-called "sprites." Those two-dimensional, often having small power-of-two dimensions like 16x32 or something. They're very often "ripped" from commercial games, but occasionally you're lucky you find something completely original (although I consider fan games and prototypes a very legitimate use for "ripped" commercial sprites.)

One of the problems with all these sprites out there, however, is that they aren't generally available in machine friendly formats. They're generally organized organically with no regard for grid alignment or consistent spacing. This makes them rather tedious to use. But there are so many of them. Sometimes it feels like they are so close, yet so far...

So I whipped up a quick program to help in access this vast treasure trove of game art. Right now it simply identifies rectangle-ish regions of an image, guided by your mouse clicks, and then... that's it.

And that's why I'm here!

Once I started thinking about what I wanted the program to do after it had identified the sprites, I realized that I wanted to find out what other game developers would find the most useful.

For what it's worth, the code can be found here:

http://github.com/hdon/spritecaster

The most obvious thing the program could do is spit out an image organized into a highly machine-accessible grid, but after that you'll have to make sure the sprites line up properly within their grid cells, work out the animation timing, and generate some kind of glue between the animation and your code. Well this is exactly the kind of software I like making -- tools -- and I'd appreciate your input on what you'd like to get out of sprite animation software.

I'm equally concerned with editor features as well as export formats. Exactly what aspects of "spriting" can be useful for just about every programmer? Is it possible (or wise) to create sprite+animation libs for use with the export format? Or should the export formats aspire to conform to existing libraries? Would it be useful (or wise) to generate animation data that emits more generic cues than "next frame?" (Would you want to design hit boxes or synchronize sound effects from your animation program?)

Alright I think that's enough to get you started. Let me know what you think!
Quote this message in a reply
Apprentice
Posts: 5
Joined: 2008.12
Post: #2
There's now a video demo at http://codebad.com/spritecaster-demo.ogg
Quote this message in a reply
Member
Posts: 65
Joined: 2008.09
Post: #3
Interesting, I have actually been working on a similar program called "Spriter". Although from the looks of it your software focuses more on the process of re-ripping, as with mine you copy and paste, which admittedly is not as cool as yours.Ninja Otherwise, mine can do palette swaps, animations, and rectangular collision boundaries. Right now it exports the images (a color, and a mask) as tif's along with a data file that contains all the animation/collision/sprite information. I've only written a module to import the data and pictures for REALbasic/SuperSpriteSurface (uses OpenGL), but I have future plans to make a C++/SDL/etc... library. It's also not very user friendly. I plan on seeing how well it works with the game I'm writing before I decide to make it usable for everyone.

Spriter Screen shot:
http://picasaweb.google.com/lh/photo/4iv...directlink

Generated Sprites sheets:
[Image: picture1hd7.png]
[Image: picture2fy3.png]

I say go for it, I found my program really helpful. Grin
Quote this message in a reply
Moderator
Posts: 3,573
Joined: 2003.06
Post: #4
tcIgnatius Wrote:I say go for it, I found my program really helpful. Grin

Now that's a smooth hijack if I've ever seen one Wink
Quote this message in a reply
Post Reply