The dropbox support with spritepack integration is genius. The integration couldn’t be easier - I love it. This is going to open up a ton of possibilities.
I like the photo import too - but the size limitation is a bummer. I expect it’s a sprite texture size limit - could we maybe in a future version either pick a region of an imported picture, or resize? It means, unless I’m mistaken, that I can’t, say, take a picture and then import it (because it’s too big). Hmm - maybe iphoto can crop, I’ll look. (I like the concept of grabbing a photo, importing it, then using it as a game asset)
But - unless I am missing something, there’s still no good way to share a project with a custom spritepack, unless maybe people make a zip file with the graphics and drop it into their dropbox. Which is I guess better than not being able to do it at all, eh?
I’ll be experimenting with the image save/load today (caching images I grab on-the-fly from github as part of the project I’m working on).
The project’s going slower than I had hoped because I got on the Diablo III beta, and there’s monsters to be killed.
Is there a cannonical way to tell if a given sprite exists?
I’d like to grab graphic assets via http.get once (on first run, presumably), and save them to project storage. To do so, I need to be able to tell if a given sprite is already downloaded (ie. it’s in the Project storage). I guess I could just keep a flag, but it strikes me as ugly.
returns “string”. Seemingly always, even if the icon doesn’t exist. (Project:Icon works, btw - yay!)
But if I try to sprite() an image from readImage(“Project:doesnotexist”), I get an error, which is kinda what I expect. I’m just surprised the readImage works, and doesn’t return nil for a non-existent image. Am I missing something?
That is odd, about getting non-nil returns from readImage(). I’ll look into it. I haven’t given those functions my attention yet so they may still need some work.
I believe there is a spriteList() function that I forgot to document. You can run it like this:
sprites = spriteList( "Documents" )
This will return a table/array of the sprites in the “Documents” pack.
Edit: I think those functions, readImage, saveImage and spriteList are not retina-ready and so could have weird behaviour when @2x versions of sprites are hanging around.
The sprite size limitation is mostly so people don’t shoot themselves in the foot with regards to memory. I may double the size limit (to 2048 pixels) on iPad 3, as that has double the ram. But it will still be easy to abuse by importing and drawing your whole photo album.
Hmm. saveImage(“Project:Icon”, image) works, because I can see the icon in the gallery.
But something is going on for names other than “Icon” - If I load a known good image (because I can draw it with sprite()), then do saveImage(“Project:” … imagename), then try to readImage(“Project:” … imagename) - I get nothing.
I’ll see if I can make a subset of my project demonstrating this - if I can’t, I’ll just bundle the whole thing up, it’s not really that big yet.
saveImage(“Project:Icon”) works in that it sets an icon you can see in the gallery - but loadImage(“Project:Icon”) comes up blank, no error.
saveImage(“Documents:Hello”) then readImage(“Documents:Hello”) works. Interestingly, I do not see it in Apps/Codea on my Mac in dropbox, but I suspect maybe when I run the dropbox app I will? (Answer? NO! I don’t see it in dropbox on my iPad, nor on the mac. Perhaps dropbox is import-only? Codea did make an Apps/Codea directory…)
saveImage(“Project:Hello”) then readImage(“Project:Hello”) does not error, but loads no image.
I suspect you didn’t see your Hello image in your Dropbox because you did “Documents:Hello”, not “Dropbox:Hello” - I expect the former uses iTunes file sharing only?
I didn’t realize that “Dropbox” and “Documents” weren’t the same thing - what I get for skimming.
Same results though - it works, in that I can save and read images, but they don’t show up in my dropbox, even if I run the dropbox app (it shows nothing in Apps/Codea).
Maybe I should just use “Documents” anyway - I’m only looking to cache. If I used a unique prefix (“Documents:appname-imagename”), it should be safe enough, and it should show up in the spritepicker as well, no?
More Odd. “Documents” works (Yay, I cache!), but the sprites don’t show up in the “Documents” spritepack.
Ah well - I can cache, that was my goal, time to move on.
Worth noting - there’s a “sync” button in the dropbox spritepack I missed. I pushed it, it makes a “Synching…” thing pop up that never seems to go away. So - there’s that.
Sounds like a bug with the sprite pack not re-loading until you restart Codea. I’ll fix it in the next build.
The Syncing never goes away? Even if you close and open the sprite picker? I’ll have to look into that.
(Once you link your Dropbox account the Apps/Codea folder will be created. If you try placing some files in there on your PC and syncing the Dropbox pack in Codea they should show up.)
@frosty, when you saveImage() to Dropbox - does it show up in the Dropbox app and/or online? Maybe I’m simply expecting it to do something it doesn’t? Is the Dropbox sync 2-way, or import only?
@simeon - so you’re saying the saveImage to Project: probably is working, but the project data isn’t reloading until I run codea again? I can test that…
No luck. SaveImage a known good image, exit codea, kill codea, run again with no saveImage, still nothing. I’m not getting Project:Icon either, even though it shows in the gallery.
So - should images I save in “Documents:” show up in the sprite picker? They do if I import them from iPhoto, but the don’t from saveImage, even though the do work with readImage.
@Bortels the Project saving is still a bit iffy. I’ll be taking a look at it for build 3 most likely.
Dropbox sync is two-way but you have to hit the “Sync” button to tell the data to go back to Dropbox. I could run Sync automatically when you go back to the editor. That might work. What do you think?
Build 2 is up and should fix a lot of issues. Also adds a pretty neat new feature for getting images in (via the pasteboard).
That should be fixed now, you should be able to saveImage() and it will show up immediately in Documents when you go back to the editor. Let me know if you are still having issues with this in Build 2.
