Taking a picture - modification to Codea runtime

Hi. I’ve made an attempt to add a function pickImage to take a picture. Maybe it should be called takePicture, but I guess a function to pick an image from the photo library would be nice also (just need to change some parameters). Anyhow, I’ve forked Codea runtime and added it.

-- Stop the runtime, take a picture, store it to Documents:Foo and return to the Codea application.

Maybe it would be better if there was a callback function instead, but haven’t figured out yet how to write runtime code for that yet. :slight_smile:

The modifications to Codea is here.

But what I would really like, is to be able to write something like sprite(“Camera:Back”) to get a live feed. Codea developers, maybe you could give me some suggestions where to start, to add that functionality? Should I modify TextureCache for this? Or any other idea how the API should look like?

I have to try this :slight_smile:

We can do some AR games also hahaa

@tnlogy I was going to add this exact feature! (For @mark.) Do you mind if I base the final API on your idea?

can we also have a variant that does not store the picture but just returns it?

@Simeon It sounds great :). Any plan on when it will be added?

@gunnar_z that was my initial plan — to have it just return the image, which you could optionally save with saveImage. However I kind of like @tnlogy’s idea of being able to pass the destination as an argument to pickImage() too.

@Simeon, what do you think about using sprite(“Camera:Front”) and sprite(“Camera:Back”) to use the camera stream as a texture? I’ve committed some code that seems to work at https://github.com/tnlogy/Codea-Runtime

The camera seems rotated 90 degrees, and some strange things like that, but it’s a proof of concept at least.

I’m only using the back camera right now, but I will add functionality to change camera later on. The idea is, if the user calls sprite(“Camera:Front”) in the draw function, then the runtime will start the camera and keep it running until a render pass without calling sprite(“Camera:Front”) happens, then the runtime will stop the camera stream. In my current code it’s always running.

I have been wanting to do something similar but we weren’t sure where to put the functionality.

I had thought fill(CAMERA_FRONT) - but there are complexities with that.

Having it be a sprite type is quite nice, though limits what you can do with it. But I like the concept.

Since I currently save the frame to a CCTexture2D I guess I could allow it to be used in a mesh as well. What limits are you thinking of?

Thanks, @Simeon and @tnlogy. Looking forward to this.

@tnlogy we are thinking about tying shader access into mesh, being able to stream the camera input and modify it with a shader in real-time is where I would like to go with it.