- xr_input.c/h: an OpenXR action set (aim pose, trigger/select click, a menu-toggle button) plus ray/quad hit-testing, and a visible laser-pointer line drawn from the controller toward the hit point. - xr_menu.c/h + MenuOverlay.java: a second composition-layer quad, toggled by a controller button, showing an off-screen, never-attached Android View tree (one "Keyboard" button so far) driven by synthetic touch events computed from the laser ray's hit UV. - Migrate gl4es from a prebuilt binary baked into the Docker build-image to a vendored source snapshot (android/gl4es-src/) compiled from source at APK build time via CMake add_subdirectory(), patched through a new android/gl4es-patches/ (mirrors the existing engine-patches/ pattern). This was needed to track down and fix a bug hit while building the menu: gl4es's fixed-pipeline emulation (fpe.c) was unconditionally substituting its own shader onto the menu's draw call (fpe_ReleventState() always sets alphafunc to a nonzero sentinel, so its fpe_IsEmpty() check could never see the state as empty), making the menu quad show the game's own rendering instead of its own content. Fixed by routing the menu's blit through a real glBlitFramebuffer() call instead of a shader-based draw, which gl4es's fpe.c has nothing to intercept - documented in README.md's new "Debugging notes" section. - Renumber android/engine-patches/ to close the gap left by removing an unrelated diagnostic-only patch, and strip investigation-journal comments and dead diagnostic code (temporary tracing, env-var probes) left over from finding the bug above. - Restructure README.md into numbered sections, document every engine/gl4es patch, add Android Studio dev/testing-cycle instructions, and generalize Quest-specific wording to any OpenXR headset. Update NOTICE.txt to match (gl4es is now vendored/patched source, not a prebuilt binary; add the OpenXR-SDK loader).
This commit is contained in:
ml
@@ -0,0 +1,61 @@
|
||||
GL4ES - OpenGL for GLES Hardware
|
||||
====
|
||||
|
||||
Many OpenGL software already works with GL4ES.
|
||||
|
||||
|
||||
|
||||
Complex OpenGL 1.5 games, like Foobillard++, that uses cascaded display list, line stipple and TexGen works fine. Here running on the OpenPandora. It will work with both GLES1.1 and GLES2.0 backend. Most OpenGL 1.x games will runs.
|
||||
|
||||
|
||||
[](https://www.youtube.com/watch?v=75FYb60L7zw)
|
||||
|
||||
The limit is an hardware one: GLES1.1 and GLES2.0 hardware do not allow reading Depth buffer, so some games that use it (like AssaultCube) for game play wont run correctly. Some FPS are using it just for cosmetics (Lens flare) and run fine without, like Serious Sam (both First and Second Encounter), here on the OpenPandora again.
|
||||
|
||||
|
||||
AssaultCube an Android also use gl4es for the rendering
|
||||
|
||||
|
||||
[](https://www.youtube.com/watch?v=kJPb2jYiBoM)
|
||||
|
||||
More complex program, like Blender, can also run.
|
||||
|
||||
|
||||
|
||||
|
||||
But also Minecraft, here on an ODroid in this old video.
|
||||
|
||||
|
||||
|
||||
|
||||
On the OpenGL 2.0, side using GLES2.0 backend, OpenRA can run on the Pandora.
|
||||
|
||||
|
||||
And OpenGL 2.x opens a lot of doors. Many commercial games run just fine on gl4es.
|
||||
|
||||
[](https://www.youtube.com/watch?v=VUoeHWuwlMU)
|
||||
|
||||
Here some FNA games, running on an ODroid XU4 (using method described [there](https://magazine.odroid.com/article/playing-modern-fna-games-on-the-odroid-platform/)). That video show just a few, and even more can be make to run.
|
||||
|
||||
|
||||
|
||||
[](https://www.youtube.com/watch?v=B4YN37z3-ws)
|
||||
|
||||
And with [Box86](https://github.com/ptitSeb/box86), even more commercial games can run, like here NeverWinter Night on an ODroid XU4
|
||||
|
||||
GL4ES also now works on some other platform, like AmigaOS4 (so BigEndian platform)
|
||||
[](https://www.youtube.com/watch?v=hQVabA_ReoQ)
|
||||
|
||||
Here running Foobillard++
|
||||
|
||||
Or even in a web browser (that support WebGL): try it with Stunt Car Remake [here](http://ptitseb.github.io/stuntcarremake/)
|
||||
|
||||
Another web browser example: Serious Sam Engine, try it [here](https://martinmullins.github.io/ssam/) (initial 80MB game files download).
|
||||
[source repo](https://github.com/martinmullins/Serious-Engine)
|
||||
[](https://martinmullins.github.io/ssam/)
|
||||
|
||||
Neverball in a browser also use gl4es for rendering: [neverball in a browser](https://neverball.github.io/)
|
||||
|
||||
About performances: while gl4es is a wrapper, there are many caching and works done in gl4es to avoid slowdown and bottleneck. While those optimization are useless in highly optimized engine, like the Quake3 engine, on other engine and games, gl4es can be (much) faster than straight GLES conversion (especially if there are a lot of `glBegin(...)`/`glEnd()` drawing commands). On an x86 VM, gl4es running on GLES can be faster than direct OpenGL use on some games!
|
||||
Now GL4ES can also use VBO, either when the software use it, or automatically when using glList, giving sometimes a nice boost (the boost depend on the Platform and game)
|
||||
|
||||
Reference in New Issue
Block a user