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.
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.
I tried excluding GL related shared libraries at linking to trace the function dependencies and was surprised brcmGLESv2 brcmEGL and vcos were not even needed for linking!
In fact vcos was the one that broke Qt GL dependency. So leaving out brcmGLESv2 brcmEGL and vcos allows Qt GUI to start up and I can show the raspicam preview "over" a qt dialog window ...
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+ ...
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 ...
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, ...
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
The Baking Pi course (about building an OS from scratch for the Raspberry Pi) has some material that could be interesting. It describes how to program the ARM CPU in assembly, and how to communicate with the GPU. Still this is not really programming the GPU, only communicating with it and the program it is already running.
The way to go would probably to use Qt embedded. It is small enough to run reasonably well on the Pi, I would guess. It can use the Linux framebuffer directly, without X11. If the kernel has acceleration in the framebuffer, it will use that, too. But this may not be the case on the Pi right now.
The Qt embedded can also be built with QtWebKit support. There ...
Unfortunately the Raspberry Pi doesn't actually support OpenGL. It supports OpenGLES instead. The perfect solution would be to port the applications you want to run from the former to the latter. This is unrealistic in most cases though so there are some ways around it. The first would be to get mesa installed and pure software OpenGL up and running. This ...