ZSprite Tool

[define-private-public]

Like many of the other tickets I've posted here, I'm not going to work on this now but I'd like to lay out my ideas before I forget them; though after the basic sprite stuff is done i think I'll start work on this.

Since we have our own custom file format ZSprite for representing simple sprite animation, we're going to need some tool to make people's lives easier to use ZSprites. As of right now the file format is nothing more than a text file. I personally don't think it's that hard to interpret and understand, but it would suck to have to define your sprite animations textually instead of graphically. Thus, we need to make a ZSprite tool.

Since the ZSprite format is pretty simple right now, it only needs to do a few things:

• [ ] Get a collection of images (spritesheet splitting will come later)
• [ ] Shove them into a sheet
• [ ] For each frame, be able to give it a unique name
• [ ] Set a default frame
• [ ] Define an optional origin point for each frame (default is (0, 0) being in the top left)
• [ ] Define sequences. An ordered collection of Frames with an associated timing value. They have unique names. Can be looping or not.
• [ ] Save it to a text file

I don't think this will be too hard to do. As for what to write the tool in, I think we should stick to Nim and keep this project "as Nim as possible." But instead of targeting a desktop platform for the tool, I'd like to target it as a browser app for these reasons:

1. Only desktop GUI frameworks I really know how to use are Qt (for C++ and Python) and Swing for Java. Browser GUI controls are pretty easy to understand without much knowledge
2. As long as you stick to standards, you're thing is guaranteed to run in every browser. So it's cross platform off of the bat.
3. Nim already has a lot of stuff bound for the browser
4. I've already written an HTML5 canvas wrapper, so we're good on the drawing front.
5. We could post the tool on the website w/ a live demo. The app would run completely client side.
6. Nim JS target being experimental is actually kind of good, and compiles fast!

Only things I'm concerned about:

1. Probably will have to manually bind some things to JS that might not be there yet (local file api?)

Anything you'd like to contribute?

[noctisdb]

Something to consider, some frameworks get away with a simple sprite batch to serve a similar result without an extra tool. Define the image's height and width, individual images height and width, and a scale and let the coder have more flexibility for animation and such(through an array, thats all the extent of "naming" they really need). I know it was discussed in the sprite issue, but if the extent of a tool from a 2d programmers perspective just showed the image with the bounds would be substantial enough as when the image is made the program being used also does this, so it could be overkill to have too much functionality.

[define-private-public]

@noctisdb Could you provide a small code example for what that would look like?

The ZSprite tool is meant so that our engine users don't need to write a .zsprite text file by hand. This is pretty good for an artist/animator who might not like working with text files that much. Also some sprites could get pretty complex (e.g. hundreds of frames and tens of sequences). The GUI tool is meant to be something to help the visualization of building these complex sprites.

[noctisdb]

Not so much the writing the text file by hand per se, I know tools can be useful, but like with many engines (defold, gamemaker) they come included but with so many options available for creating the images themselves, sometimes a nice way of handling the images is all thats needed without the need for a new tool.

BASEIMAGEVARIABLE = love.graphics.newImage("image.png")

player.anim = { love.graphics.newQuad(0, 0, 64, 64, 384, 64);
    love.graphics.newQuad(64, 0, 64, 64, 384, 64);
    love.graphics.newQuad(128, 0, 64, 64, 384, 64);
    love.graphics.newQuad(192, 0, 64, 64, 384, 64);
    love.graphics.newQuad(256, 0, 64, 64, 384, 64);
    love.graphics.newQuad(320, 0, 64, 64, 384, 64); }
     love.graphics.draw(BASEIMAGEVARIABLE, player.anim[ARRAY], X, Y)

Take this for example from LOVE/Lua. This does not use any image data at all, allowing the coder to hot swap the image during the game while maintaining the bounds of the "image frames", which works well in 2d games. These quads effect the output image and even the scale(first 4 arguments are the top-left and bottom-right coords).

Cycling through them is a matter of cycling through the array. Now something that just takes the aforementioned and previews the above might be beneficial, minimizing bloat was all I was alluding to. Now when there are say hundreds of frames, the above could be cleaned up with a loop instead of writing each by hand. And it doesnt really require an extra text file, just an array.

And for clarification on the draw, the second arg is which "frame" in the image is drawn

[define-private-public]

After thinking about this a bit, making the tool a desktop app might be better. Some of the OpenGL stuff might cause problems when using Nim's JS target. IIRC, we already have nuklear in zengine, so building the tool around that might be best.

[define-private-public]

Do you have any issues if I use using NEd's GTK3 bindings? They're good on Linux. I can test them on Windows later tonight. Could you try them out on OS X?

[define-private-public]

And on third thought, I think I might want to do this with nuklear and zengine itself...

I tied out getting the GTK+3 bindings to work. While they do compile, I forgot OS X's dylib stuff is a pain in the butt to deal with. So unless there is an easy to configure and package that, I'd like to rule it out.

I'd prefer much more to do it with HTML5, but that doesn't look to be the case right now because of the deps on some desktop only packages.

[zacharycarter]

I think using Nuklear + ZEngine itself is a good option. I'm getting over my cold and could assist with this this week.