This was not possible at the time of the original question, but the full Java-based Minecraft can run on a Raspberry Pi 2 or higher today. With improvements to OpenGL on Raspbian over the years, LWJGL now just uses full OpenGL via the Mesa library.
Instructions with demo videos:
How to setup Minecraft 1.8.9 on RaspPi2 (original tutorial with Minecraft 1.8....
Assuming your running the latest Raspbian Stretch with Desktop.
To enable OpenGL, from a terminal window:
Select 'Advanced Options'
Select 'GL Driver'
Select 'GL (Full KMS)'
To test it's working you can install and run glxgears - a graphical demo that should run at close to 60fps:
sudo apt-get -y install mesa-utils
pyopengles is probably the best choice for the moment, it's certainly not very mature yet, but is quite functional. It would be nice to see some of it wrapped in a more OO fashion, but it's good for learning the raw mechanics of opengl es if that's what you're interested in.
I found this page very helpful when I was trying to get to grips with pyopengles on ...
You need to enable the OpenGL driver:
From a terminal window enter
Then select 'Advanced Options','GL Driver','GL (Full KMS)'
Once you've rebooted glxgears should run at close to 60fps with the correct colours.
The setting that changes inside the config.txt is dtoverlay. Whenever the GL driver is enabled it is set to dtoverlay=vc4-kms-v3d else commented out.
I had difficulties even finding the config.txt since I was looking in the wrong partition (thanks for the tip, @joan !)
In order to easily find what setting has changed and since I didn't know the name of the ...
Did you consider 2D Game engines/libraries ? Because OpenGL/OpenVG are very low-level and don't do font handling , the added "belt and suspenders" of those libs will make your life much easier :
Is it possible to use SDL2 with 2D hardware accelerated rendering on Raspberry Pi?
Is there anyway to check at runtime that the renderer is using hardware acceleration?
Yes and yes. It seems that this method is actually producing an executable that uses SDL2 with an OpenGLES 2 backend. This can be confirmed by adding some code:
From the log you pasted it seems that Pi's GPU doesn't know OpenGL. That's one of the reasons they've made a special version of the game.
EDIT: I tried to make LWJGL program an run it on pi. It failed. Pi's GPU definitely doesnt support LWJGL OpenGL implementation.
ssh's -X sets the DISPLAY environment variable such that all X requests are sent to the host. EGL has no X11 wire protocol, so EGL can't be forwarded to your host's X Server. For EGL, you'd need to run the application on an X Server on the Pi, then use something like lightpipe to scrape the pixels on the Pi's X Server and forward them to your host. It'll ...
I had the same problem and the culprit was mesa-common-dev. Try removing it using
% sudo apt-get remove mesa-common-dev
A new round of ./configure && make && sudo make install made my SDL2 program run.
glReadPixels() is the correct function to use, and it's exactly what you asked for: Move data from the GPU's framebuffer to the CPU.
On Raspbian, I believe they disabled the NEON code in the GL driver due to their compiler not liking compiling NEON code (for pi0/1 compatibility), even though Mesa has conditional dispatch to the NEON code based on ...
lenix is correct. The GPU drivers on Raspberry Pi (and every other ARM SoC that I know of) are delivered as a binary blob. If your goal is to learn how to write a GPU driver, then you have a lot of reverse engineering ahead of you. If your goal is to make the GPU do something, then you can call the OpenGL ES 2.0 C API from your assembly code. Since you're ...
You may want to take a look at OpenMAX. Otherwise, graphic drivers are provided by BroadCOM in binary form and not open-sourced at all. You may need to sign NDA and have close friends at Broadcom to take a peek.
The problem turned out to not be in the code, but in the library path. A simple -L/opt/vc/lib/ added to the compile command line fixed it. Without that the compiler would pick:
While the right one would be (use ldd to check):
These libraries were renamed to libbrcmEGL.so and libbrcmGLESv2.so on Stretch, in order to reduce the risk of conflicting with their libgles2-mesa-dev counterparts. Edit the Makefiles to say -lbrcmEGL -lbrcmGLESv2 instead.
In fact, somebody already did that and submitted a pull request.
There's no such thing as GL 2.1 core, so I would expect your context creation to have failed here, ...
There's an implementation of OpenGL 1.X API using OpenGL ES, which I was able to successfully build on several ARM devices (Orange Pi, Pandora). Since the repo has a branch called rpi, I assume it works on RPi as well.
The library helps a lot when you want to run older OpenGL games on ARM. For learning purposes, you'll want to check how much of OpenGL 2.0+ ...
That tutorial uses the old Broadcom EGL libraries (/opt/vc), which was all that was available in 2012. Modern Raspbian is often configured for the Mesa open-source driver, leading to a failed to add service error when attempting to run a program built for the former.
If you had enabled the full OpenGL driver at any point, you can run sudo raspi-config, ...
The best way to launch X applications before conecct with a ssh -X is adding nohup to avoid this errors:
nohup glxgears &
And you have the application running, the errors dumped in a file called "nohup" and the console operating because you launched the application in background using the "&"
One Minecraft Pi Edition (MCPI) user had reported this error appearing with a patched minecraft-pi but not the original. This suggested /usr/bin/minecraft-pi may be more than just a symlink, and it turns out to be a helper script. It appears the Raspbian maintainers installed a wrapper for libbcm_host using the LD_PRELOAD trick to keep MCPI running in both ...
Did you consider 2D Game engines/libraries ? Because OpenGL/OpenVG are low-level the added "belt and suspenders" of those libs will make your life much easier - especially considering input handling , too :
On the Raspberry Pi technologies incorporating hardware accelleration are preferable (look ...
I got 2D vector graphics library working, using it from C Language, currently with a 128x128 OLED display on a headless Raspberry Pi 3B, using the following recipe. Note: X-Windows (X11) is not installed (e.g. Raspian lite edition). As for performance considerations, OpenVG's claim to fame is that it utilizes available HW acceleration layer(s) rather than ...
You may be following an out of date tutorial and installing screen software which is no longer relevant.
Support for at least some Adafruit 2.8" touchscreen displays is built in to the later versions of Raspbian with a recent kernel.
Look in /boot/overlays/README on your Pi.
Info: Adafruit PiTFT 2.8" resistive ...
Link GPU eglfs binaries so Qt can get to them in system path
sudo ln -s /opt/vc/lib/libEGL.so /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0
sudo ln -s /opt/vc/lib/libGLESv2.so /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0
Install the leandog apt server in your sources
echo "deb http://apt.leandog.com/ jessie main" | sudo tee --append /etc/apt/sources....
Pi can run GL in two ways -- the traditional GL-on-X11 way which uses the glx() calls and also directly, without starting X11.. which is where the bcm_host_init()
calls come in -- they're the chipset driver API (bcm => Broadcom)
I work with QT 5.0 for hardware acceleration ... because there is an optimized version for the raspberry Pi and i can use the transparency :
you can use the powerfull QTQuick for : translate, move on X,Y ...rotate etc etc
but ... the only problem: there is not a valid debian package for the moment, so you need ...
There is a free software assembler, MoeASM for the RaspberryPi GPU https://wk3.org/posts/588911
Also, check out the reverse engineering work and source code samples at https://github.com/hermanhermitage/videocoreiv