beta 1.3.5

I see the debug library is being added…

Can I beg for zlib, and maybe jpg/png decoders, and the base64 stuff from the sockets library?

I know spritepacks are the long-term “right” solution (or files, or sockets, but I digress) - but until then, people who want to roll up images are in a lurch - the data is huge. Some are rolling their own encode/decode - but they’re still nasty. The ability to load binary data from a base-64-encoded jpeg or png would be huge - it would reduce size of projects that have lots of images tenfold.

The libraries should be non-controversial in terms of Apple approval, and simply “include the library” - it’s a data transform, there should be little or no extra work to be done.

We nearly had it in there — proper image saving. But I’ve had to work alone to finish this update so wasn’t able to finish all the features I wanted to have in 1.3.5. (Retina-fying the entire up took up my whole long-weekend.)

1.3.5 actually has undocumented functions called saveProjectImage and saveDocumentsImage. These accept an image object and write it out to a PNG file in either the project’s bundle or the documents directory. There’s no way to read them back in, at the moment.

We also have a sprite pack that shows up for your current project and documents directory (though I’ve had to disable these in 1.3.5 due to them not getting done in time). These are pretty definite for 1.4, as they are nearly implemented.

I’m talking about the other direction - import. I can already take a screenshot if I need to get graphics out, but the goal is to get game assets into the ipad in a reasonable manner. And game assets have recently expanded to include things like a 3d mesh of points…

Yes, that’s necessary to have if we have image saving capabilities. We might start with images then expand to regular files — I’m not too sure.

I’d like to design an API that is coherent with the current one. Any suggestions? Say the current design is:

-- Saves as project.codea/name.png
-- On retina device saves project.codea/name@2x.png 
-- AND project.codea/name.png 
saveProjectImage( image, "name" ) 

-- Attempts to load project.codea/name.png
-- On retina device attempts to load project.codea/name@2x.png 
-- (falls back to name.png if @2x doesn't exist)
readProjectImage( "name" ) 

Same thing repeated for 


Except they read to the global Documents folder for the app.

We also plan to turn on iTunes file sharing again so you can drop images into the documents folder. That will be a tiny update that we may have to struggle over with Apple.

(A side note: with the image saving stuff, we plan to allow you to change your project icon by executing saveProjectImage( someImage, "Icon" ))

For general files we could implement the following:

saveProjectFile( data, "name.ext", BINARY | TEXT )
data = readProjectFile( "name.ext", BINARY | TEXT )

bool = hasProjectFile( "name.ext" )

-- Same for Documents.

I think there could be a better design than that. Any ideas?

To be fair, my reasons for this request (adding zlib and libPNG and such) are all about the specific case of “I want to load an external image, and my only means are cut-and-paste” - so I’m going to have a chunk of code that decodes a big string into an image. If you want to take it further, that’s awesome - but beyond the scope of what I was hoping you could get into a quick update.

Comments below on images APIs…

I wouldn’t have explicit retina support (unless you plan on extending the metaphor to iphone as well). It is not unreasonable to expect coders to support scaling their image appropriately for the platform they’re on. (You’d have the same issue with the built-in spritepacks)

A lot of it depends on if you go with the file metaphor; if you do, then “image=loadImage(somedatasource)” is perfectly reasonable. I do think you’ll be better off just sandboxing standard Lua file I/O if possible; the more things can be compatible with “standard” Lua the better off we are, I think. I think regular Lua I/O, jailed to the Codea Projects directory, isn’t unreasonable. It still leaves us with the bootstrapping of getting data there, and of decoding it, but that’s what I was looking for zlib/libPNG for.

NOW - pie in the sky. Say you don’t want people to have to mess with raw encoded data at all (a noble goal). You have that now with spritepacks - you’d simply need to add a mechanism to download/install new spritepacks, and perhaps to save an image to a spritepack, and maybe extend the metaphor so a spritepack is part of a project.

Here’s what I’m thinking - have each project make an implicit spritepack with the same name as the project, initially empty. So - a project named “test” would have a “test” spritepack associated with it with no sprites. The API could then be:

sprite("spritepack/imagename") - draws image "imagename" from spritepack "spritepack"

sprite("imagename") - draws image from project storage

sprite(image) - draw an image object

saveSprite(image, "imagename") - Save the image object to the current project spritepack; saving nil would delete the sprite

saveSprite(image, "spritepack/imagename") - Save the image object to a different spritepack or project

setSpritepackInfo("spritepack", "A nice spritepack name", "The author", "a URL", icon) - where icon is an image object *OR* "name" for the name of an image in that spritepack

This avoids global/project differences - any project can access images from any other project (or installed spritepack) if it knows the name. It also lets you make a project that does nothing but add a new spritepack.

If you refer to a spritepack that doesn’t exist - it’s created. This all also assumes that there’s a spritepack manager that lets you view them (as you can now), and maybe delete packs or sprites, and ideally download spritepacks from the internet. (the spritepack manager could easily be a lua project using the API above, plus some way to enumerate projects and spritepacks)

In a perfect world, in addition to all of this, "sprite("")" would also work. I understand that may not fly.

That’s actually very similar to our planned functionality. It’s what saveProjectImage and saveDocumentsImage will do.

  • Documents shows up as a global sprite pack, shared between all projects. It shows in the sprite picker.
  • Project sprite packs show up as a sprite pack only for that particular project. It shows up in the sprite picker.
  • These are referenced in code as:
sprite( "Documents:SpriteName" )


sprite( "Project:SpriteName" )

the call:

sprite( "SpriteName" ) without a qualifier will first search in "Project" and then in "Documents" for the sprite.

These two sprite packs will be constant — every project that has saved images will show up in the picker, and every project will have access to the documents directory from the picker.

We will then add custom packs that can be explicitly managed by the user. So you can copy your project or documents images into a named global sprite pack that has a theme, for example.

It looks like there’s a minor bug in 1.3.5 that we will be fixing with a quick 1.3.6 fix. I’ll try to put a http.get() API into the 1.3.6 release. And make sure it can support the RESTful services (GET/POST/PUT/DELETE).

My thought is:

data = http.get( url ) -- Synchronous, blocking

http.get( url, successFunction ) -- Asynchronous

http.get( url, successFunction, failFunction ) -- Asynchronous

http.get( url, { success = successFunction,
                   fail = failFunction,
                   data = dataFunction,
                   type = "GET" } ) -- Asynchronous

We might also put a JSON parser in there.


The only thing about http.get might be to have it have 3 return values - the body (which is what you’d get if you only asked for one of them), the success code, and a table of headers. Just a “completeFunction” should be sufficient - it’s easy enough to see if the return code is ok. And yes - Async is a good idea.

But frankly - that’s a wish list. Just being able to get is 98% of what I’d use.

Even just being able to ‘im=http.get(“”)’ would be insanely useful. A JSON parser would be icing on the cake.

failFunction would be for if the network isnt working (ie, no response at all) rather than a 404 or something (which may or may not be considered a success, I guess we need to figure that out)

Hmmm. Yes, it would be nice to differentiate between “the site failed” and “you don’t have a network I can use!”. Perhaps a nil return? I do think it’s handy to be able to get at the response code and headers.

ooh - passing a timeout is also a good thing, although with an async process you can fake it…