Problem with EAGLView.m kEAGLDrawablePropertyRetainedBacking property and BhSnapshot.mm in iOS6

bowerandy

Hi @atilim,

I noticed, just as I was about to use my BhSnapshot plugin in anger, that something was changed in IOS6 to stop it working. I use this plugin to create thumbnail images of objects created in game so that they can be displayed in a slider view and chosen later by the user.

The BhSnapshot plugin uses glReadPixels() internally but it appears that, since iOS 6, this is returning just a bunch of zero bytes. The solution is described here:

http://stackoverflow.com/questions/12528365/why-is-glreadpixels-failing-in-this-code-in-ios-6-0?lq=1

I've verified that if I change the Gideros EAGLView.m file to include:

[NSNumber numberWithBool:TRUE], kEAGLDrawablePropertyRetainedBacking,

then the problem is fixed. Do you think it would be a good idea to change the base Gideros code to include this change? Alternatively, is it possible to set this option later (after initialization time) so that I can do it from within the plugin itself?

best regards

atilim

Here http://developer.apple.com/library/ios/#documentation/iPhone/Reference/EAGLDrawable_Ref/EAGLDrawable/EAGLDrawable.html it says:
Setting the value to YES is recommended only when you need the content to remain unchanged, as using it can result in both reduced performance and additional memory usage.

Therefore I think I shouldn't change it.

And initialization needs a proper OpenGL context. Therefore I cannot set this option later.

The only good side is you can alter EAGLView.m by yourself

atilim

And when a new iOS version is released, a lot of things are changed/broken. I don't know how older iOS games are still running.

bowerandy

@atilim, thanks for the reply.

I tell you, this gives me a horrible feeling of "shifting sands". This feature is absolutely critical to the way my game works so I'm just lucky that, this time, the fix is in a bit of Gideros code that is actually available to me. I'm now wondering that would happen if it were buried deep in the internals?

From my point of view, this means +100 votes for you to finally implement "render to texture". I know there are quite a few Gideros users out there who have requested this feature in the past. Is it actually difficult/impossible to do with the version of OGL that you're using?

best regards

Javi

I'm in the same position as @bowerandy, render to texture and the option to load resources directly from Lua strings are the only features I miss in Gideros (to save resources as temp files in order to be able to load them is a slow process and, over all, it's a destroyer of the device's memory card).

ar2rsawseen

@bowerandy as much as I understand you (waiting for render to texture myself) even if it is possible to implement render to texture in current OGL version, is there really a need to do it, if after couple of month there will be a need to re-implement it again with the other OGL API. That would only postpone the movement to new OGL and raise all other kind of delays

bowerandy

@ar2rswaseen, well I understand that but as it stands (without any kind of roadmap apart from a few hints that @atilim has dropped in some other threads) we have no way of knowing how long an OGL2 version is going to take.

I don't know OGL very well at all and my question was just, "is this feature actually hard to do with OGL1". If the answer was "no" then I'd recommend doing it now and hopefully the code would move across to OGL2 with little change.

To be honest, I think my real worry is this lack of a roadmap but that issue was beaten to death in another thread.

best regards

atilim

@bowerandy although it's possible to develop render to texture with OGL 1, Android have some problems with it. When an Android OpenGL application is paused, its OpenGL context is destroyed and all textures are removed from memory. To implement render to texture, the texture data should be saved to CPU memory just before OpenGL context is destroyed and restored back after the application resumes. And this implementation is tricky.

Currently, I'm developing new graphics backend considering these issues. To be honest, I don't know how long OGL2 version is going to take.

atilim

@bowerandy - And I wonder will listing the roadmap items one after another make feel you safer? (like https://www.coronalabs.com/resources/roadmap/)

ar2rsawseen

@atilim I like listing all my tasks, because I get such a pleasure when I can scratch them off when their done

atilim

@ar2rsawseen I've tried many todo applications but at the end I couldn't use none of them. Finally, I have my precious todo.txt at my dropbox folder changing all the time

bowerandy

@bowerandy although it's possible to develop render to texture with OGL 1, Android have some problems with it. When an Android OpenGL application is paused, its OpenGL context is destroyed and all textures are removed from memory. To implement render to texture, the texture data should be saved to CPU memory just before OpenGL context is destroyed and restored back after the application resumes. And this implementation is tricky. Currently, I'm developing new graphics backend considering these issues. To be honest, I don't know how long OGL2 version is going to take.

This answers my original question.

In terms of the roadmap. If we had a page like that where the items were in order of likely implementation then that would be helpful. I actually liked the original scheme you had a year ago, you just needed to be a bit more realistic with the timescales and to make it clear that any dates published are always tentative.

best regards

bowerandy

@ar2rsawseen I've tried many todo applications but at the end I couldn't use none of them. Finally, I have my precious todo.txt at my dropbox folder changing all the time

Indeed, I use this for my todo.txt editor

best regards

atilim

Ok, I'll prepare the roadmap (But I'm dropping using redmine therefore it'll be an ordinary static web page)

atilim

@bowerandy TaskPaper look great. I'll try it right now. (do you what is the limitation of free version?)

Javi

I used to use Task Coach http://taskcoach.org but now I prefer Wunderlist http://www.wunderlist.com (both free).

atilim

I was using Wunderlist but stopped using it. I feel more comfortable with a simple .txt file.

SinisterSoft

Just looked at Wunderlist (now at v2), it's worth a second look... (as it's now v2!!!)

OZApps

Have you tried TaskBAdges? If you are used to text based todo's.

bowerandy

@bowerandy TaskPaper look great. I'll try it right now. (do you what is the limitation of free version?)

@atilim, I'm not sure. I have the full version. It's a bit odd that their website doesn't explain the difference but I guess it might be a time limited trial.

@OZApps, yes, I use TaskBadges with Taskpaper and they seem to work well together.

best regards

octotod

I just tried the BhSnapshot demo project, and I'm getting a crash whenever snapshotToAlbum or snapshotToFile are called. I changed [NSNumber numberWithBool:FALSE] to [NSNumber numberWithBool:TRUE] in EAGLview.m initWithFrame and recompiled GiderosiOSPlayer, but still get the crash. Xcode gives this error when running in the simulator:

-[UIImage rotate:]: unrecognized selector sent to instance 0xb584320

Does this relate to the glReadPixels() problem which cropped up in iOS6 remaining in iOS7? Are there any work-arounds?

thank you very much

kussakov

Just my 5 cents:
Since render to texture was implemented, but can't be used to save a screenshot - I also use plugin.
I just set kEAGLDrawablePropertyRetainedBacking to TRUE in EAGLView.m
The screenshots are working on iOS 6 and 7 and I do not see any performance impact. The FPS, CPU usage and Memory remain the same.
I will keep digging, but so far - no difference (at least on my device).

@octopod - did you add all those UIImage+... files to you project?