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.
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
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.