importing graphics

One of the first things I did when I got Codea - like the first day - was hack in my own spritepack. Fun, but a stunt - I couldn’t share it with anyone, so I can’t really use it for things I wanted to share.

When we got images, one of the first things I did was get my own graphics in via source (tomfez). That could be shared, but a teensy 64x64 sprite was super-huge in source.

A big part of the reason I was pulling for persistent data was to cache and share graphics between projects. The problem is, with .codea sharing disabled, I can’t encode graphics into persistent storage and share them via projects.

I also expect demand for importing graphics to grow after 1.3 is released.

We need a real way to get our own graphics into a project. Spritepacks are limited, and having someone have to download and install a custom spritepack is yucky as well (although it might not be bad if apple allowed a 1-click import from a URL).

Suggestion: enhance sprite to take a URL, or make a loadsprite() command to fetch a png from a URL and save it to a project-local spritepack. That way, instead of having to bandy about giant chunks of source, or mess with persistent storage, a program could say:

sprite("planet", WIDTH/2, HEIGHT/2)

loadsprite would check to see if the image is cached in the project, and use the local one if it’s already there. if not, it would fetch it from the internet. A sprite() call that doesn’t match one of the global spritepacks would look in project storage for the sprite.

This is, incidentally, the functionality I wanted first from sockets. (Second was for multiplayer gaming, but this doesn’t address that need)

Because of it’s caching nature, this should be fairly immune to abuse (any cached image wouldn’t make the web call, so it couldn’t be used trivially for OOB data). Codea could check to ensure the png is valid or error out.

Good ideas, @Bortels.

I still want to put in .spritepack sharing in a similar way to .codea sharing - 1-click import.

We could simplify your API to:

sprite("http://url-of-sprite.png", WIDTH/2, HEIGHT/2)

And it could draw with a temporary “Loading” sprite until the data is fetched from the web and cached on device. But what happens if you update the sprite on the web and try the function again, then Codea simply fetches it from its cache. We could use E-Tags to check if it has changed, but that means people need to set up their servers to serve E-Tags.

That was my original thought; I went to “loadsprite” so that you could do it in setup(), and know you had the images when you hit draw().

The problem I have with sprite updating - and I’m not against it, mind you - is that if you end up with some way to force a check every time, you may as well just let us load arbitrary data from a URL; I could, very easily, use it as a mechanism to pass OOB data (in the URL) and get data back in the sprite graphics (composite it to an image() and read the bits). If we want to do that - just do wget() and some way to load binary data into an image(). (Keep in mind: I don’t think this should be forbidden anyway, I really do want a way to share data so I can do multiplayer games. But - baby steps)

The idea behind caching and not checking again is to assure Apple we’re doing something pro-active against that sort of abuse; if a cached image never reloads, well, that’s that. Maybe add some way for the user to manually clear the cache. (yes, definitely, or debugging will be a giant pain)

I would also say that many (most?) people won’t have a server like I do - being able to host the images on flickr or other free image hosting services would be a plus. That would probably preclude fancy caching like ETAGs. You replace the image, you change the name. (In my case, it’d be like “mars-0001.png”, and when I update it, it’s “mars-0002.png”, and I just change the name in the source. Crude and old-school, but effective)

If you do it in setup it would just appear to “hang” until the sprites are loaded. I would consider that a negative user experience.

If the data can’t be changed, then 1-click importing of .spritepack bundles as well as in-editor Dropbox support seems like a nicer solution to me.

When sockets were in the beta, I did basically this (for font data - admittedly, only a few k), never had an appreciable lag (data goes pretty fast nowdays). I could see putting in a “loading data” screen while it was going - it should only be an issue, if at all, on the first run, after that, it’s cached. Or, like you said, do it async, and just have a “loading” placeholder.

The problem with 1-click sprite bundles (and I don’t see this as a replacement for that, but rather an adjunct) is that the user has to go fetch them. Perhaps a “loadspritepack(URL)” that launched mobile safari at the URL for the spritepack? You’d end up with the same question there, of how to force it to reload when the graphics update.

And of course - it’s not that data can’t be changed in the original scheme; it’s just that it doesn’t check every time. Either the programmer (by changing the name/URL) or the user (by clearing the cache) would manually force a recheck. And again - that’s just so I don’t set up a server to turn this into a hacked OOB means of talking to the web…

Tell me more about in-editor dropbox support. it sounds promising. :slight_smile:

@Simeon - Wouldn’t your original though keep reloading the prote over and over and would lag Codea?

With Apple paranoia, I don’t think it’s such a good idea. I prefer project-based sprite pack which only available to the project alone, similar to projectData. This pack can have items imported from the net, through a command (menu or button), not through API. It can also import images from Photo app. This will assure that this feature can’t be abused by code. When the project is exported, the sprite pack also goes with it.

The similar mechanism can be used for other resources as well, such as sound file, data file (text), etc. Codea shoud provide file format validity checking, just to make sure it can’t be used to import code. And all those imported resources are treated as resource, so they never be executed. With this approach I think Apple will approve it.

I like the idea of being able to pull an image from the photo app and treating it as a multi-sprite template from which you can peel multiple images.

@bee, the problem with “when the project is exported, the sprite pack also goes with it” is that we don’t have export, not to mention import - and may never.

The scheme above will let us have the goal - nice graphics in our projects that we can share - while still living inside a reasonable cut-and-paste regime. I’d much rather have what you suggest, but Apple won’t let us right now. And the things you suggest above about graphics aren’t sharable.

As for Codea providing validity checking - good luck with that. Code can be hidden anywhere. Look up “steganography” on wikipedia. The only sure way to eliminate downloadable code would be to remove load(), and if that happens, we just write an interpreter in lua.