Finally got a system that can handle GLES3.2 so at some point soon I'm going to play with it...when I get everything else done

The NanoPiT4 has 3.2 on board, but it is giving me a bit of headache trying to open an X11 window in order to set up render targets, so for now, none of my projects work. I am investigating and have called in some big guns to help me out It seems to be limited to latest versions of Ubuntu...but I can't find out why at the moment.

Once I do get this figured out I'm going to use it as my main 3.2 system (well only one really, even though a couple of others claim to have 3.2 none of them are hardware enabled, the T4 is the 1st to come with all drivers on board, I'm sure the ubuntu thing is something that can be fixed)

I'm in love

Its been a long time since I could get a board, burn linux on it and immediately use it.
The T4 is such a board, it came with android installed, but I wanted Lubuntu, and hoped I could dual boot it from an SD, but that didn't work out, so I reflashed the eMMC with Lubuntu, very very simple

And wow, it works, its all there, GLMark2-es2 works fine, though it is frame locked so never went above 50fps, not to worry running it offscreen (avoiding the frame lock) throws up a mark of 312, that's 3 times faster than a raspberry   And.....and.....OpenGLES3.2 yipeee


There's a small downside though, its froze on a 2nd turn of glmark2, it clearly got very hot even with the heat sink on board.. So it is a little fussy. Usually updates fix that, but I can' t get apt-get update to work
It says the dirs are locked....hmmm dunno how to fix that, so have posted on the forums.


I'm loving this board already... going to do a quick compare with the XU4 and Tinkerboard (after an update) to see how its glmarks compare. I'll set up a test project shortly to see how the standard demo plays. Its got a Mali 860Mp4 in there so its up there with the latest (in terms of SBC's, 5 years behind phones though) and has a nice bit of grunt, if we can control the overheat, it could be a contender.

Tinkerboard returns GLMark2-es2 score of 392...hmm that's surprising, and impressive, but the Tinkerboard only goes to OpenGLES3.1 
I'll add the XU4 here when I get round to hooking it up again.

I give my 1st year  students Raspberry Pi's to work on for 8 weeks each year, mainly as an introduction to OpenGL, shaders and code design to use the GPU well.
Its often fun and some really nice games come out of it. I don't set them any very hard goals, just revamp a retro game, do a quake demo, or for those who want to dabble with networking, create a 2 player networked version of Battleships and visualise it anyway they want.

This year, some of my students decided to polish up their version of Battleships and do a cross platform version.
They even did a small trailer of it, though I can't say its all that good, lucky they are not media students.

But I'm still very pleased they made the effort to polish and cross develop it. So thanks to 
Joey Jacobs
Erico Wiggers
Arthur Kuylaars

Team 6 - Block C - Year 1




I'll try to set up a download for you have a go at it, though it needs 2 players with their own pi's to work over a network! (should also work with a PC as the host?)
Edit...now uploaded on the main site's download pages

It doesn't look like the code for the latest issue has been posted to GitHub. I don't know who looks after the repi,or if there's an alternative location...

Eclipse is a robust development environment available for linux which offers better scope for dealing with remote projects than other utilities that I've tried on the O/S. With it you can install a GDB add-on and manage your files across a network, perfect for remote compiling. I will offer the links for all the items you will need to code and cross-compile for the Raspberry Pi 3 B(+.) Here goes:

Installing Eclipse should be the first step, you can get it at the official site, as Brians' book is dealing with C/C++ we should install the IDE for working in those languages (Eclpise C/C++ IDE) or you can download it using your favourite package manager. The official website for Eclipse finds its home at: https://www.eclipse.org/

Now because the Raspberry Pi has proprietary hardware we will need to have drivers ready for our host computer to compile against. You can find these here [https://github.com/raspberrypi/firmware] and because the Rpi has a different architecture to your desktop or laptop we need more tools for remote compiling which can be found here [https://github.com/raspberrypi/tools].

With Eclipse installed we need to extract the files we got from github to somewhere. For ease of use I suggest just extracting them to your workspace folder.

Let's start Eclipse and get it ready to speak to the Rpi.

Open a .cpp file, start a new project, import an existing one, whichever way you go you'll need to direct Eclipse to files from both the firmware and tools-master folders. To set this up we need to open up the properties panel in the projects menu at the top bar. Once in there open the C/C++ Build menu and go to settings. And from there, in the newly visible settings panel, you should be seeing Cross Settings.

In the Cross Settings you need to set the prefix to 'arm-linux-gnueabihf-' and set the path to '~/workspace/tools-master/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin' or wherever you have put these files.

It's from the properties panel that we include the libraries and names of the modules we will be using to compile with. First up we include the directories in the Cross G++ Compiler->Includes section. You can find most of these in the section of the book that details setting up Visual Studio, they have paths like '/opt/vc/include/.' In fact this is so similar that it's practically the same thing. Further to setting up the libraries we have to include the names and this is done in the Cross G++ Linker section->Libraries and these look like 'bcm_host' and 'EGL_static.' You can also set the path for the compiler to find them.

For a more in depth, and easier to follow example, you can check here: https://www.96boards.org/blog/eclipse-re...debugging/

However it must be noted that the tools-master and firmware are both required to make the tool chain, again you can find these here: https://github.com/raspberrypi/tools and here: https://github.com/raspberrypi/firmware respectively.

Any questions?

Like the Odroid XU4 set up is identical but performance isn't quite as impressive as you might expect from a Mali 450 which has 3 vertex and 2 pixel units. Not sure exactly what that means really in terms of how it relates to cores on other systems but bottom line is its not that fast

It also seems to have a small issue with inverted UV coords, which needs to be looked at

and finally it needs the chmod hack to get keys working

 sudo chmod  a+r /dev/input/*

But... if I can fix the inverted UV (or whatever it is) its a nicely working system on a par with the Raspberry in terms of its performance.

EDIT... though after testing the frame rates, actually its much slower, so it maybe that the OGLES is not fully functioning, or, possibly that the lack of optimization in the renders is more serious on this GPU.
The CPU certainly seems to outperform the Rpi, but the GPU isn't currently doing it for me.

Ok this is of course the beast in the Odroid Range, well loved for its emulation ability and octocore performance.

And of course as a target machine it is an utter beast to use, hardware acceleration on the OpenGLES, and able to handle OpenGLES3.1
It has an Mali T628 MP6 on board which is really a major boost, and if you want to get very fancy with it it can do OpenCL for some very intense muli system coding, not that its very practical on a games target.

I love this machine though it does have one niggle, the noisy fan, which does come on and off a lot when you are running it hard and can be an irritant. They do have a silent version basically a big lump of metal heat sink. Not sure of it suffers from overheating with it or not. I can't bring myself to buy 2 of them, as they are a bit pricey. Close to my limit when you factor in the shipping.

So far I've only used mine in anger as an OpenGLES2.0 system for my test code, though I have run a few ES3.0 demos to see it working in its glory :
If you plan to do any OpenGLES3.0 this is the one. I am not 100% sure though that the OpenGLES3.1 claim is true as I was unable to get anything to work on 3.1 demos, however I didn't spend a lot of time so maybe I was just not setting it up right

Set up of the XU4 for ES2.0 really isn't too hard. I use their supplied Ubuntu MATE OS which I think came ready to go with no need to install anything else, but its over a year since I got mine and memory might have failed me. If you can't find the OpenGLES2.0 folders then simple apt-get the mesa libs.

Set up in Visual GDB is typical for most non Raspberry systems you need these include libs, assuming you have glm and bullet installed

/usr/include /usr/include/bullet /usr/include/bullet/BulletCollision/CollisionShapes . glm Headers /usr/include/GLES2 /usr/include/arm-linux-gnueabihf /usr/include/arm-linux-gnueabihf/c++/5


and then just this Binary Lib Dir
/usr/lib/arm-linux-gnueabihf

Library names are...
GLESv2 EGL pthread BulletCollision BulletSoftBody BulletDynamics LinearMath X11

Finally you will need to include some flags for g++
-ggdb -ffunction-sections -std=c++11 -O0 -DGL_GLEXT_PROTOTYPES
the 1st set are normal but the Odroids UbuntuMate version of gcc needs that -DGL_GLEXT_PROTOTYPES or it won't compile


Make sure you don't include BCMHost.h  in any non Raspberry Build

There after there are only 2 issues.. How to get the screen size to set up full screen, and how to set up an EGL window, this time displayed by X11

So make sure you don't define a preprocessor define for RASPBERRY
and you can use this code for both systems.

Oh bugger, it seems NTC who made the little $9 C.H.I.P. have gone bust and there's no apparent sign of a relaunch.

Shame, their little board was actually quite nice to use, and cute to show to people, and I recently did an update on it and noticed it was downloading Mali GPU drivers, which I assumed were related to the Allwinner binary blob release. 

Though only a single core CPU and not very fast at that, it would have got a bit of a boost with its Mali 400 working. Mind you not that much of a boost it was only an M1, but any graphic acceleration is to be applauded.


It was really pretty much the worst SBC on the market, but it had a nice clean OS and was simple to get started, though such a low power system was never going to be any good at the wide range of tasks they wanted it to do, there was even a "games console" kit version...hmmm
I really was hoping they'd get another board to market with the same nice approach to the OS and community but with a better more powerful SBC.


I actually rather liked it when I tried it out, and I might get it up and running again soon to see if the updates do indeed provide an improvement. But its dead Jim, so perhaps I'll just try it out, take note of the set up (should be standard debian) and then move on, even the NTC board isn't showing a lot of discussion in its demise so it wasn't that well supported (oh thats probably why they went bust)

Last year Allwinner announced binary blobs for the GPU's were released and could be added to your Allwinner equiped SBC's

I've been hoping to see more Allwiner chips with the results of that release but so far nothing.

But I understand it is possible to add them yourself....But as I'm not a linux developer  I'm a bit confused by the process

The details are here, 

https://www.cnx-software.com/2017/09/26/...s-support/

I can certainly understand the script, but how you find/edit/use a DTS file is beyond me.... can anyone help?

Oh this is a good one.


"Why are you using OpenAL in the book when its been replaced by more modern sound systems like Fmod? I don't want to have to learn such old tech!"


Ah that is such a good question, and the answer simply is that FMOD isn't available for SBC's, and isn't likely to be considering how large it is and how complex it has become.
I use FMOD in my PS4 and PC development and love it, its really wonderful, if I could get it to work on an ARM based SBC I most certainly would. But until they make a version for me and other SBC game coders (which means both of us), we have to look for the next best alternative.,

The same argument can also be used for MD2-MD5 for models, why do I use these outdated systems. I'd much rather use FBX and other systems but they are not available on any of the current ARM systems. Though I heard there was going to be an IOS version of FBX, I've not see it in action yet and no idea if I can port it to a Pi.

So I used what I thought would work best with the hardware we have to hand. On a low power GPU trying to do too much is a killer for frame rate so MD2 and MD3 don't push it very hard, MD5 does though it can be done and the result is nice easy to view and use models on the Pi and its clones.

Likewise, OpenAL is still very usable, provides 3D surround sound and mixing, and its pretty easy to use with almost any format of sound system if you can convert the data to standard wav format (OpenAL knows nothing of compression systems, it uses only raw files).

It works, its got a small footprint, its not killing the CPU or sound system and theres plenty of help and advice around.

I noted in the book, a lot of the libs we use are 10+ years old and certainly can be considered outdated on PC. But we are not running on a modern PC, and the levels of power we have pretty much match the levels of power of systems form 10 years ago. So use what works.

If you don't like it, I really would love to see you produce something better.'

But rest assured I am always looking for better more uptodate and feature rich systems, so far though...not much on show.