Spritely -- a simple image editor

I’m still scratching my head over the best approach to print, but this version does generate simple set statements to draw an image. I’m hoping to get more functionality into it soon.

Draw your sprite in the grid on the right, then copy the text from the output box to get the code to paste into your program.

http://devilstower.posterous.com/spritely-01-codea-sprite-editor

This is really cool!
The space in bottom right could be used to display a palette, so that you can reuse colors.

(BTW, the order of blue and green seems to be reversed in drawBig.)

This is awesome. 8-bit Art in codea. yeah!

Fantastic work Mark. I love that you put sound effects in for painting, and that you seem to have built the UI icons in your own editor, nice touch :slight_smile:

Regarding getting the data back out of the editor, there’s a new, undocumented function in 1.2 you can use to make this awesome.

loadstring() will let you execute a chunk of Lua code. So you can do the following instead of printing the text to the output window.

  • Store the image creation code as a big string using the custom data storage. Do the following: saveProjectData( “SpritelyData”, “lots of image code as a string” )

  • The “lots of image code as a string” data would look something like this:


local spritely = image( 16, 16 )
spritely:set( 1, 4, 244, 100, 16 )
spritely:set( 2, 4, 244, 100, 16 )
spritely:set( 3, 4, 244, 100, 16 )
spritely:set( 4, 4, 244, 100, 16 )
-- ... and so on
return spritely

  • In order to create an image from this saved data, all the user has to do is the following:

createImage = loadstring( readProjectData("SpritelyData") )

myImage = createImage() -- executes the above code

sprite( myImage, x, y ) -- render image

  • Bonus points if you can allow the user to customise the name that spritely saves the data under (instead of “SpritelyData”). The user can have a quick way to create images from Spritely’s saved data.

Note: sprite editing is actually a feature I’ve wanted to add to Codea for a long time, and still might add.

One way to allow the user to store the data under their own key could be to do the following, print something like this to the output window:

-- Copy this data into your own sprite with the following code
saveProjectData( "YOUR SPRITE NAME", readProjectData( "SpritelyData" ) )

-- Load your new sprite into an image
-- (Note the function call braces at the end of the line)
myImage = loadstring( readProjectData( "YOUR SPRITE NAME" ) ) ()

I wrote a little Python script which uses PIL to convert an image file to a series of “anImage:set(…)” statements: http://szleski.posterous.com/images-in-codea
That way we can bundle custom sprites with a Codea project.

Example:
python image2codea.py image.png

Output: image.lua

Plus one for this

How fast is codea in drawing images?

The code i’ve been working on (pacman) requires drawing optimizations because i was using rect for drawing pixels, but with the new image functionality i imagine that’s not the best way anymore

New version up that incorporates all these good suggestions.

– color palette for some pre-defined colors
– preview of image at actual size
– print to output fixed
– save to project string

Simeon – that loadString() function is killer. Solves all manner of problems. And building everything to one big screen and dumping it to print solved the nested loop issue.

http://devilstower.posterous.com/spritely-020-codea-icon-editor

Wow so awesome. How about talking to bortels about using his keyboard implementation (dont think he release yet) so you can type the name of the image as you save it?

i’d also allow currenttouch.state to be Moving as well and remove the old touch check so that the user can draw his finger around to draw stuff

This is great!

The keyboard class, as it stands (working, poorly, and ugly) is up on github already - https://github.com/bortels/HersheyCodea/blob/master/Keyboard.lua

If someone wants to clean it up, feel free; I’m happy to accept push patches, or just publish a better one - I’m not proud. The keyboard has been sidetracked while I worked on image() stuff (nearly done, I swear!) and now I’m seriously considering redoing the font stuff I did with images for speed (ie. I’d pre-render the characters and draw them with images, rather than line drawing them each time).

Regarding drawing speed, @ruilov, Codea is a bit slow with sprites at the moment. We’re going to be heavily optimising sprite drawing in the coming releases. noSmooth() rects are probably fastest.

Are you drawing the level in Pacman as lines at the moment? It would be interesting to see how all the rects() compare to a single image of the level map speed-wise. I’ve only tried it on iPad 2 and it seemed perfectly smooth.

pacman map is drawing as rects. Each pixel from the original game corresponds to 2.5 x 2.5 pixels in codea. Drawing the rects for each tile of the game was slow (DeltaTime ~ 0.1) so added an optimization that joins two rects from different tiles if they have a side in common before drawing, which got DeltaTime to 0.02

@ruilov I suspect noSmooth() line() calls would be fastest, as these use the GL_LINE primitive, which is very cheap. What would be more interesting is to see if an image() with the level pixels set is faster to render using sprite().

The way you did it is really cool though.

– On @ruilov’s suggestion, changed draw to support support MOVING.

– Added 1x and 2x views of image in progress.

– Added a load / save dialog with slots for multiple saved images

– general cleanup

I’m looking at Bortels’s keyboard class, but thought the load/save dialog would help till I get it working.

http://devilstower.posterous.com/spritely-030-simple-image-editor

Nice improvements. This is really amazing, nice features. I think it looks better with noSmooth() used in certain places - and runs faster. I modified the following functions:

noSmooth() on scaled sprites uses nearest-neighbour interpolation, so you get a nice pixellated effect on the 2x sprite preview, rather than a blurriness. The noSmooth() on the main grid makes interaction faster, and looks much cleaner, I think.

drawBig() and drawSmall() to incorporate noSmooth() as follows

drawBig:


function drawBig()
    pushStyle()
    noSmooth()

    -- ...original drawBig() code, except change 
    strokeWidth(1) -- thinner strokeWidth looks good with noSmooth()

    popStyle()
end

drawSmall:


function drawSmall()
    pushStyle()
    noSmooth()

    strokeWidth(1)

    -- ...original drawSmall code up to:

    sprite( anImage, x, 412 )
    sprite( anImage, x + 1, 312, SpriteSize * 2, SpriteSize * 2 )

    popStyle()

    -- Draw the numbers with smooth() style

end

Also, the load / save dialog box is excellent. I would also use noSmooth() on the preview images for each slot.

The icons confused me initially, I thought the blue down-arrow was “Save” but it seems to be load. Perhaps you could use an “L” and an “S” on these icons as well.

The noSmooth() really does crisp things up. Nice.

Down arrow should be save and up arrow load. If it’s not working that way, I’ve mucked up something.

With 1.2.5 you will have to flip your images (previews and saved results), as image coordinates now start in the bottom left.

@Simon it’s funny. The print button is now a fax machine