Build issues for NG on Arm #457
Comments
|
You mean armv7 32bit? You need to enable neon support, your cpu needs also neon. Minecraft Symbols and the script were removed, you saw it |
|
Many thanks for getting back to me. Should I be building with the Fake-JNI? That is the default and I ran into build issues. I was working through them, mostly by adding Building went fine if I disabled it with
Should I still be checking out the armhf branch though? If I do then the client crashes with: With the master branch: Note - the bit about EGLUT_FB is from my own changes which successfully used the fullscreen display and drawing context to clear the screen with: So not sure why all the "load_library: Undefined symbol" errors, considering 3 of them were used successfully above. That's something for me to debug. Many Thanks |
Fake-JNI was required some month ago, but I made it optional. It was never my idea to use fake-jni.
No, it was an annoying leftover of the old armhf version. I added new armhf compat directly to master.
... It seems your GetProcAddress returns or is a nullptr for a required function I hope you didn't tried to return a nullptr while implementing this function E.g. for libEGL it have to return something like the pointer to eglGetProcAddr(const char*) which returning the specfic opengles function pointer.
|
|
If Fake-JNI has no benefit then I'll leave that and go with the working build.
LOL, no I worked out the importance of that.
My EGL version is 1.4. So I will require a workaround to return the function pointers to the game. I found a rough example here which uses |
|
I've written a drop-in as above to allow linking to the GL functions and fixed a few build issues. The game now launches up to the "Microsoft Sign In" screen, complete with scrolling 3D cave background. So things are looking very good. I can go no further than that as I've yet to implement the input system... First I'm going to move video to SDL2 rather than raw EGL as it will make blitting in a mouse pointer for the menus far easier. I was already going to be using it for mouse/keyboard/gamepad anyway, and it might make this more portable to other boards without X11. Many thanks for the advice and keep up the good work. |
Hi, I tried this great application using a ChristopherHX produced AppImage on my Linux Mint desktop.
Impressed I began trying to get it working on my daily gaming box, which is an Arm S905x. It's essentially an Odroid-C2, with Mali EGL/GLESv2 support. The main hurdle - the application is X11 based, where my system is not and runs directly in framebuffer.
I did briefly get an experimental X11/Xfce desktop working to test. The Qt based frontend worked and downloaded the apk from the Play Store, but the game could not launch due to graphics issues. I built from the ChristopherHX source, natively on my board, but that didn't help with any video detection etc.
I would rather cut out the X11 overhead anyway... So I've opted to try and provide framebuffer support for the video, and SDL2 support for the input. I'm working from the NG source as this seems to be the recommended project.
I've compiled Qt for my platform to add the EGLFS_Mali plugin support. That allowed the Qt-UI to work without X11, but it froze after a bit. No Matter - I'll come back to that. Priority is the client.
First
cmakeissues with mcpelauncher-manifest were with new dependancies. Installed those.I tried to still follow the advice about:
However that folder isn't created after the checkout, so there's no script to run...
I also found it insisted on building with CLang, which I've never used before so I installed that.
So now I configure with:
CC=clang CXX=clang++ cmake ..This yields
Running
makeI fail with:Any advice would be greatly appreciated.
Many thanks in advance.
The text was updated successfully, but these errors were encountered: