ptitSeb / gl4es

GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4.
http://ptitseb.github.io/gl4es/
MIT License
694 stars 159 forks source link

gl4es for Pd Gem #360

Open dromer opened 2 years ago

dromer commented 2 years ago

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?

ptitSeb commented 2 years ago

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.

dromer commented 2 years ago

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 :#

dromer commented 2 years ago

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".
ptitSeb commented 2 years ago

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.

dromer commented 2 years ago

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 ..

ptitSeb commented 2 years ago

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.

ptitSeb commented 2 years ago

My beta thread is there: https://pyra-handheld.com/boards/threads/ptitsebs-beta-lair.77439/ you can download the (huge) pnd there.

dromer commented 2 years ago

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 ..]

ptitSeb commented 2 years ago

good :) happy building!

dromer commented 2 years ago

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 ?

ptitSeb commented 2 years ago

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.

dromer commented 2 years ago

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
dromer commented 2 years ago

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!

dromer commented 2 years ago

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

ptitSeb commented 2 years ago

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.

dromer commented 2 years ago

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 :)

ptitSeb commented 2 years ago

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.

dromer commented 2 years ago

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).