hi,
I’d just like to confirm that this IS an outstanding bug, even on the most recent daily build. The issue appears for me on an HTC Incredible device.
Darren [import]uid: 94684 topic_id: 24187 reply_id: 119678[/import]
Ben,
Thank you for posting your test results. I’m glad we were finally able to resolve this graphics issue. I’ll close your case #15389 too.
Regarding the audio issue that you’ve mentioned, if it sounds like it is breaking up or skipping, then that typically means that you are mixing too many audio channels. More than the CPU can handle. You see, on Android, audio channel mixing is CPU bound. So, the more audio channels you mix, the more work has to be done by the CPU to mix the channels together before streaming it out to the audio hardware. That skipping sound indicates that the amount of time it takes the CPU to mix the audio channels is longer than the audio segments themselves. I hope that makes sense to you.
So, the issue here is that slower single core CPUs cannot mix as many audio channels as, say, faster dual core CPUs. Bottom line, you are running into a hardware limitation. The only work-around is to reduce the number of audio channels.
I also recommend that you use the [lua]media[/lua] API for playing sound effects. That API bypassing audio mixing mentioned above… plus it has far less latency too. Only our [lua]audio[/lua] API is mixed by the CPU. The [lua]audio[/lua] API is best used for music and for applying audio effects.
Anyways, I hope this helps!
[import]uid: 32256 topic_id: 24187 reply_id: 120410[/import]
Hi everybody,
I’m also confirming this bug on Motorola Atrix and Motorola RAZR devices. This is a serious bug. Hey, ANSCA people, staffs, help us!!! I’m losing users!! [import]uid: 143834 topic_id: 24187 reply_id: 119706[/import]
If it helps, this bug happens not only when I relanch the app, but when I load any of my spritesheets for the second time. So, if I release memory, unloading spritesheets that are not in use, when I load them back, blank squares are shown.
Guilherme. [import]uid: 143834 topic_id: 24187 reply_id: 119707[/import]
We are still working on isolating this Corona bug because ANSCA refuses to look at the bug until they can be given a very small exact instance of what produces the bug.
Things that seem to be obvious to us:
- It must be a Corona bug as it manifest as different behaviour on different devices using the same code. I.e works fine on some devices and not on others.
- It happens every time the app is run.
- The behaviour is random in that it replaces different things each time.
- It is not limited to sprites. In fact it seems to be objects that are replaced with blanks squares. This means it can be an image, sprite or text object.
- if you push the app to the background using the standard Android home button and then return to the app, the objects that were missing will now be ok, but other objects during this same app session will go missing randomly.
- We are having quite bad sound issues on the same devices that exhibit this bug, but not sure if it is related. Would be happy hear from others on this sound issue.
Ben
[import]uid: 28534 topic_id: 24187 reply_id: 119830[/import]
Hi Josh,
Thanks for the suggestions however we have tried all sorts of things.
* Currently we can’t even get a single mp3 (background music saved as 83kbs) file to play without breaking up and having the game start stuttering while doing so on these devices.
* Using the media API does not help this.
* Disabling all sounds except the music does not help.
Wrong thread for these comments. Just replying to your suggestions. Would be good if this part of the thread could be move to a new thread??
Update:
Just updating here in case anyone comes across this piece of info and finds it useful.
Here is what seems to have given the best compromise for older devices if you are having similar issues:
* Set FPS to 30 in config.lua
* Use the media API for SFX.
We still plan on using the audio API and setting to 60 FPS for newer devices. This of course will mean manually setting which app is for which devices in the Play Store, but I can’t see any other way as one approach is not great for both types of device. We can’t tell what hardware is being run… can we? [import]uid: 28534 topic_id: 24187 reply_id: 120611[/import]
Hmmm… I’m wondering if we added the ability to fetch the number of CPUs the device has would be a good way to “assume” how fast/slow the device is, and set the frame rate based on that. [import]uid: 32256 topic_id: 24187 reply_id: 120752[/import]
That would be very useful.
It would even better if we could see the clock speed too.
I am assuming for a sec that a newer single core, but very fast clock speed phones might be ok at 60fps.
Eg. A HTC Sensation XE & XL clocked at 1.5ghz.
As a side note… Even the Samsung Galaxy Tab, that is the original 7" gt-p1000 with a 1ghz cpu, runs the game fine without any sound issues using 60fps & only using the audio API. So I guess it is not so cut an dry. Perhaps it is also influenced by the combined chipset. [import]uid: 28534 topic_id: 24187 reply_id: 120781[/import]
I don’t think we can fetch processor speed reliably between devices. That’s the problem. The CPU information that I did find provided speed in “BogoMIPS”, which is not a reliable value. It might be this way because mobile processor speed fluctuate on demand in order to conserve battery life. But you’re right, I’m sure that there must be single core processors out there (perhaps the Intel Atom?) that is fast enough.
I looked at Google’s Android source code (which is open source) and they seem to make assumptions about how good the device is based on the amount of RAM. Not that I’m saying that’s the right way to do it, but it’s an interesting observation. Google enables hardware acceleration by default when it discovers that the device has at least X amount of RAM. [import]uid: 32256 topic_id: 24187 reply_id: 120794[/import]
Just having a look at the device specs it seems to be more related to the device chipset perhaps.
For example:
The HTC Desire HD has 768mb ram and still has sound issues.
Where as the Galaxy Tab (original) only has 512mb ram and has no sound issues.
Different chipsets in both of the above examples though.
Galaxy tab is a Hummingbird chipset with a 1Ghz Cortex-A8 CPU & PowerVR SGX540 GPU
HTC Desire HD is a Snapdragon chipset with a 1Ghz Scorpion CPU & Adreno 205 GPU
Maybe not easy solution? [import]uid: 28534 topic_id: 24187 reply_id: 120795[/import]
I’m not really sure what is the best way to determine if the device is “fast” or not yet. This is definitely not a trivial problem. This requires further thought. Nothing is really coming to me at the moment. [import]uid: 32256 topic_id: 24187 reply_id: 120800[/import]
One further update to this:
On rechecking and again and again, I found what seems to be a major cause of the issue we were trying to fix. Did not think to look at this as it was something we already knew to do and been quite careful to avoid doing… So what was it??? It was mixing audio frequencies.
It seems that on a final mix of the music file it was mistakenly saved at as a 44Khz mp3 file, when it should have been 22Khz like the SFX WAV files. We know this and I personally hang my head in shame. This has a big impact on devices that are marginally keeping up, so keep it in mind.
Anyway, with this fixed, the sound is generally ok even using just the audio API and set to 60fps. Yes there is still sound breakup, but we will live with this as it is now minor and not major like before.
Thanks for suggestions and ideas Joshua, it kept me looking at this. [import]uid: 28534 topic_id: 24187 reply_id: 120821[/import]
Oh good. I’m glad you’ve found a solution.
We’ll continue to think on our end on how to best provide information about an Android device’s capabilities so that an app can decide if it should run 30 or 60 FPS, load large or small assets, etc. It’s a nagging issue that affects everyone. [import]uid: 32256 topic_id: 24187 reply_id: 120912[/import]
Everyone,
We have recently discovered an OpenGL driver bug that is common on many HTC devices that can cause the blank images that you are referring to. This explains why this issue only occurs on particular Android devices. Even then, it took very particular circumstances to trigger this issue, making it difficult to isolate and reproduce. That is why it took us so long to resolve this issue.
The next daily build, #882, will work-around this OpenGL driver bug. If you can let us know if this daily build fixes this issue for you, then that would be much appreciated. Thanks! [import]uid: 32256 topic_id: 24187 reply_id: 120373[/import]
That’s good news Joshua.
I have tested a #882 based build on the problem devices that we have:
Nexus One - Tested OK now.
HTC Desire HD - Tested OK now.
HTC Evo 4G - Tested OK now.
Dell Streak - Tested OK now.
So I would say that has fixed this problem, thanks. Which also covers case #15389, but that was not listed in the cases affected on the daily build notes.
Now to find out why sound is really bad and breaking up all the time on these same devices.
Ben [import]uid: 28534 topic_id: 24187 reply_id: 120401[/import]
Ben,
Thank you for posting your test results. I’m glad we were finally able to resolve this graphics issue. I’ll close your case #15389 too.
Regarding the audio issue that you’ve mentioned, if it sounds like it is breaking up or skipping, then that typically means that you are mixing too many audio channels. More than the CPU can handle. You see, on Android, audio channel mixing is CPU bound. So, the more audio channels you mix, the more work has to be done by the CPU to mix the channels together before streaming it out to the audio hardware. That skipping sound indicates that the amount of time it takes the CPU to mix the audio channels is longer than the audio segments themselves. I hope that makes sense to you.
So, the issue here is that slower single core CPUs cannot mix as many audio channels as, say, faster dual core CPUs. Bottom line, you are running into a hardware limitation. The only work-around is to reduce the number of audio channels.
I also recommend that you use the [lua]media[/lua] API for playing sound effects. That API bypassing audio mixing mentioned above… plus it has far less latency too. Only our [lua]audio[/lua] API is mixed by the CPU. The [lua]audio[/lua] API is best used for music and for applying audio effects.
Anyways, I hope this helps!
[import]uid: 32256 topic_id: 24187 reply_id: 120410[/import]
Hi Josh,
Thanks for the suggestions however we have tried all sorts of things.
* Currently we can’t even get a single mp3 (background music saved as 83kbs) file to play without breaking up and having the game start stuttering while doing so on these devices.
* Using the media API does not help this.
* Disabling all sounds except the music does not help.
Wrong thread for these comments. Just replying to your suggestions. Would be good if this part of the thread could be move to a new thread??
Update:
Just updating here in case anyone comes across this piece of info and finds it useful.
Here is what seems to have given the best compromise for older devices if you are having similar issues:
* Set FPS to 30 in config.lua
* Use the media API for SFX.
We still plan on using the audio API and setting to 60 FPS for newer devices. This of course will mean manually setting which app is for which devices in the Play Store, but I can’t see any other way as one approach is not great for both types of device. We can’t tell what hardware is being run… can we? [import]uid: 28534 topic_id: 24187 reply_id: 120611[/import]
Hmmm… I’m wondering if we added the ability to fetch the number of CPUs the device has would be a good way to “assume” how fast/slow the device is, and set the frame rate based on that. [import]uid: 32256 topic_id: 24187 reply_id: 120752[/import]
That would be very useful.
It would even better if we could see the clock speed too.
I am assuming for a sec that a newer single core, but very fast clock speed phones might be ok at 60fps.
Eg. A HTC Sensation XE & XL clocked at 1.5ghz.
As a side note… Even the Samsung Galaxy Tab, that is the original 7" gt-p1000 with a 1ghz cpu, runs the game fine without any sound issues using 60fps & only using the audio API. So I guess it is not so cut an dry. Perhaps it is also influenced by the combined chipset. [import]uid: 28534 topic_id: 24187 reply_id: 120781[/import]
I don’t think we can fetch processor speed reliably between devices. That’s the problem. The CPU information that I did find provided speed in “BogoMIPS”, which is not a reliable value. It might be this way because mobile processor speed fluctuate on demand in order to conserve battery life. But you’re right, I’m sure that there must be single core processors out there (perhaps the Intel Atom?) that is fast enough.
I looked at Google’s Android source code (which is open source) and they seem to make assumptions about how good the device is based on the amount of RAM. Not that I’m saying that’s the right way to do it, but it’s an interesting observation. Google enables hardware acceleration by default when it discovers that the device has at least X amount of RAM. [import]uid: 32256 topic_id: 24187 reply_id: 120794[/import]