I'm learning using OpenGL ES with the JNI (Java Native Interface). I'm currently trying to draw a simple Triangle with NDK installed in Android Studio through this example : https://github.com/googlesamples/android-ndk/tree/master/hello-gl2.
I haven't learnt java before, so I want to write all the code in C++ and call it through the JNI. However, there's still some java code in the GL2JNIView.java of this example, which makes me confused. Could someone guide me how to draw this Triangle with only C++ code and call those functions through JNI please ?
In the sample, hello-gl2, there is no java code draws a triangle. The sample project is exactly what you are looking for. In the sample, Java only calls C++ code(which actually draws a triangle) through JNI.
If you really don't like to use java at all, there is an option that you can use a native-activity. However, I recommend to mix Java & c++ since the android native environment is limited to use all android features that you might need. I, for example, use c++ most in android development although very barely, I need to use android api which is only supported in JAVA.
If I used the native-activity, there wouldn't be no option to use them I needed
Related
I've read through a lot of documentation on Xamarin and my understanding is that it exposes the native APIs on each platform via C# and .NET, and this way, offers a sort of one-to-one binding. The native build produced contains some of the applicable .NET libraries (based on linker optimisation).
However, I can't seem to find any information about what actually happens within the native build itself.
Assuming my understanding is correct, my question is:
Within the native build, does the code you've written call the native API functions via a call to native .NET functions included in the build?
The short answer is: yes, it calls native API's through .NET code that runs on Mono, via the binding concept you already seem to be familiar with.
Xamarin uses these bindings to call the native code from your C# code. There are a few differences depending on the platform you are running on.
iOS
Your IPA-file will contain 2 things:
The executable of your .NET code (AOT-compiled), which is run through the Mono runtime
Native libraries, which use the objective-C runtime. The .NET code calls these libraries/API's via bindings.
Both the Mono runtime and the Objective-C runtime are running on top of a UNIX-like kernel.
Take a look at this Xamarin iOS architecture documentation for a more extensive explanation.
Android
Android is a little more complex to understand and explain. This is because some of the API's are only exposed through the Android Runtime API.
The bindings in Android are working through concepts such as:
"Android Callable Wrappers" (Android Runtime to Mono)
"Managed Callable Wrappers" (Bindings to Android Runtime API's)
The Xamarin Android architecture documentation explains these concepts and inner workings in great detail.
I am very experienced with Visual C++ and I am just starting to program native Android C++ apps with Visual Studio 2015 C++.
I need to do a homescreen overlay-style app, presumably by using a TYPE_SYSTEM_OVERLAY window and SYSTEM_ALERT_WINDOW permission.
Is it possible to do this with the NDK? Will all required API calls be available to use?
Am I correct to assume that I won't be able to use OpenGL-ES to display my graphics in the window (since it isn't full-screen)? I would love to be able to use cocos2d-x for graphics, input etc but I have a feeling that won't be possible at all.
Is it just going to be too difficult to use NDK for this type of app, and should preferably just sit down and learn Java and SDK?
(last question is probably a bit opinional)
On Android, anything you can do with Java, you can do with the NDK, because you can simply use JNI. If you are making many calls into Java from the NDK, you should consider creating an JNI wrapper class, which reduces the calling mechanism to fewer lines.
Although I haven't tried it, there is nothing in the Android documentation to suggest that GLSurfaceView cannot be used with a particular type of window layout.
I'm building an application with OpenGL ES 2.0 and SDL2 for Android. Is SDL_GL_GetProcAddress working with OpenGL ES 2.0 on Android? Also i know OpenGL ES 2.0 is a subset of OpenGL, so with this method can it run on desktop systems too?
From a quick browse of the SDL repository it should be.
SDL_video.c defines the implementation of SDL_GL_GetProcAddress simply to check that you've started OpenGL and then to call _this->GL_GetProcAddress, where _this is a global instance of the video driver.
SDL_androidvideo.c sets its GL_GetProcAddress to be Android_GLES_GetProcAddress, which is a preprocessor substitution for SDL_EGL_GetProcAddress.
So, so far: if you call SDL_GL_GetProcAddress, you'll get through to SDL_EGL_GetProcAddress.
SDL_egl.c implements SDL_EGL_GetProcAddress but declines to call eglGetProcAddress on Android. This looks like it's probably an error — the reason given is this bug but the status for that bug switched to 'Released' in June 2013, which I believe means that this has been fixed in Android for more than three years.
That aside, the fallback is to use SDL_LoadFunction, first with the direct function name, then with it proceeded by an underscore provided it's short enough to fit into the statically-declared buffer. Which this one is.
(so, caveat: SDL_GL_GetProcAddress is definitely not thread-safe, even if you've taken appropriate share group steps to use multiple GL contexts, but if you're writing an SDL program you probably don't care)
Android should be using the dlopen version of SDL_sysloadso so it looks like SDL_LoadFunction is implemented directly as a call to dlsym. Which has no issues that I'm aware of under Android.
So, in summary: yes, that call should work. It'll use the platform-specific dynamic library loader rather than the EGL call though it probably doesn't need to, but that's just an implementation detail.
I am trying to develop one sample opengl 3D application using Netbeans with MingW.
How to compile opengl sample code in netbeans.?
what is shader language(GLSL) in opengl.?
Can i run GLSL code in netbeans.?
How to compile opengl sample code in netbeans?
Just like any other program as well. Only addition is, that you must configure the OpenGL API interface library as another dependency. Since you didn't specify which language you use I can not tell you how it's named. For regular Windows programs written in C or C++ the name is opengl32.lib and it's part of the standard compiler environment.
Netbeans is a Java IDE, so I suppose you want Java. Then the de-facto standard binding library would be LWJGL.
what is shader language(GLSL) in opengl?
The programming language in which shaders are written. Shaders are programs that are executed by the GPU for every primitive and pixel drawn to the framebuffer. GLSL compilation is done by the OpenGL driver, your program just passes the GLSL code into a function of OpenGL, namely glShaderSource
Can i run GLSL code in netbeans?
No because GLSL is not a regular programming language that produces executables you'd "run" in the classical sense.
I need to develop a small 3D game running on both Android and IOS mobile devices.
1- Should I implement EGL using within 3D logic or left it been implemented in Object-C or Java? which way should I go and why?
2- Should I use C or C++ for game logic? it is said C has better run time performance but harder to design due to it is not OOP C++ and vice versa. I have some experience with Java so I prefer OOP more.
Have you already considered to use a multiplatform library? For example:
libGDX
Especially if you are targeting for both platforms, such a library might be helpful.
I can only speak for Android a bit:
It actually makes no real difference, the Android API just provides calls for the same OpenGL C-functions, but still more comfortable, better supported and the recommended approach. Anyway there is Android NDK which allows to load original C/C++ code given the case you want to port some code from another platform (or develop for several platforms).
In my opinion the performance is mostly limited by the graphics (number of objects, size of textures etc.), usually not much by game logic, so Java would be more convenient.