ptitSeb
gl4es for Pd Gem
So, it has been many years since I tried this, back then still with glshim .. but really I only got as far as a mesa build.
What do you think it takes to build pure data with Gem on top of gl4es?
It may just work. gl4es is a drop-in replacement for libGL. Just build gl4es and launch Pd Gem with gl4es in the LD_LIRBARY_PATH and you'll see.
I need to build pd + gem from scratch as well .. trying to setup dchrt-ng toolchain, but not sure what the recommended way is to cross-compile a pnd for pandora these days :#
Still had a working SL4P sdcard, however the cmake was too old (2.8.8) so I tried building and installing 2.8.12-2 but thenI get:
dreamer@darkstar:~/Sources/gl4es/build$ cmake .. -DPANDORA=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_LANGUAGES_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_LANGUAGES_COMPILER
CMake Error: Could not find cmake module file: /home/dreamer/Sources/gl4es/build/CMakeFiles/2.8.12.2/CMakeLANGUAGESCompiler.cmake
CMake Error: Could not find cmake module file: CMakeLANGUAGESInformation.cmake
CMake Error: CMAKE_LANGUAGES_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "/home/dreamer/Sources/gl4es/build/CMakeFiles/CMakeOutput.log".
You can also probably use codeblocks PND (use the beta one from my beta thread on the Pandora forum) and build on the pandora itself.
Hmm, codeblocks in a graphical IDE right? Do I then have to do everything physically on the pandora? I can't see myself do any of this if not in a shell .. and then how do I run any software I build, inside of the PND?
Sorry too many questions not related to this project .. info is very sparse out there and none of this seems to be in a very usable state ..
Codeblocks PND contains the codeblocks IDE yes, but also a command line prompt with a fell dev. env. availble, so you can use cmake, autotools, gcc (full suite v9.3 with latest beta PND), and more.
My beta thread is there: https://pyra-handheld.com/boards/threads/ptitsebs-beta-lair.77439/ you can download the (huge) pnd there.
I was just trying that one :)
Is your script to use it over the shell still https://pyra-handheld.com/boards/threads/open-pandora-for-other-stuff.73756/#post-1288781 ?
After trying this I still do not have cmake in the path.
[Edit: oops, nevermind. I modified the included cbpnd_cli.sh and now seem to have a working C::B shell!
I'll go play with this for a bit ..]
ja, got gl4es and pure-data builds. now starting on Gem.
too bad this isn't cross-compiled .. poor pandora needing to do heavy lifting ;)
Is there maybe a way to distribute a code::blocks env for cross-compiling on x86 ?
It's possible, but tricky, and not really documented. Look here: https://pyra-handheld.com/boards/threads/update-wiki-for-cross-compiling.79293/ you'll find a small script I wrote to build a cross-tool chain specific to the pandora. After that, you have to cross-build the same GCC version as in codeblocks, that mount/copy codeblocks to use all the libs.. That's basicaly the steps, but there are a few adjustment to do (don't remember wich one). I found it more simple to use build on the pandora anyway; so I never continued this work.
Hmm, building Gem on C::B got as far as:
Event.cpp: In function ‘void dequeueEvents()’:
Event.cpp:353:5: error: ‘error’ was not declared in this scope; did you mean ‘perror’?
353 | error("dequeue NULL queue");
| ^~~~~
| perror
Event.cpp:358:5: error: ‘error’ was not declared in this scope; did you mean ‘perror’?
358 | error("dequeue empty queue");
| ^~~~~
| perror
make[4]: *** [Makefile:794: libGem_la-Event.lo] Error 1
make[4]: Leaving directory '/media/Pandingen/Sources/_codeblocksdev/Gem/src/Gem'
make[3]: *** [Makefile:634: all] Error 2
make[3]: Leaving directory '/media/Pandingen/Sources/_codeblocksdev/Gem/src/Gem'
make[2]: *** [Makefile:794: all-recursive] Error 1
make[2]: Leaving directory '/media/Pandingen/Sources/_codeblocksdev/Gem/src'
make[1]: *** [Makefile:658: all] Error 2
make[1]: Leaving directory '/media/Pandingen/Sources/_codeblocksdev/Gem/src'
make: *** [Makefile:693: all-recursive] Error 1
Ok that declaration is hopefully fixed and now building since ~2 hrs ;)
Hopefully tomorrow morning it succeeded without errors. Will then see what happens when running it using the gl4es build!
Ok, some success, however it seems that this C::B environment ships its own gl4es?
LIBGL: v1.1.3 built on May 18 2020
Not my build that I put in LD_LIBRARY_PATH=/media/Pandingen/Sources/_codeblocksdev/gl4es/lib
Yes, CB include everything. gl4es, box86, all my stuffs are there too. Prefer LD_LIBRARY_PATH=/media/Pandingen/Sources/_codeblocksdev/gl4es/lib:$LD_LIBRARY_PATH becausez the variable is used.
You can also copy libGL.so.1 directly to /mnt/utmp/codeblocks/usr/lib/ to override the one from CB.
LD_LIBRARY_PATH really doesn't work, but overwriting the CB version does work!
On 1ghz model it says v1.1.5 and GLES 1.1/OpenGL 1.5 but I can overload with LIBGL_ES env var.
Need to do a lot of testing, some things seem to work fine, while other features crash the program entirely.
First steps look promising though :)
Yes, on Pandora, gl4es default to GLES 1.1.
The crashes maybe because of some shader that fail to compile / link. Use LIBGL_LOGSHADERERROR=1 to have more details when a shader fail to compile/link.
Hmmm, so some of the crashes seem to happen after re-opening the rendering window.
I believe this should completely remove the window and disable rendering. Then create a new context and enable rendering on that.
Any other logging I could try? the LIBGL_LOGSHADERERROR=1 doesn't show anything when this happens.
Sometimes Pd just crashes, other times the entire pandora just freezes completely (no SSH active either).