Ran the update, seems same error on both devices.
Note2 starts up the music but hits the exception before I see and other graphic. "Thread[GLThread 35814,5,main] com.jme3.renderer.RendererException: An OpenGL error has occurred: out of memory …
Ill try to get ADB working to see if I can get proper stack traces.
The Tab3 10 gives pretty much the same error BUT does not occur until I start the game, just before the swirling text aligns as before.
Something comes to mind!
I had a similar error, and it turns out the textures I was using were too large!
Try and resize your textures down to 256x256 or less, and see if that will help!
Also, I hang around in the #jmonkeyengine irc, for faster communication
@BigBob said: @t0neg0dSomething comes to mind!
I had a similar error, and it turns out the textures I was using were too large!
Try and resize your textures down to 256x256 or less, and see if that will help!
Also, I hang around in the #jmonkeyengine irc, for faster communication
Ohhh! Hey! That might do it. Anyone know a way of determining what the texture size cap for different devices are? I’d like to swap them out accordingly.
@radanz said: @t0neg0dRan the update, seems same error on both devices.
Note2 starts up the music but hits the exception before I see and other graphic. "Thread[GLThread 35814,5,main] com.jme3.renderer.RendererException: An OpenGL error has occurred: out of memory …
Ill try to get ADB working to see if I can get proper stack traces.The Tab3 10 gives pretty much the same error BUT does not occur until I start the game, just before the swirling text aligns as before.
- Radan.
If @BigBob is correct this would mean that the texture cap for the Tab3 is 512x512 (the font texture size). The next atlas is 2x that size.
EDIT: I just rechecked the image size. I lied. Nothing is bigger than 512x512. This may not be the issue after all.
From everything I can find on the subject, limiting your texture size to 1024x1024 max is safe for older devices. I need to see if I can track down how you force the opengl version in JME. I’m setting this in the android manifest, but I don’t think it is effecting the renderer.
EDIT: On a side note, the smaller Samsung tablet I tested it on was Tab 3. Wonder why that one worked.
I’m certain that my device will not run a 1024x1024 texture as that was the size I had to resize them down from.
@t0neg0d said: From everything I can find on the subject, limiting your texture size to 1024x1024 max is safe for older devices. I need to see if I can track down how you force the opengl version in JME. I'm setting this in the android manifest, but I don't think it is effecting the renderer.EDIT: On a side note, the smaller Samsung tablet I tested it on was Tab 3. Wonder why that one worked.
the Tab3 10" is the only x86 model using the atom
the Tab3 7" & 8" uses the normal ARM type procs so the firmware would be very different.
Ok well that’s just bizarre…
I enabled the Developer options on the Note2 and enabled ADB debugging as well as Enable OpenGL traces on “call stack on glGetError”
Now the game is running fine…
soo works for developer and not on normal? freaky…
–Radan.
Edit: Confirmed, Enabling the OpenGL traces on “call stack on glGetError” causes the game to work on BOTH my devices… maybe it captures the error somehow and prevents the crash?
Ok, even though the game is working I’m seeing errors on the logcat:
I used adb shell then logcat | grep “E/”
the “E/AudioResampler( 1995): Unsupported sample format, 1 bits, 1 channels” lines occurred every time a ‘shoot’ sound played from either the player or the enemy.
thought it may help.
–Radan
Ok… I’ll review the sound files and see if I saved them in a weird format.
Is this what was causing the oom exception? Or? because I don’t see anything other than this.
@radanz said: Ok well that's just bizarre...I enabled the Developer options on the Note2 and enabled ADB debugging as well as Enable OpenGL traces on “call stack on glGetError”
Now the game is running fine…
soo works for developer and not on normal? freaky…
–Radan.
Edit: Confirmed, Enabling the OpenGL traces on “call stack on glGetError” causes the game to work on BOTH my devices… maybe it captures the error somehow and prevents the crash?
@nehon @iwgeric Does this mean anything to either of you? The original error is an oom error that looks like it is related to OGLESShaderRenderer.updateBufferData… then setVertexAtrrib… Why would enabling the above make everything work ok?
My guess is it just swallows the error before the app can crash, which makes the error more odd.
here’s a logcat from the note2 with the actual crash.
hope it helps, let me know if I can provide any more, I’m good with console stuff but never gone into depth with android, its still on my ‘todo’ list.
cheers.
-radan.
@radanz said: My guess is it just swallows the error before the app can crash, which makes the error more odd.here’s a logcat from the note2 with the actual crash.
hope it helps, let me know if I can provide any more, I’m good with console stuff but never gone into depth with android, its still on my ‘todo’ list.
cheers.
-radan.
That’s pretty weird.
Only think I can think of is that when you enable debug mode, android allocate more memory to your process to make for the debugging overhead…but that’s just a guess.
From the posts here I can’t see if it’s a java OutOfMemoryException or if it an opengl out of memory error.
Those are quite different cases.
For information, my last released game on android was tested on Nexus 5 Nexus 4, galaxy nexus, nexus S, nexus 7 nexus 10, Samsung galaxy S3, galaxy tab, asus transformer. All was working smoothly…
First person that bought the game (was a friend of mine :p), has a Samsung galaxy S5 and the game systematically crashed with a java oom on start. We then found out that the Galaxy note 2 had the same issue.
We fixed the issue by reducing texture sizes too… That’s just a shame that we have to do this for most recent hardware on the market…
Samsung seems to be to the mobile game dev world what AMD/ATI is for the desktop game dev world…a pain in the ass.
EDIT : I just tested the game on Sony Xperia Z2 tablet and it works fine
@nehon said: That's pretty weird. Only think I can think of is that when you enable debug mode, android allocate more memory to your process to make for the debugging overhead....but that's just a guess.From the posts here I can’t see if it’s a java OutOfMemoryException or if it an opengl out of memory error.
Those are quite different cases.For information, my last released game on android was tested on Nexus 5 Nexus 4, galaxy nexus, nexus S, nexus 7 nexus 10, Samsung galaxy S3, galaxy tab, asus transformer. All was working smoothly…
First person that bought the game (was a friend of mine :p), has a Samsung galaxy S5 and the game systematically crashed with a java oom on start. We then found out that the Galaxy note 2 had the same issue.We fixed the issue by reducing texture sizes too… That’s just a shame that we have to do this for most recent hardware on the market…
Samsung seems to be to the mobile game dev world what AMD/ATI is for the desktop game dev world…a pain in the ass.
EDIT : I just tested the game on Sony Xperia Z2 tablet and it works fine
When you had to reduce the texture sizes, how many textures is your app using and what was the final dimensions you had to go with?
EDIT: Currently I don’t have anything over 512x512. I’m wondering if I was to condence the entire app into a single 1024x1024 texture if this would be ok… or do you think it is the single texture dimensions that is more important?
EDIT 2: I’m also loading more than 8 textures (11 I think though 1 is never sent to the GPU, it’s used as a pixel mask for the 2D emitter shape), which I have read can be problematic due to texture swapping.
I wonder if its in the hardware or the firmware and yes Samsung is an issue, the Samsung 4.2.2 firmware has a well known wifi bug that has griefed me no end, I was overjoyed when 4.3 was released as it fixed that issue.
I wonder if anyone with a note2 wants to install CyanogenMod and test these issues… I’m tempted, don’t know if I want to take that path again myself…
@radanz said: the Tab3 10" is the only x86 model using the atom the Tab3 7" & 8" uses the normal ARM type procs so the firmware would be very different.
Ah… this would explain it. The one I tested on was the 7". It had a pink sparkly case too… which may have had a positive impact on running game… erm… or not.
@t0neg0d said: When you had to reduce the texture sizes, how many textures is your app using and what was the final dimensions you had to go with?EDIT: Currently I don’t have anything over 512x512. I’m wondering if I was to condence the entire app into a single 1024x1024 texture if this would be ok… or do you think it is the single texture dimensions that is more important?
EDIT 2: I’m also loading more than 8 textures (11 I think though 1 is never sent to the GPU, it’s used as a pixel mask for the 2D emitter shape), which I have read can be problematic due to texture swapping.
Unfortunately I don’t think there is an absolute rule for the size. We were generating images for the ingame gestures and we just reduced their size. WE have a 10241024 background, the characters textures are 512512 (diffuse + normal) and 256 * 256 for specular.
Other than that we have plenty small icons, and so on…
@nehon said: Unfortunately I don't think there is an absolute rule for the size. We were generating images for the ingame gestures and we just reduced their size. WE have a 1024*1024 background, the characters textures are 512*512 (diffuse + normal) and 256 * 256 for specular. Other than that we have plenty small icons, and so on...
Thanks for this info! I’ll give the single atlas a shot first and see how it fairs on the Note 2. If that is unsuccessful, I’ll try reducing all the existing images as some just don’t need to be as large or detailed as they are and try that route.
LG Nitro HD (P930) with CM 10.1.3 (Android 4.2.2)
NullPointerException… Stack trace:
