Severe graphical glitches on SPH-M900
Monkey Targets Forums/Android/Severe graphical glitches on SPH-M900
| ||
| Hello, I'm not sure if this is a bug, or a configuration, compilation, or code error on my part. However, since around the time Mark implemented the new graphics engine for Android, none of my code examples (including a previously-working example) are displaying properly. I've uploaded demos and used DDMS to try to determine the source of the problem to no avail. I'm using a stock version of this device, and it should meet the minimum requirements (GLES 1.1 and 2.0 are supported, and the OS is Android 2.1 API Level 7), so I'm not sure what's going on. Here are the examples. No scaling was done nor attempted in these examples; the code accepts whatever the device size is. nbFontTest: Perhaps the simplest example, it uses DrawText and a custom font I created to display some characters on-screen. What it should look like: http://nobuyuki.gpknow.com/lab/nbFontTest/ What it looks like on my device (captured from DDMS):  What looks like is going on: Texture surfaces for the font image are being improperly scaled by some tiny amount, causing bilinear bleedover from other characters. ballTest: This example uses DrawImage and SetColor to display some bouncing balls on-screen. What it should look like: http://nobuyuki.gpknow.com/lab/ballTest/ What it looks like on my device:  What looks like is going on: Lots of flicker; the balls only appear sometimes and show up some frames as glitches. Accessing undefined memory space? VecTest: This example uses DrawLine and DrawCircle to display elastic collisions with vector maths. DrawText is used to composite numbers on each ball. What it should look like: http://nobuyuki.gpknow.com/lab/VecTest/ What it looks like on my device:  What looks like is going on: I have no idea. This one is completely broken! Those filled blue shapes move around a bit, possibly anchored to one of the bouncing balls, but that's all that's displayed, if anything. When switching back to this app, sometimes Cls blanking shows white bg instead of black (!) Some more information about the graphics processing on my device (Samsung Moment): It's based on the S3C6410, a samsung-built ARM11. 3d acceleration should be built-in (again supports OpenGL ES 1.1 / 2.0). Devices which use this processor... http://pdadb.net/index.php?m=cpu&id=a6410&c=samsung_s3c6410 Anyone else have a model similar to this? I've tested these builds on the reference emulator, and had a friend test it on a Nexus S. Both builds work just fine. I'm guessing not many people have had this problem, or there'd be more reports... Still, this was a very popular device at one point, and I really don't want to exclude it from the manifest if it's an issue in mojo that can possibly be resolved... Moreover, it's hard to test my builds on the emulator :) I appreciate any input you guys can offer ! |
| ||
| Can you possibly share one of the projects so that others can look them over and try them on their devices? |
| ||
| Certainly. I've only included 2/3 of the examples here, since VecTest contains some code I'm working on for a game. Also, of course the graphics in here aren't free-to-use in other projects. Other than that, I'm sure there's nothing in here no one's ever seen before. BallTest was my first time using Monkey, so the code there might be sloppy. nbFontTest is much more succinct. I'm presuming the graphics code for VecTest could be replicated easily with some simple DrawCircle calls (I may attempt to do this and make another version of ballTest later with screenshots, but anyone should be able to try it). http://nobuyuki.gpknow.com/lab/monkey_demos.zip |
| ||
| Is there any particular reason you're loading the ball image 11 times in OnCreate, then once every frame if you're left clicking/touching the screen? That's a lot of object spam right there. I'd expect the app bogs down really fast on Android if you're touching the screen. |
| ||
| Meanwhile, back on topic... They work fine on my ZTE Blade, which doesn't help except to add another data point. Is it just your examples that are not working for you or do you get similar issues with the standard Monkey examples in the bananas folder? What about other Android games? Also, is the Samsung Moment known for compatibility issues? I noticed this on the Wikipedia page: "As of the latest Android 2.1 build DJ07, the Samsung Moment, the Samsung Intercept, and the Samsung Transform (all based on the same SoC) do not include support for OpenGL ES 1.1 or 2.0 (in Android 2.2) despite hardware support for it." |
| ||
| @muddy_shoes: Meanwhile, back on topic... How was that not on topic? LoadImage is part of an optional parameter in the Sprite constructor. The loop in OnCreate passes no arguments, so LoadImage is being called 10 times there. It's then being called once every loop if you're touching the screen, since MouseDown is being used rather than MouseHit. Admittedly the objects returned are being overwritten with ballImage, but loading the image multiple times could be wreaking havoc. |
| ||
| "Maybe your phone is having a problem with the repeated LoadImage calls." would have been recognisably on topic. A post just pointing out a performance issue in obvious test code isn't. |
| ||
| Is there any particular reason you're loading the ball image 11 times in OnCreate, then once every frame if you're left clicking/touching the screen? That's a lot of object spam right there. I'd expect the app bogs down really fast on Android if you're touching the screen. At the time that I wrote that demo, I wasn't totally clear about how to prevent null references on object instantiation. The code hasn't been updated since it was first written since I don't have much use for the code anymore. I think I mentioned this in a previous post that it was my first Monkey app, and it is indeed off-topic to focus specifically on that piece of code specifically, especially if it detracts from the more serious issue. Removing the default arguments from the constructor probably wouldn't do much to fix the real problem I'm having -- the image:Image=LoadImage("ball.png") was, iirc, some piece of fudge code added to prevent a null reference at runtime which I never managed to properly debug. |
| ||
For the sake of keeping on-topic, here is also a screenshot of what \bananas\mak\mojotest\mojotest.monkey appears like on the device: the screenshot is slightly deceptive -- it shows a flickering white and blue box on-screen which changes in size according to its clipping rectangle. DDMS captured the image over several frames for some reason, based on what part of the screenshot you're looking at vertically, which is why it appears to stagger a bit. Also, is the Samsung Moment known for compatibility issues? I noticed this on the Wikipedia page: "As of the latest Android 2.1 build DJ07, the Samsung Moment, the Samsung Intercept, and the Samsung Transform (all based on the same SoC) do not include support for OpenGL ES 1.1 or 2.0 (in Android 2.2) despite hardware support for it." arrrrrgh. Say it isn't so :( I have found this project which explains some of the problem (and more details): https://github.com/tom3q/openfimg/wiki This is apparently not just limited to Monkey, but to practically all games which utilize OpenGL ES on the device. I imagine there are many games which must exclude my device from the manifest as a result.... how disappointing.. |
| ||
| It's a pity Mark removed support for Canvas, then. It might be possible to retrofit the original Canvas code and make a new target for it. |
| ||
| Perhaps, although it would seem that there's a reason this device was discontinued, I suppose. At least 2 other phones use the same System-on-Chip that are still being sold, however. I'm not sure how many people would use these devices to be worth re-implementing Canvas, but it looks like I'm due for a new phone anyway this week :3 It might be helpful for Mojo to specifically exclude the Moment, Intercept, and Transform inside the manifest file, or at least have a comment in there to allow easy exclusion, if it turns out that these devices can't be supported. I would've figured the programs shouldn't run at all, but again, the device driver may be misrepresenting its OpenGL capabilities to the OS :\ |
| ||
| Hi, I've recently been investigating a VERY similar graphical corruption issue with a T-Mobile G2 Touch (aka HTC Hero), with Android 2.1 It's had me completely stumped, so I'm glad to find that I'm not alone :) Everything works fine in the emulator, but on the physical device I get exactly the same flickering/corrupt images as shown in that "balltest" pic above. I've just tried the same "mojotest" sample, and although I don't get the flickering white/blue box, I only see the outer dark blue expanding/contracting rect. The spinning inner contents (wireframe + images) are simply not there at all (completely black background). Apologies I don't have an image - can't seem to get DDMS to recognise my device. I've also put together a little app, similar to the "balltest" above. See below for the code. It's not doing anything special at all, but this gives the same flickering (of both the text & the image itself). It's almost as if every so often, one of the images being displayed is switched out for some random part of memory (so distorted parts of other images are drawn instead). In this case, the image appears to sometimes be replaced by what looks like a skewed part of the font image (just for an odd frame, a few times per second). Interestingly, if I comment out the DrawText() the flickering goes away. However, in other cases I've seen the same flickering on this device when I'm not using DrawText(). I'm not sure where to find further details of the hardware in this device, but could it be a similar problem? The graphical corruption certainly looks identical. Any suggestions for workarounds, or is it down to the inner workings of Monkey? The plan was to use this as a low-end test device, so hopefully there's a way to get things working on it... Thanks! Strict
Import mojo
Global x:Int=50, y:Int=50
Global dx:Int=5, dy:Int=2
Global img:Image
Function Main:Int()
New MyApp
Return 0
End Function
Class MyApp Extends App
Method OnCreate:Int()
SetUpdateRate(60)
img = LoadImage("image.png")
If img = Null Then Error "Can't load: image.png"
img.SetHandle(img.Width()/2, img.Height()/2)
Return 0
End Method
Method OnUpdate:Int()
x += dx
y += dy
If (x < 0) Or (x > DeviceWidth()) Then dx = -dx
If (y < 0) Or (y > DeviceHeight()) Then dy = -dy
Return 0
End Method
Method OnRender:Int()
Cls 0,0,0
DrawText Rnd(), 0,0
DrawImage img, x,y
Return 0
End Method
End Class |
| ||
| try using power of 2 images only, and that includes mojofont.png I dont think its power of 2, try using an alternative font |
| ||
| Thanks for the suggestion slenkar. I've just tried using a custom 128x128 image as a font. The other image I'm using in my example is 64x64. Unfortunately I'm still getting the same results on the HTC, except now I can see more clearly what is happening... Every so often (just for a couple of frames every second) the moving "image.png" isn't drawn. Instead (just for those frames) it is drawing a shrunken version of the entire font image in it's place. The font image is being scaled to the exact dimensions of the image that should have been drawn. This was kind of difficult to see before since the built-in mojo_font is a very wide strip - so it just appeared as garbled black & white pixels when squished up. Not sure if that info might help track down what's going on behind the scenes... EDIT: One thought... should it matter which version of Java SDK I'm using? Currently on jdk1.6.0_21 - haven't tried jdk1.6.0_23. The config.winnt.txt seems to look for either (or even jdk1.6.0_19) so assume it doesn't matter? EDIT: Just to add, I've noticed the following appearing (twice) in the output when building for Android - not sure if it's relevant... [setup] Android SDK Tools Revision 11
[setup] Project Target: Android 2.2
[setup] API level: 8
[setup]
[setup] ------------------
[setup] Resolving library dependencies:
[setup] No library dependencies.
[setup]
[setup] ------------------
[setup]
[setup] WARNING: Attribute minSdkVersion in AndroidManifest.xml (3) is lower than the project target API level (8)
[setup]
[setup] Importing rules file: tools\ant\main_rules.xml |
| ||
| EDIT: One thought... should it matter which version of Java SDK I'm using? Currently on jdk1.6.0_21 - haven't tried jdk1.6.0_23. The config.winnt.txt seems to look for either (or even jdk1.6.0_19) so assume it doesn't matter? I'm pretty sure Monkey only needs a reference to Java so it can call Ant. Android doesn't actually use the Java SDK at all. |
| ||
| I've re-built my little test app from above using Monkey v42b, and can confirm that this issue didn't exist then. The gfx render perfectly, without any flickering/glitching. So, it looks like I'm experiencing the same issue as Nobuyuki with my HTC Hero. I'm guessing this is related to these changes from VERSIONS.txt ***** V43 ***** Modules: ...[snip]... Android mojo now requires GL1.1. ...[snip]... Trans (1.16): Added 'uses feature gl1.1' to android manifest ...[snip]...So, this seems to be affecting at least the following devices (and possibly more we aren't aware of yet)... T-Mobile G2 Touch (aka HTC Hero) various Samsung devices including... Samsung Galaxy Spica (GT-i5700) Samsung Moment Samsung Acclaim Samsung Intercept Samsung Galaxy 3 (GT-i5800) Is it perhaps feasible that some workaround might be built into Monkey? Seems a shame to not support all those devices when it was working nicely just a few versions ago. EDIT: Also, just noticed this in VERSIONS.txt - maybe related..? ***** V43 ***** ...[snip]... Implemented VBOs in android mojo. |
| ||
| Sorry guys, just realised I made a mistake earlier with testing this on various versions of Monkey... The flickering/glitching is actually NOT present when built with Monkey v43 on this HTC Hero - but definitely is with versions 44 through 45c Perhaps this is more of a general bug introduced with v44, somehow just related (or maybe completely separate!) to the GL 1.1 stuff? The only thing that looks relevant in VERSIONS.txt for v44 is... ***** V44 ***** ...[snip]... mojo.graphics - Tweaks all round, and fix for android 16bit 1555 fmt textures.A little vague, so not sure if that could be it. Nobuyuki, perhaps your code works ok on v42b/43 too? |
| ||
| Indeed. I haven't tried it since upgrading, since I don't keep multiple Monkey versions on this machine, but the programs did seem to work (albeit with lots of small starts and stops) around that time period. When I upgraded based on that "fix" I started seeing graphical glitches which I thought would be fixed by the next version, but unfortunately they never went away. Based on the responses in this thread, I've come to the conclusion that it is because the devices are no longer supported by mojo/trans :( Anyway, whatever all the aforementioned devices have in common, I am wondering if they are easy to exclude / provide an alternate APK for in the manifest. If they are reporting that they support the same sorts of hardware features that devices which are working have in them, then we kinda have a bigger problem. For these things, I wish someone with better knowledge on the subject would come forward with any insight... Edit: P.S. Since starting this thread, I have purchased a Nexus S for the specific purpose of continuing Monkey development on the Android platform. I didn't really want to have to do that, but seeing as this is a serious project, I didn't have much of a choice <:) It is a nice phone for the price, incidentally, but I'm sure there's still tons of people out there with older handsets that may not be supported by Monkey games using the new renderer... |
   |