Does anybody know what the deal is with declining support for the WebGL extension OES_texture_float on Android over the years?
https://webglstats.com/webgl/extension/OES_texture_float?platforms=000000000010000400
Is this a data collection error of some sort, or is the support really declining?
If you take Android out of the filter then `OES_texture_float is supported on basically 100% of the other mainstream mobile and desktop platforms:
https://webglstats.com/webgl/extension/OES_texture_float?platforms=000036048004003200
declining support for the WebGL extension OES_texture_float on Android over the years?
There are a large numbers of OpenGL ES 2.0 parts shipping which simply don't support floating point texturing (all of the Mali-4xx series, for example).
It's a core feature in OpenGL ES 3.x, so I suspect a lot of mobile vendors don't expose the extensions and just expect people to switch to a newer API which has all of the new features as part of the core spec rather than supporting them piece-meal. Given WebGL 2 is now published, this seems a sensible approach to me as it guarantees some level of cross-platform portability ...
Related
What's the currently supported version of OpenGL ES in WearOS 2? Ist OpenGL ES 3.x supported, assuming the hardware can support it? I can't find any documentation for it.
According to the Play console, Wear OS devices do support GL ES 3.0. Here's a screen grab from the device page for the Huawei Watch 2 on my console:
Given that Wear OS is Android under the hood, you can usually assume that anything not obvious or documented to be different is the same. So yes, it probably is going to be whatever the hardware supports.
My question is - is it possible to compile a C++ library that uses some desktop features on mobile device - in this particular case the Irrlicht Engine? I know there is a port out there that uses OGLES drivers, but it also combines using the NDK. I would like to know if there is a possibility to build that library with such a tool like CCTools despite the fact that mobile devices use OpenGL ES - maybe some kind of equivalent libraries, that fit both mobile and desktop environments? There may be some incompatibilities, I know.
The system of input and output doesn't matter at the moment.
And of course - I haven't found the question that fits my expectations.
I wrote an article about porting desktop OpenGL apps to Android that might help:
http://software.intel.com/en-us/articles/porting-opengl-games-to-android-on-intel-atom-processors-part-1
I don't see the advantage of using CCTools rather than the NDK. I think the differences between OpenGL and OpenGL ES would be the biggest problem.
I have spent a few dozen man hours searching Google and asking questions on forums trying to figure out whether or not my OpenGL ES 2.0 application on Android is lagging due to errors on my end, a virus on my device, OpenGL implementation on Android, or OpenGL implementation on the Samsung Galaxy Express.
I have found nothing, if anyone wants to try answer that root issue I would greatly appreciate it, but my question is if I should revert back to OpenGL ES 1.0 and if that is what everyone else uses.
The exact same application (single spinning triangle) using the exact same timestep with the only difference being a barebones OpenGL ES 1.0 vs OpenGL ES 2.0 change causes stuttering in the 2.0 app and smooth animation in the 1.0 app.
Do other games only use 1.0? If they use 2.0 can you point me to an example that is known to cause no noticeable stuttering, that I may download and test on my device? I have downloaded the OpenGL ES 2.0 sample from Google themselves, stutters the same.
Does Samsung Galaxy Express not handle OpenGL ES 2.0 gracefully? Is there any way to get another Android device without stealing or asking random strangers, I have no money.
Thank you.
Thing is that OpenGL ( not just ES ) is a specification, the other part the implementation is not governed by anyone, well by the specification to a certain extent meaning that the implementations can differ greatly altho they shouldn't.
This is due to the fact that OpenGL uses client drivers to handle the commands and those are written by the GPU creators ( usually ). For PCs you can easily name all the prominent GPU builders, nVidia and ATI so there you can at least know what to expect.
For phones there are lots of GPU/CPU combos so more errors to be discovered due to faulty or wrong form the start designs, not just the GPU's drivers, since the phone's creator may also make changes to the system or use low speed/grad parts which will result in poor performance.
OpenGL ES 1.0 I would say is more common since 2.0, mainly because it's backwards compatible so a device that supports 2.0 will most certainly support 1.0 as well. For development you can skip the whole "build on phone" thing by making a framework and using an emulator ( OpenGL ES ) on PC and when you are done just copy over your OpenGL code into your phone app.
Since manufactures try to keep their costs low, they tend to lie about what they actually do, or support so ES 1.0 being more simple and hard-wired than 2.0 it is possible that the lag may be due to the poorly supported OpenGL.
According to the latest Android Platform Dashboards, Open GL 2.0 makes up 98.3% of devices that visited the Play Store in the last 7 days, making it the standard for game development.
I have noticed a lot of people seem to have trouble with the OpenGL ES drivers for Samsung Android devices. You should try another device with a different graphics core.
Since Ice Cream Sandwich, the Android platform itself mostly uses OpenGL ES 2.0, including major components, such as the SurfaceFlinger. It's not optional anymore. Check out this article.
I need to get an idea of how many potential installs I'll be loosing if I choose to do my drawing in OpenGL instead of android's native 2D graphics APIs in android.graphics.*
The android documentation seems to imply that the OpenGL ES API is supported basically on all phones: http://developer.android.com/guide/topics/graphics/opengl.html
OpenGL ES 2.0 is supported by most Android devices
Now, does that imply that even cheap commodity devices will have OpenGL ES 2.0 support? Will the cheaper phones perhaps have software rendering, or will it always be hardware rendering?
I take it that the documentation's wording of "most android devices" means that there may indeed be some phones which are running android-8, but just don't have the hardware for OpenGL ES 2.0. But how many phones is that exactly?
Check the Device Dashboard by OpenGL ES version.
I am planning to develop a game for all of the mobile platform and have pretty much zeroed down on the concepts of the game. but the only issue I'm facing as of now is that I have no idea what would be the best libraries + 3d Engine to us to achieve the best results on the hardware on some of the upcoming mobiles. I'm talking about the iPhone 3GS, the new WinMo and Android devices with the famed Snapdragon, other processors from Samsung, ARM, Qualcomm and even Intel and AMD.
as of now i plan to use the ogre libraries for now, but then what will offer portability?? This is much more of a design question rather than just coding. Any help is appreciated, others who wish to collaborate are very much welcome too. just drop me a mail.
I don't know much about Window Mobile, but (right now) there is a barrier to compatibility between Android and the iPhone: managed vs. native code. Android highly encourages you to write in Java, whereas the iPhone requires Objective-C or C++ (or C). Though Android does have a native development kit, they don't currently expose many libraries. They will add more APIs over time, but the Android devs will continue to encourage Java development, since Dalvik bytecode will run on any new device.
This is just my opinion, but I would focus on just one platform at the start. Pick your primary platform, write your core game code in portable C++ if you can, and keep the platform-specific parts separate from your core game code. Your goal is to get your game published. Once you have some money coming in, then start focusing on your second platform's port.
I would recommend you to use OpenGL ES and STL. Both Android and iOS platforms become more compatible with OpenGL and STL library, and it looks like every other mobile platform would follow this course (except, perhaps, Windows Phone 7.)