I have an OpenGL ES app that works both on iOS and Android. Most of the code was written ages ago by another person and now I have to maintain it. OpenGL usage seems fairly simple (the game is 2D and uses only textured sprites in a simple manner). But I see two major differences in graphics code realization for iOS and Android:
1) iOS code contains this code:
glGenFramebuffersOES(1, &m_defaultFramebuffer);
glGenRenderbuffersOES(1, &m_colorRenderbuffer);
glBindFramebufferOES(GL_FRAMEBUFFER_OES, m_defaultFramebuffer);
glBindRenderbufferOES(GL_RENDERBUFFER_OES, m_colorRenderbuffer);
glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_COLOR_ATTACHMENT0_OES, GL_RENDERBUFFER_OES, m_colorRenderbuffer);
and Android's one does not.
2) When Android app goes to background, all OpenGL textures are destroyed (glDeleteTextures) and EGL is shutdowned using eglTerminate. When app returns from sleep, EGL is re-initialized and textures are re-created.
iOS code does not do these things. It just pauses rendering loop by calling [m_displayLink setPaused:YES];
Other OpenGL-related code is the same for iOS and Android.
Everything works well on both platforms, but I want to have a full understanding of what's going on. Can anybody explain me a rationale behind these two differences?
1)
This is just a difference in the APIs. On iOS, you create your own framebuffer to render in to when the App starts. On Android the framebuffer is created automatically in GLSurfaceView, so the App doesn't need to create its own.
2)
On iOS, when your App goes to the background, the OpenGL context is preserved, which means all your textures and buffers are still there when you return it to the foreground.
Older versions of Android had only a single OpenGL context, so it was destroyed whenever your App went to the background (so that other Apps could then make use of it).
Later versions of Android do have the option to behave more like iOS by calling setPreserveEGLContextOnPause. However for this to work, the Android version has to be 3.x or above (API 11) and the device must support it also.
When it is not used or supported, the App must delete and re-create all it's OpenGL resources when going between background and foreground, which is what your App appears to be doing.
Related
Is actually in the end everything rendered via OpenGL in Android. I have already checked out this video https://youtu.be/zdQRIYOST64 and the relevant documents. And it seems that not all is rendered via OpenGL or maybe Vulkan nowadays. But when it is not rendered via this, how is it rendered, via some internal stuff inside the SurfaceFlinger?
Can someone show up the way through the code from the application level to the very last point before the hardware?
I have asked #Romain Guy on twitter to answer this question and this is his answer
https://twitter.com/romainguy/status/1272314819333337090
Apps are rendered pretty much entirely with OpenGL yes. SurfaceFlinger
avoids using the GPU whenever possible and uses dedicated compositing
hardware instead (hardware composer). But sometimes it falls back to
GL.
For some time I'm creating simple google cardboard vr game. It's one of my first games so I probably dot know many things. My problem is that i was uing standard shader all the time, but recently I noticed that there is mobile shader available. Then when I was browsing through Unity's standard assets i found AutoMobileShaderSwitch script(I suppose it switches between shaders depending on the platform). The thing is that I have been using standard shader all the time and it worked just fine(on my phone).
Is there any reason to use this moblie shader in this case. Maybe it will increase performance sginificatly? Aleso do you know what shoul I do with this AutoMobileShaderSwitch script? Should I just attach it to any gameobject?
Usually what you do is to develop with standard shaders. Don't worry about mobile shaders until you are about to release for mobiles, then you switch the shaders to mobile. By doing this, you will know that the images you see during developing is the highest quality of what your game would look like.
Also, when making your game, always check for the framerate once in a while, on your mobile device. If it gets down to something you consider to be unacceptable for your game, then you can switch the shader to mobile and see if that makes a difference before spending time, optimizing you code.
And yes, mobile shaders will improve performance, especially when using transparent shaders. Mobile shaders are optimized for mobile devices. Basically, things were stripped out from them to make them faster and lighter on mobile devices. The down part of this is that some mobile shaders don't look good like the standard ones because things were removed.
Im porting an iOS game to Android.
Im using as template the GL2JNI example from the latest NDK, and have added inside GL2JNIActivity.java/onCreate mView.setPreserveEGLContextOnPause( true ); to preserve the EGL context but it as soon the device orientation change the screen is all black.
I've research on this and some suggests to reload all textures, shaders, geometry etc... But that is not an option for me (too slow to reload).
Is there any way to handle like on iOS multiple devices orientation using on OpenGLES2 view on Android? If yes how can it be done without reloading everything. I've seen like Unity games doing it... so it must be possible right?
TIA!
I read somewhere that OpenGL context can be restored automatically by libgdx framework. And in my case, everything is OK with the real phone 4.0.3. But when I test with Android 2.x, it doesn't work well, just return me a white blank:((.
Isn't it true that i can leave restoring OpenGL context to libgdx? Could you please share your experiences with this? Or libgdx just can't work with Android versions lower than 4.x?( I use Opengl 1.0).
See http://www.badlogicgames.com/wordpress/?p=1073. The post is from 2010, and so it talks in about some future features that are now current (TextureAtlas and TextureRegion), and the point of the article is about how dynamically generated textures cannot be automatically managed by libGDX, but implicitly it describes the texture management problem, and how libGDX can be used to solve it in certain cases (basically libGDX needs to know how/where to reload your texture from).
libGDX should work fine on Android 2.x or 4.x.
Are you sure the underlying process is hanging around in both the 4.x and 2.x Android cases? Texture lossage is only a problem when an Activity exits and the Application stays alive until the Activity is restarted. If the Application exits, everything is re-initialized.
I am almost done creating a game for android using a port of irrlicht 3d engine to android.
All code except a minimal frame work to make the native calls and play sounds is written in C++.
Even the opengles display is created in c++ code using eglGetDisplay and eglCreateWindowSurface
The problem I need to solve is that when home is pressed then relaunch the game the screen is all white.
From other answers I have found that the opengl context is lost then recreated when onSurfaceCreated is called. I thought that I could just reload textures but that seams to work for only some textures. Also the background color is changed which is not a resource.
It seams I would have to completely restart the game but this could be really annoying to a user.
the port of quake 3 has notes about this problem be has no solution.
Is there a example anywhere of a game written in native code which correctly handles this situation?
The way I handled the situation is to recreate everything. I made sure that all generated stuff like textures and buffers where deleted before recreating everything as if it happened for the first time.