android graphic stack ' s library - android

I have spent some time to google information about graphic stack of android. But everywhere I saw pictures like it and text was described it.
http://withimagination.imgtec.com/wp-content/uploads/2013/06/AndroigGFX2.png
But , unfortunately , nothing wrote about names of library which contained this components of graphics stack. Can you help me in it? Particulary , I want to know all about openGL ES calling and library.

OpenGL and OpenGL-ES are industry standard graphics APIs. They're not specific to Android but available on most platforms. They're extensively documented at https://www.opengl.org/registry/ and http://www.khronos.org/opengles/
I'd start by reading the specifications. Also there's an excellent OpenGL tutorial at http://arcsynthesis.org/gltut

Related

Is this possible, GNOME (lib)Clutter with OpenGL ES & Vulkane?

I'm planning to run an app based on (GNOME) libclutter on Android 9 (Pie). I'm quite new to these graphics related stuff, been wondering on these things, so seeking for guidance/direction whatever data that could help me to understand this thing better.
As per the documentation of Android Graphics, Android is using OpenGL ES & Vulkane at low level to render objects. And as per GNOME Clutter documentation, it could be only compiled with mentioned back-end only! (Please check embedded link to for platforms details.)
I don't see OpenGL ES or Vulkane support, So am I missing something on understanding part or it can't be done?!
[Clutter maintainer, here]
Yes, Clutter supports OpenGL ES—it uses Cogl, a library that abstracts GL and GLES concepts.
No, Clutter does not support Vulkan at the moment.
No, Clutter and Cogl do not support Android; there was an experimental port but it has been abandoned in 2012.
Additionally, Clutter is in deep maintenance mode: no new development releases, no new features, and only minimal/security/crasher bug fixes are allowed.
I would not recommend using Clutter in a newly written project.
OKay...after spending few more hours, I was able to figure out an answer! (Yayy..!!!)
As per Clutter Project website: (somehow I had missed this info previously! :p)
Clutter uses OpenGL for rendering (and optionally OpenGL ES for use on mobile and embedded platforms), but wraps an easy to use, efficient, flexible API around GL's complexity.
So, as per my requirement, I should be able to integrate and cross-compile Clutter lib source and compile it.
PS: I will try to integrate & build the libclutter on android 9. Will update this answer latter with additional set of information.
==========================================================================
Update:
As pointed out by #ebassi in another answer, I have dropped the idea of integration and looking forward to directly using Android Graphics stack for the implementation.
Thanks #ebassi...!

JOGL vs OpenGL ES API on Android. Pros&Cons

We are trying to migrate our project from PC version to Android. PC version uses JOGL.
Can anyone explain main advantages of using JOGL in Android application instead of OpenGL ES API?
For example, on PC pros of JOGL are:
In theory you can use it on any platform.
It's more or less integrated with AWT, Swing and SWT.
Also it's some kind of wrapper, so in theory there are some abstractions that make it easier to use OpenGL.
But I can't see advantages of using it in Android, here are the cons from my point of view:
It's another dependency, APK size will be larger.
Some issues that affect both JOGL and OpenGL ES will require more
time to pinpoint and fix.
It's not a silver bullet that would not require some time for
refactoring, since in Android we should use right patterns for
Activities, Services, etc.
JOGL has less tutorials and smaller community that OpenGL ES API
has.
So what's the point of using it in Android project?
You can use JOGL only on the platforms that we support. I confirm that JOGL has a good interoperability with AWT, Swing and SWT (not yet with OpenJFX/JavaFX but we'll improve that when Oracle does the necessary things). Yes there are some nice abstractions but you forget tons of things:
JOGL has its own AWT-free image management. It has a better support of JPEG than ImageIO and it is faster
You can preserve the OpenGL context even when your application is paused and put in background (when you press "home"), it's build-in
You can test your OpenGL-ES code on your computer even though it doesn't replace the tests on a real device
You can use exactly the same OpenGL code on desktop and embedded environments, especially if you already use GL2ES2
you can rely on us if something goes wrong, there are already a few commercial games on Google Play
I admit that there is a lack of documentation about JOGL under Android. I'm sorry, I have spent several months in writing a tutorial about JogAmp's Ardor3D Continuation and I prefer leaving the task of doing the same for JOGL Android usage to someone more experienced with it.
Edit.: Sorry for the late reply but I had a problem with my OpenID. Please rather post questions about JOGL on our official forum.

SDL2 cross-platform OpenGL 3+ and OpenGL ES 2.0 or 3.0

Is there some super-easy basic hello world cube project (with setup tutorial) for SDL2 that builds and runs easily across (Windows, Linux eg Ubuntu, Mac OS X, Android, iOS), using modern OpenGL as in OpenGL 3.x or 4.x and OpenGLES 2.0 or 3.0?
I downloaded SDL2 and it was pretty easy to get their example testgles.cpp and testgl.cpp to build...
However, the testgl.cpp one is horribly old (gl2 style), so I tried the testgles.cpp. Unfortunately, even this is full of old style fixed function calls like glMatrixMode(GL_MODELVIEW). And it's annoyingly over-integrated with SDLTest_Common code.
Is there a better simple clean hello world project (eg colored cube, textured cube) that I can start from?
Or is there some reason why they don't include such an example starting project or tutorial?
Or should I be using a different library instead of SDL2 that is simpler & cleaner to setup? Basically I want to write OpenGL / OpenGLES (and maybe DirectX) cross-platform C++ code. But setting up SDL2 has been a lot messier and more painful than I expected.
So far I just made an svn repository with SDL2 code and got testgl.cpp and testgles.cpp to build on those five platforms. But that used a lot of old style OpenGL/OpenGLES code, so now I am slowly hacking it to use newer stuff... It's been quite a pain. I don't get why SDL2 doesn't just include a basic hello world cross-platform starting project (eg textured cube) using modern OpenGL/OpenGLES (and DirectX).
SDL2 is a good way to start. I could even say, that SDL is the most popular and yet multiplatform lib for that, especially is you think about using joystics or going steam later on. There is no need to look for any other lib. But please remember, that it's just low level layer for providing media access. It's not their job to provide high quality Opengl 3.0 projects to users. What you need is to learn some modern OGL basics - and you have to do it somewhere else. As simple as that.
A good place to start is http://www.open.gl. There is a couple of very straightforward and simple tutorials written in C++ with some SDL and SFML approach.
Lazy Foo also cover some of the topic http://lazyfoo.net/tutorials/SDL/
http://openme.gl/ is also nice, maybe http://openme.gl/opengl-4-x-example-using-sdl2-and-glm/ is something for you. It seems to be a quite good quality code.
http://www.opengl-tutorial.org/ is also a great place to learn OpenGL 3.3+. It's recomended in many places.
You can always come with some kind of project like this and link to official SDL wiki. ;) SDL community will be greatfull for that.
And by the way. DirectX is "Microsoft's non-opensource SDL" - and it's very non-crossplatform.
If you want to write cross platform OpenGL, you might take a look at GLFW for setting up your OpenGL context. It handles simple window and context creation as well as user input.
I have a method to render a colored cube in some of my example code here. It's pretty enmeshed in my library though as it makes lots of calls out to my wrapper classes. They're also available in the same library, or you can take a look at the latest version of them here.

Looking for OpenGL ES framework for cross-platform development on Win/Linux/MacOSX/Android/IOS [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I have to develop a cross-platform multimedia application that will run on Windows, Linux, MacOSX, Android and IOS. This application will have to be able to play audio/video content, display photos and graphs and, probably, show simple 2D animations. After lot of searching, it seems that the "most portable approach" to the problem is to use C++ as language and OpenGL ES as drawing APIs, because both are supported on almost any pair of device/OS, the performance level will be good and the visual appearance should be near the same on each (group of) devices.
Obviously, I know that I'll have to tweak the appearance of the app to "scale" on different devices with different display sizes and resolutions. I also know that it's unrealistic to demand the exact same behavior for any piece of code on such different architectures. I just want to minimize the written code (e.g. the rewrite of a piece of interface first in C++, then in Java must be avoided).
I'm not an expert in OpenGL ES programming, but looking at some samples, it seems that I will need a framework to have some ready-made widget (menus, buttons, textboxes). I'd prefer not to reinvent the wheel.
This is a low-budget project, so I'll need a framework that is completely free and opensource. The latter requirement also gives the freedom to add/modify APIs of the framework when something important is missing or is misbehaving. I'm not asking for a multipurpose framework (such Qt for example), able to handle input, networking, storage, etc., just because I strongly suspect that such a framework doesn't exist for the platforms I mentioned. I just want a sort of OpenGL wrapper able to abstract many of its low level details but also offering some UI widget as Qt would do. I'll handle intput, networking, storage, sensors separately, probably using other cross-platform open source libraries, as suggested here.
I've read a lot of similar questions on Stackoverflow and Gamedev, and I've heard about a lot of frameworks (Unity, Corona SDK, LÖVE, LibGDX, Ogre, Cocos2D-x), mainly created for game development. Ogre and Cocos2D-x, for example seem to match some of my requirements, but if I decide to use one of them I'll have to code almost all my UI elements (not such a big burden, someone might argue).
A few remarks:
the application is 2D, so OpenGL might seem like overkill. However, OpenGL ES has been chosen because of it's very good portability and its high performance level even on old hardware.
I'm basically a Linux C++ developer, so I'd prefer not to switch to HTML5 (still too young) or .NET/Mono (less efficient) without remarkable advantages in return. Moreover, I couldn't realistically master these languages in the short period.
I've been impressed with the story in this article. I believe that this could be the right approach: a mix of open source tools and libraries that fit the project needs. But I'm still missing the most important piece: the graphics framework.
Writing this question, I found this discouraging answer. I hope my requirements doesn't produce an empty set. I really can't affort to maintain n different UIs on n different platform. I really need something that is platform agnostic.
Any help or advice would be greatly appreciated.
I just stumbled onto this one: GamePlay 3D
Supported platforms are Blackberry, Android, iOS, Windows, Linux and Mac OS X.
You can always do 2D using a 3D framework.
openframeworks
Does everything you asked.

3D model format for OpenGL ES Android

when I was working with XNA model format was obvious .X or .FBX, they had bones so I was able to do animation and collision detection, they probably had everything I needed. But now I started to work with Android and OpenGL ES and I can't seem to find anything about preferred model formats, I keep seeing .OBJ but they don't support bones, I also read something about collada and md5 formats but heard there are some problems with loading them? Also suggestions with min3d but I don't like the idea using third party stuff.
Could someone please explain a bit the situation with models and OpenGL ES, why there are no preferred obvious choices(at least from my point of view), and what format or solution should I go with?
Also this is my first question, please write suggestions if I didn't explain myself right or made any other question errors.
OpenGL ES is much much more low level than XNA, it does not provide anything related to 3d models 'management', and thus, has no preferred model/file format or bone management.
Basically, if you don't like the idea of using 'third party stuff', then you'll have to pick whatever 3d model format you see fit, and do it all on your own.
OpenGL ES is basically a specification, nothing more, the 'SDK' provided by Khronos contains only 1 library. Generally, development resources are provided by the various hardware vendors, in the form of code samples.

Categories

Resources