Has anyone ran into problems with Opengl textures on Froyo 2.2, cant seem to get the textured triangle sample to display a texture on my 2.2 nexus one, works fine on the 2.1 emulator. But when I build and run the API demos from the SDK and select the texture triangle it works fine, this is driving me crazy why the same code doesnt display any textures if it’s built as a standalown app. I have tried adding ‘nodpi’ and ‘drawable’ dir’s with the texture images too.
Oh I'm pretty sure it worked fine when my nexus one was running 2.1.
Thanks
Think I solved it, i will post the fix later.
So what was the problem? I'm experiencing this to. I noticed the issue happens if I have ndroid:anyDensity="true" in my app manifest, but if I use anything else, I don't get the full 800x480 screen resolution available to me.
Same issue is happening to me as well. My little opengl 2D test app ran fine in my Nexus 2.1 and after upgrading to 2.2 textures are completely white. Would you please tell us what was your problem?
Thanks!
I think I have your solution.
First, as people may already know, to get the full resolution you want <supports-screens android:anyDensity="true" /> in your application manifest.
The textures are white because when you load them from a Bitmap, android has resized them and the resizing has made them a size that is not a power of 2, so it borks when you load the texture into opengl.
So how to you stop Bitmap from doing that?
create a folder in your "res" directory called "drawable-nodpi" and move your images in to that folder and the system will stop resizing them.
this is only an issue if you are using resources, if you load your images from assets or some other place, then I don't think the system resizes them.
Hope this helps, it worked for me.
-James
Hey James, thanks for your insight
However I just did as you said but I'm still getting the same result. I never used power of 2 textures and they were perfectly rendered; I'm guessing GLUtils.texImage2D already does the dirty work.
anyDensity is set to true, bitmaps are inside drawable-nodpi, all screens are set in SupportedScreens... dunno; I'll guess I'll try to load the texture from elsewhere, not the resources, and see if I can pinpoint the problem.
Hi,
I almost forgot to post here. All James said is true and doing as he said (and using power of 2 widths & height for textures) made it work, but a special circumstance was blurring my point of view here.
The circumstance is that NPOTs seem to be supported in Nexus One with Android 2.1, but not 2.2. Why this support was removed remains a mystery to me
Sorry about not posting what I found and I dont have thread update email reminders turned on. All I did was strip down the api demo (which works) to just a single project and used it as a template.
Ok im trying to set my program to use OpengGL and i have some questions to thos who know more then i.
Right now my main question is if the Render.OnDrawFrame() is run in a continous loop? I have looked through the official documentation but it doesnt say much. And from this is anything drawn in this function immediately drawn to teh screen? or it as if there was swapbuffer at the end?
Next if i were to do all drawing natively could i simply bypass using the Rendering class all together and manage everything myself?
Well, this thread is a little old, but it's still open and I'd like to discuss a little openGL too.
The Renderer is like a separate thread, once you set the renderer object it will run based on what you define with the setRenderMode(int) method.
From the Android decumentation:
Rendering Mode
Once the renderer is set, you can control whether the renderer draws continuously or on-demand by calling setRenderMode(int). The default is continuous rendering.
Click to expand...
Click to collapse
Managing all the rendering by yourself, without using the standard classes, might be vary challenging. But you don't need to do this to draw natively, there are ways to access native code inside the renderer.
In fact, each gl method call is a native call, you can have a nice performance boost by making only one native call inside the renderer.
Balosen said:
Well, this thread is a little old, but it's still open and I'd like to discuss a little openGL too.
The Renderer is like a separate thread, once you set the renderer object it will run based on what you define with the setRenderMode(int) method.
From the Android decumentation:
Managing all the rendering by yourself, without using the standard classes, might be vary challenging. But you don't need to do this to draw natively, there are ways to access native code inside the renderer.
In fact, each gl method call is a native call, you can have a nice performance boost by making only one native call inside the renderer.
Click to expand...
Click to collapse
Very old indeed!
Yes that is exactly what i did actually. in my onDrawFrame() i call a native method where i do all of the actual drawing(had alot of pre-existing code that made this more practical).
Weeds2000 fixed the orientation on our Folio100 to work with games like Asphalt5 and now its possible to play, although graphics are still kinda messed up. but other games like the 3d tilt works nearly perfect now too.
you might find it useful, and VEGAn mod might be able to include this as my FolioTntMod is based of the TNT framework...
Find the download patch i made for our folio in this thread.
it also include a full 360 rotation fix, if you need it
As we all share the same Tegra2 platform and can nearly swap experience here, im posting this to share the fixes weeds2000 made for us...
Hope you find it useful..
Note:
The patch i made might actually work fine as update.zip on your tablet as well, or might need minor adjust to install, but let g tablet modders fix this if needed.
at least now you know its available.
Thank you! One question - do you know what file(s) were altered for the 360 rotation fix? Was it a lib file, for example?
EDIT: Also, to any other modders looking at this, the system.img is a ext2 filesystem image, NOT a yaffs2 image.
roebeet said:
Thank you! One question - do you know what file(s) were altered for the 360 rotation fix? Was it a lib file, for example?
EDIT: Also, to any other modders looking at this, the system.img is a ext2 filesystem image, NOT a yaffs2 image.
Click to expand...
Click to collapse
Roeby wan Kanobi, is this something that could work and be added to TnT Lite? My Clockwork back up just completed
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
Click to expand...
Click to collapse
This could be another watershed update Also- with the accelerometer corrected, folks will be getting exercise by holding up the G while playing games
added:
Perhaps the one extra update that would be nice is a DSP manager so dB level or gain increases can be made. Modders released a DSP manager on the Incredible that allows increases to 3.5mm and speaker output. Hardware based EQ too.
Perhaps being too picky, but louder speakers would be nice.
Did you see.. they provided the SOURCE!!!!! This is what we need!
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
Click to expand...
Click to collapse
What does the patch change? Would is break things when the application developer fixes the orientation code in their game.
We saw this problem fixed in the application in the Gallery 3D application by google, not in framework. http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Click to expand...
Click to collapse
okay here are some details.
the framework.jar modified comes from this file: update-smb_a1002-3338-user.zip
the library should be generic, but is required for the gsensor/rotation/orientation fix as part of the new framework.jar changes.
the 2 primary folders in the framework.jar changed are /android/hardware /android/view
you should be able to easily spot the differences in filesizes..
do note: there is another change android\os\Environment.smali as i modified it to work with /mnt/sdcard and /mnt/sdcard/sdcard-disk0 and /mnt/usbdisk-disk0 for compatibility with folio mount functionality.
here is the "vold" also different but works fine with the tap'n'tap framework.
remember that /etc/vold.fstab needs changed to support the more new mount devices if you wish to use that one too.
360 rotation fix is in android\view\WindowOrientationListener$SensorEventListenerImpl.smali
orientation fix is
android\hardware\SensorManager*.smali
but again, the framework.jar is Tap'n'Tap based, so works directly on top of r3338 edition.. and i made a patch in my section with just framework + lib files included.
rothnic said:
We saw this problem fixed in the application in the Gallery 3D application by google, not in framework. http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html
Click to expand...
Click to collapse
No, as far as i understand, weeds2000 only made the hardware swap sensor reading, so now it acts like a portrait mobile phone, where our Tegra2 has the chip rotated once 90degree.
Dexter_nlb said:
No, as far as i understand, weeds2000 only made the hardware swap sensor reading, so now it acts like a portrait mobile phone, where our Tegra2 has the chip rotated once 90degree.
Click to expand...
Click to collapse
Hmm, so it does a 90 degree rotation. And the device is still a default landscape device. We definitely need to make sure there are no negative effects on games that utilize the acceleromether and worked fine before.
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Thanks for the explanation - this is something I suspected would fix it, but it's good to see that someone had pushed the idea all the way through to an actual fix.
So, I suspect that when the device boots up, it should be in portrait mode initially (until the sensor kicks in).
roebeet said:
So, I suspect that when the device boots up, it should be in portrait mode initially (until the sensor kicks in).
Click to expand...
Click to collapse
That makes more sense to me if that is true.
I read through the code ... Prior to the code change they were performing the rotation either for Acceleration minus Gy on the y-axis
or Acceleration minus Gz on the z-axis and NOT Acceleration minus Gx on the x-axis. Now the axis swap is always occurring... under all 3 conditions irregardless of sensor.
Dont know why there was an exclusion in the first place for Acceleration minus Gx on the x-axis...
When I get back I will look through the code some more...
rothnic said:
Hmm, so it does a 90 degree rotation. And the device is still a default landscape device. We definitely need to make sure there are no negative effects on games that utilize the acceleromether and worked fine before.
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Click to expand...
Click to collapse
rothnic said:
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Click to expand...
Click to collapse
if Google didn't "invent" the different way of reading sensors, there would only be one way of doing it, so developers would not be able to see it, so an update to like 2.2 or higher is now an requirement, right? but if older games do not check, it would work with them, so this fix solves it as i see it.
putting back androidos orientation handling to its original state, as many developers should be reading it.
I have ported the fix for both TnT stock and lite. As well as Vegan beta 4.
http://forum.xda-developers.com/showthread.php?t=892345
gojimi said:
I have ported the fix for both TnT stock and lite. As well as Vegan beta 4.
http://forum.xda-developers.com/showthread.php?t=892345
Click to expand...
Click to collapse
remember its all done by weeds2000 , i cannot/will not take credits for his effort here, i am just sharing the good work done on this fix.
I have released a new version of the fix, this should clean up all the remaining issues with the accelerometer/compass. Code is also much cleaner now. Some weird hacks you may have seen were caused by the legacy API which was used by my test game.
Only known issue up to now is that the mouse coordinates are also rotated.
The source can be found in the zip file attached to the original post, I hope that all changes are prefixed with // XXX:
The source files are based on the nvidia-froyo tree.
Link:
http://forum.xda-developers.com/showpost.php?p=10209624&postcount=38
Doodle jump doesn't work. Game loads upside-down with home buttons on top. If you tilt left you go right...Any fix for this?
Does this work for the VegaN Ginger Edition, or is that fix built into the ROM, I think I am having issues with some games on that ROM.
bmw4aaron said:
Doodle jump doesn't work. Game loads upside-down with home buttons on top. If you tilt left you go right...Any fix for this?
Click to expand...
Click to collapse
I think you can write the developer and tell , that the games is not working normally.. all other games work fine, so why would one game stand out, only reason, bad programming, or misunderstanding of androidOS and orientation. maybe developer thought he should fix the "orientation" in his game on tablet, and forgot other trying to make it reverse.. so: bad programming and choice of developer..he should follow guidelines and not his ideas.
Hi there,
I'm working with nitr8 on an app for his cooked rom for SGS, we are adding ability to change LCD density...
And here goes problem - apps dont scale well. Some of them can be fixed with spareparts, and there is a setting in it, which according to sources (I got them compiled with 2.2 sdk, only two problems discussed here) toggles: Settings.System.COMPATIBILITY_MODE,
however eclipse says: COMPATIBILITY_MODE cannot be resolved or is not a field
Same goes for
Settings.System.FANCY_IME_ANIMATIONS
Rest of spareparts' settings are resolved.
Does someone know how to toggle compatibility mode?
I'm using sdk 7/8 and layoutlib.jar from these two. Nothing works.
I saw this post http://www.greatereader.org/posts/developer/android-3-0-hardware-acceleration_19942.html
And I see that the AndroidManifest.xml does not have this option checked when I decompile it with apktool. I added the value, recompiled but it had an error when installing(no specific error, just said not installed).
Will this fix the 10fps issue on youtube? I figured if you add that argument to the xml file and then build/install flash maybe it would force flash to render on the gpu.
If I'm not mistaken from reading the link (and I'm no developer), it looks like you can keep acceleration turned off at the application level but turn it on as needed for activities or windows. So, you'd have to see the setting on a Xoom or GT 10.1 to know if the TF is configured differently.
Looks Interesting. Any Confirmation?
If I flash the eee pad to PRIME 1.5, will it solve the flash(video) issue?
I'm also interested in this thread. Anyone with thoughts? The Asus implementation doesn't feel like hw acceleration....