I'm using Visual Studio Community 2017, but the native-activity in this version is the same as in Visual Studio Community 2015.
I have just created a new native activity project in Visual Studio 2017, using the default program that loads with this project choice. However, whenever I try to use a function exclusive to open gl es 2, Visual Studio responds with an error like "error : undefined reference to 'glCreateShader' " for each open gl es 2 function that I use. Strangely, the following code works, even though I deleted the line in the pch file that includes open gl es 1:
glClearColor(200, 200, 200, 1);
glClear(GL_COLOR_BUFFER_BIT);
The following function if put into the default native activity project (even after including GLES2/gl2.h, GLES2/gl2ext.h, and GLES2/gl2platform.h) results in the error described above:
int prepareShader(GLuint shaderType, const char * shaderCode) {
GLuint shader = glCreateShader(shaderType);
int len = strlen(shaderCode);
glShaderSource(shader, 1, &shaderCode, &len);
}
I remember a similar error occurring in Android Studio, which was fixed by adding the following to cmakelists.txt:
find_library(gl-lib
GLESv2 )
find_library(egl-lib
EGL )
target_link_libraries( # Specifies the target library.
native-lib
${egl-lib}
${gl-lib})
My Visual Studio project does not use CMake, however.
Can somebody please tell me how to successfully use open gl es 2 in Visual Studio 2017?
The solution to my problem is to load the open gl functions using eglGetProcAddress. This just means that each opengl es function must be set to a pointer before using them because GLES2/gl2.h does not define the functions (the functions are defined at run time).
Doing something like this for each function solves the problem. (However, I needed to delete the function prototypes in GLES2/gl2.h for this to work).
typedef GLuint(GL_APIENTRYP PFNGLCREATESHADERPROC) (GLenum type);
PFNGLCREATESHADERPROC glCreateShader = (PFNGLCREATESHADERPROC)eglGetProcAddress("glCreateShader");
Related
I have an Android native library (C++ code base) called:
libserverapp.so
And I cannot get the Android build to find it:
"DllNotFoundException: serverapp"
I am using an internal build system, but when I parse the output of the build process, I can see many calls of the form:
android-ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-g++.exe -march=armv7-a
After building my Android app, I inspect the resulting APK (renaming to .zip and extracting), and can see my library file here:
lib/armeabi-v7a/libserverapp.so
I can confirm that "ARMv7" is the target architecture in the Android Player settings, and I access the library, in C#, via:
[DllImport("serverapp", CallingConvention = CallingConvention.Cdecl)]
private static extern void run_sim(StringBuilder matchInput, StringBuilder results, int randomSeed);
I have built a Windows DLL of the C++ code, to use in the Editor, and everything works great. However, when I move to Android, the .so cannot be found. The import settings for libserverapp.so are:
Platform: Android; CPU: ARMv7; Path: Assets/Plugins/Android/libserverapp.so; Type: Native
Given that the final APK includes the .so where I expect it to be (lib/armeabi-v7a/), I assume my Unity settings are correct? Also, I am not using IL2CPP for the Android build.
Finally, when I do an object dump of the library file (using arm-linux-androideabi-objdump.exe), the file format of the library file is "elf32-littlearm".
I feel that the issue here is simply finding the .so, not the functionality within it. Any ideas on what's going on here?
Thanks!
I ended up solving the problem. I mentioned that was using an internal build system. Well, there seems to be a bug in it. I ported things over to official Android NDK makefiles, and then it "just worked". So in this case, the library could be found, but its contents weren't valid.
I'm compiling C++ code written primarily for Mac OS, using the Android NDK and I get the following error:
- Type 'errno_t' could not be resolved
In Xcode this type is defined on OSX 10.0/usr/include/sys/_types/_errno_t.h as this:
#ifndef _ERRNO_T
#define _ERRNO_T
typedef int errno_t;
#endif /* _ERRNO_T */
Any suggestions on how to convert this to the NDK, or add compiler flags to make this compile, or where to even get the source code to define this type in my source code itself?
Thanks.
See this answer for information on errno_t.
errno_t is not a part of the C standard, and bionic doesn't support it.
The fix is simply to change all the errno_ts to be ints.
I have a project that's fully functional in Xcode but not compiling in Eclipse ADT. I have successfully compiled and run android applications in the past, but this is my first time to create a custom class. To replicate the issue:
I create a new project, then add the following 2 files:
//Enemy.cpp
#include "Enemy.h"
USING_NS_CC;
bool Enemy::init()
{
if(!Layer::init())
return false;
return true;
}
//Enemy.h
#ifndef __ColorMirror__Enemy__
#define __ColorMirror__Enemy__
#include <iostream>
#include "cocos2d.h"
USING_NS_CC;
class Enemy : public cocos2d::Layer{
public:
CREATE_FUNC(Enemy);
virtual bool init();
};
#endif
I am able to see them in Eclipse in the list of classes.
Then I create a new enemy in HelloWorldScene.cpp as follows:
Enemy *newEnemy = Enemy::create();
This compiles and runs as expected in Xcode, but when I run build_native.py I get the following errors:
jni/../../Classes/Enemy.h:19: error: undefined reference to 'Enemy::init()'
jni/../../Classes/Enemy.h:19: error: undefined reference to 'vtable for Enemy'
Checking in the jni/../../Classes file, I am able to find Enemy.h and Enemy.cpp.
I have seen several explanations for fixes in other versions of Eclipse, and the suggestion it's a linker error, but I haven't figured out how to fix it in ADT.
Thanks!
So I'm not entirely sure which of these steps fixed the problem, and it may very well have been multiple issues, but here's what I did:
1) Added Enemy.cpp into Android.mk as follows:
Browse to game folder /proj.android/jni and open Android.mk
Open with TextEdit
Below the AppDelegate.cpp in LOCAL_SRC_FILES: added this:
../../Classes/Enemy.cpp \
Save
(still didn't work, so I took it out)
2) Changed workspace for Eclipse (which is specified on opening eclipse) and deleted old workspace
3) Downloaded and set up newest ADT package (Eclipse JUNO)
4) Upgraded Cocos2d-x from 3.1 to 3.2
(still didn't work)
5) Added Enemy.cpp to Android.mk again
Upon completing all those steps, everything works great and compiles as before.
Thanks to Wez Sie Tato for confirming that Enemy.cpp did in fact need to be added to Android.mk... Based on some comments I've seen elsewhere, it appears that my ADT package may have gotten damaged somehow, in conjunction with not having the proper line in Android.mk
I am a beginner with C/C++ and the Android NDK, and I have a problem trying to create a native library. My code compiles using MinGW on CDT, but when I write the same code on a JNI file, there is an error.
My code is:
int n = 7;
int positions[n];
int final_order[n];
memcpy(positions, final_order,sizeof(final_order));
The plugin shows me:
Invalid arguments 'Candidates are: void * memcpy(void *, const void *, ?)'
This the header from MinGW on CDT:
_CRTIMP void* __cdecl __MINGW_NOTHROW memcpy (void*, const void*, size_t);
This the header from the Android NDK:
extern void* memcpy(void *, const void *, size_t);
There is a known indexing problem when using Eclipse to do NDK development.
Read about it here: https://code.google.com/p/android/issues/detail?id=33788
Near the bottom there is a reasonable workaround that I myself use:
What we want is to use the Android GCC toolchain but change the actual tools and modify the discovery options so that the include paths and symbols are correct.
Go into C/C++ Buid \ Tool Chain editor
Make sure Android GCC is the selected toolchain and Android Builder is the selected builder.
Click on "Select Tools"
Select "Allow all changes"
Remove the Android GCC Compiler
Add "GCC C Compiler" and "GCC C++ Compiler" so that we can index both c and cpp headers.
If you would look at "Paths and Symbols" you would see we have both GNU C and GNU C++ languages, but of course the built-in include paths are wrong. luckily there is a fix for that.
Go into C/C++ Build \ Discovery Options
Change Discovery profiles scope to "Configuration-wide"
Make sure the Discovery profile is using "AndroidPerProjectProfile" and make sure both checkboxes are checked.
I then have to manually add my own include directories and definies under Project Properties -> C/C++ General -> Paths and Symbols
It's worth noting that your code compiles fine. You can turn off indexing if you like, but if you still want the advantages of indexing you'll have to work around the issue.
Another workaround is:
to open the android native perspective,
to right-click on your project in the project navigator,
and to click on the index options to rebuild the indices.
I have following commands:
// Load the shaders and get a linked program object
userData->programObject = esLoadProgram( vShaderStr, fShaderStr );
...
// Generate the vertex data
userData->numIndices = esGenCube( 1.0, &userData->vertices,NULL, NULL, &userData->indices );
The program is in native C++ for Android 4, using only NativeActivity. So, project has no /src and java classes.
I put the information to NDK OGLES 2.0 about the version running as EGL_OPENGL_ES2_BIT, and Android.mk was also setup to -lGLESv2. In the file is also included:
#include <GLES/gl.h>
#include <GLES/glext.h>
#include <EGL/egl.h>
#include <GLES2/gl2.h>
And also AndroidManifest was informed that it runs OGLES 2.0.
When asked to run, the program gives the following message:
'esLoadProgram' was not declared in this scope
'esGenCube' was not declared in this scope
For some reason these commands that belong to OGLES 2 are not visible. Any suggestion why this?
All comments are highly appreciated.
esLoadProgram and esGenCube are not a part of OpenGL ES or EGL. They are just a helper functions (probably from http://code.google.com/p/opengles-book-samples/)
PS. I would not suggest to mix also GLES and GLES2 headers. If you want GL ES 2.0, then include only from <GLES2/...> (not <GLES/...>)