[LWJGL] Spritomatic - sprite creation tool (for programmers)

With a twist!

The initial idea
So I basically have been using some of the standard sprite creation tools out there, and one of the things that annoyed me was their limited capacity for easing actual development, the most common use being the ability to create sprite sheets that could then be interpreted by code.
What annoyed me was the fact that I’d have to go from creating animations in a sprite editor, to exporting a sprite sheet png, to writing code to find it as a resource and then to putting things in, usually via a constructor, to let my program know the width/height of a specific animation, no of frames, duration etc.
I got to thinking that it would be great to be able to write all the animations inside the editor, and then merely click an export button and be rendering the sprite within 2 lines of code.
In essence, that’s what I’ve achieved so far:

E5o3AOTlIzA

Technical aspect
Essentially all the animation/sprite data is serialized from the editor and put into the res folder; then a xml file with all the resource links in is generated; then a resource manager class + several others are unpacked from a internal zip into a package in the src folder and when the program is run the resource manager reads the xml and then the serialized data and generates some sprite objects that can be gotten through their names in the editor.
It simplifies rendering of an animation to Sprite.Render(x,y,width,height), and changing animation to Sprite.setAnimation(“anim name in editor”). I still need to put in some controls for pausing/setting frames etc. Render also acts like a game tick to handle animation timing, so might make them seperate for more control.
Done so far

  • Exporting an animation as GIF
  • Exporting a sprite sheet as png
  • Exporting to a lwjgl project, sprite useable in 1-2 lines of code
  • Basic sprite editor with saving/loading, color chooser, project management etc etc

Still to do

  • Stop drawing to canvas when clicking on dropdowns that drop down over it XD (facepalm worthy bug)
  • Zooming is a little annoying on large images as centered to top left
  • interface changes
  • Property menus
  • Bug testing
  • Write custom color chooser as I feel using JColorChooser is not the way to go
  • evaluate export destinations
  • Many other things I am sure ^^

Hopefully will have a release out soon, once I feel it is user friendly, and then will be able to release source code if I manage to tidy it up alot C: Just feeling out to see if it would be helpful to anyone else now that the general idea is implemented.

You might want to change the name… :slight_smile:

Spriter

Hehe, yeah I saw that :frowning:
Thought it might be good as non commercial until I can find a better name; better to be safe I guess, will change the title to something just as ingenious :wink:

Don’t worry, no one uses Spriter anyway. :point: BAZINGA! ;D

It looks very interesting and helpful. I’ll probably test it out when a release comes out. One thing I am not a huge fan of, however, is that it exports code into the project. It allows for customization, but I feel like much of it seems to be able to be stored within the library (if there is a library). It’s not a huge problem as many may like it, but I’m not a big fan of it. I would be able to work with it but I’d just prefer if more data is stored within the library. Also, in an unrelated note, I feel like the folder “res” in your project shouldn’t be a source folder. I’ll be sure to try this out when a release comes out :smiley:

Hehe C:
Thanks, would be super awesome! Can cut it down to 2 classes if need be, but expanded one to 3 so less memory would be used at runtime. I saw matheus23’s xml loader that stored alot of the animation data in the xml file, which could be handy in just reducing it down to a resource loader class :3 Will have to think about it. It’s not meant to be, just left over from when I was trying to fix an inputstream problem and ended up following a instruction that didn’t work :stuck_out_tongue:
Cheers!

:o

No, less classes != better. Also, memory won’t be touch that much, since you need to store the same information anyways, only in 2 classes instead of 1 (<- example).

Just so you know, my ResourceLoader is implemented with 19 classes in total, not counting the backend (3 classes) and the utility classes (7 classes).

Looking pretty good, waiting for that release :wink:

I use Spriter.
BAZINGA!