I confirm the camera fill is not refreshed in real time. It refresh only if I hide/show the app again (or display the notification menu and close it).
I’m currently downloading the last daily build, I saw something about ‘CameraPaint update’ in the change log…
You may need to add some things to your build settings. See this blog post:
http://www.coronalabs.com/blog/2013/11/05/tutorial-captureselect-photo-and-video/
Hi Rob, I inserted this into our build.settings file but the camera feed still displays in portrait mode even though my device is set to landscape orientation.
iphone = { plist = { CoronaUseIOS7IPadPhotoPickerLandscapeOnlyWorkaround = true, CoronaUseIOS6IPadPhotoPickerLandscapeOnlyWorkaround = true, CoronaUseIOS7LandscapeOnlyWorkaround = true, CoronaUseIOS6LandscapeOnlyWorkaround = true, }, }The app I’m testing with is portrait only.
@davidjames At the moment portrait mode is the only supported orientation but we will add your request to our camera fill feature request list (along with front facing camera support).
@abiasi Can you post your sample code for changing/deleting the fill - we will use this to reproduce the issue.
Here’s the project attached. When I run it on my iPhone 5S, the camera only captures 1 image, is not real time and when it switches from scene1 to scene2 it crashes after a few seconds.
Huge vote for landscape support. All but one of our apps are in landscape orientation and in particular all of the apps where we would use this feature.
@dmekersa – I am getting the same behavior, camera feed not updating, but it does if you suspend/resume (Build 2171).
I noticed something further - If I update the coordinates of *anything* on the screen (move the camera feed rectangle a bit, or even an onscreen button by 1 pixel), then the camera feed updates. But just for 1 frame - while the other object is updating. If you move something a pixel later, again the camera feed updates at that time.
So I’m guessing the camera feed by itself doesn’t trigger the SDK to update/refresh the openGL buffers, or something along those lines.
Something else onscreen must update/move to trigger the cascade of openGL buffer goodness. Well, until coronaLabs starts making live camera feeds force screen updates, me thinks…
I’ve been putting a 1 pixel circle at .004 alpha moving back and forth on the screen to get live camera. Works well enough I suppose…
We will look into this. A possible work-around is to call: display.setDrawMode( “forceRender” ). It overrides several optimizations in rendering to redraw the scene.
@robo – it’s good enough for now, we can move ahead with our code.
I think an important thing here is this:
If we can identify the issues (in beta features like this), and help them to isolate and home in on the technicalities, then we all win.
And CoronaLabs is listening.
So hopefully in the end, we all win.
PS: Note that my meaning is that: CornoaLabs intends for camera feeds / textures to update automatically independent of other objects, and our proposed “workaround” behavior is understood by all, CL too, as temporary until the issues, if any, are resolved. Your mileage may vary.
@mpappas, well said. This has been precisely my experience most recently in the graphics.newOutline API question I posted.
regarding the landscape vs portrait issue : I created a shape with the camera feed texture and width = wanted_height, height = wanted_width and then just rotated it -90 °, and it seems to work 
I also wobbled a pixel to get the feed in realtime and not just one frame at a time.
Oh, another bug I thought I saw posted about the feeds, but after looking back, I don’t see it mentioned by anyone, so while we’re piling on the feeds here… Anyone else seeing this one?
I put the feed on a rectangle. Great, works good (as long as something else is updating on screen of course, otherwise the feed never updates – already discovered). Put poverlays on top, works great. Mask the feed object, works great. Everything works great… Until.
The user changes screens, and I call display:remove() or object:removeSelf(). Shortly I release() the screen that had the feed (and construct/display the new screen), I get a hard crash on iOS – “Bus Error: 10”.
I had tried several ways to disengage the feed from the OS before the remove() (like setting isVisible = false, setting.fill = “” / nil, using a timer.delay to allow the graphics update, etc), but couldn’t isolate a method that would get around it… So I switched to the “if you can’t beat them, join them” strategy again (like for the other bug, just keep something moving)…
To prevent the crash (actually to prevent the removal of the feed), when the screen with the feed exits it now creates a global feedgroup and inserts the feed rect into it, then places the group object WAY offscreen so it wont be seen, makes it invisible, etc. (Next time it reloads it checks if the feed already exists, and re-uses it).
With both bugs (feed not updating, and the bus error bug), I’ve got more workaround code than I’d like, but hey, I’m still moving forward onto more screens.
Anyways – anyone else seeing bus error 10: when removing your feed yet?
Did not try yet… Why don’t you use Composer and do not recycle the scene when hidden (it keeps the objects in memory, just hide them)?
You should submit a sample to bug report no? It could help to get this feature fixed. It’s amazing how new features are published and then not updated like this… I got a similar issue with the iTunes plugin, I had to create a project to show the bug, I hope they will fix one day…
I confirm the camera fill is not refreshed in real time. It refresh only if I hide/show the app again (or display the notification menu and close it).
I’m currently downloading the last daily build, I saw something about ‘CameraPaint update’ in the change log…
+1 for front facing camera
I definitely note for the landscape feature. But mihal’s solution of rotating it may work for now. I plan to try this tonight.
Warren
I just made a simple code here and also saw the problem of the camera not refreshing.
But then I downloaded the Corona Camera Fill Sample code and it worked fine.
Just sad that it sill doesn’t support Front Camera and Android.
Huge vote for landscape support. All but one of our apps are in landscape orientation and in particular all of the apps where we would use this feature.