Its been brought to my notice that some of the earlier lessons, which expected Rasbian Jessie libs, have been hard to upgrade, to Stretch, since its not clear how to add the new libs.
Code::Blocks has 2 basic ways of searching for libs.

You can define the full path and name of the lib 
like this
../../../../opt/vc/lib/libEGL_static.a

but what do those ../ symbols mean... Thats an indication of a relative path, in other words the linker will look at your current bin directory, and step back into the dir structure each time it sees a ../
Generally thats a good idea to do, if you are using a system with libs that you make, but I must admit it was poor choice on my part to include that on tutorials for on board libs.
Its much more sensible to use an absolute path

/opt/vc/lib/libEGL_static.a


The reason being that Raspbians file structure is consistent, so you can indeed go to the root then opt, then vc etc

The other ways is just to name the libs, and ensure that you have the linker search directories set to the correct dirs, in this case
/opt/vc/lib
and
/usr/lib


I've attached a more Stretch friendly version of Lesson 2 which is the 1st graphic project that needs libs, if you have problems please use this.

Attached Files

  cc2.tar (Size: 30 KB / Downloads: 0)

All my demos and samples are built using on target building, while this is effective and allows the code to work or at least compile on a very wide range of systems, it is a little slow, especially on older single or dual core units.

VisualGDB does allow you to install and build using toolchains, in other words, compilers and linkers that run on your PC and then download  only final build executable and resources to your system to then be run. Thats a much faster turnaround, sometimes by a factor of minutes, this is simply because your PC is many times more powerful and can compile files without sending them to the system,

It is however much less portable, and you are basically making builds that will will work for you and your target, and not for other peoples targets. (unless they have the same targets)

There's a few minor things to think about when building on your dev system. 
You have to sync your sysroot. Which basically means, your PC needs to keep a copy of all the libs and include files it will find on your target, so that it can include them during compile.

You need to be extra careful you are sending resources over your project needs, 

Be aware that no source files are now sent, unless you specify them.

I've had such a pain getting the whole Android SDK to load, but after 2 days of installing,reinstalling, testing and trying...I finally got it in place

I tried it out 1st with an ancient Sony Experia Phone which I used to use when I was doing Playstation Mobile coding which was an NDK based form of Android. And it managed to build but was not happy with debugging or resending.

I next tried to create a project for my FriendlyArm K2, which is an android 5.1.1 based system with a decent CPU/GPUcombo I hooked it up the usual way to my network and monitor, but powered it via its usb to my PC giving me access to the Google USB driver to send and communicate. 

And lo and behold it worked, at least the VisualGDB simple NDK test project worked.. So it looks like I can build on that to produce some examples for Android based machines.
I've not even tried to do the OpenGLES stuff yet, just letting you all know that despite the hassle of getting the SDK for various versions of Android on to your system (we're talking many 10's of gigabytes). VisualGDB does seem to be fairly happy so far on later Android versions.

I'll take this a bit further and see how it gets on, my biggest issue at the moment is I can't seem to work out how to target a specific build chain after I've selected all versions, this makes the build quite slow. Though you can edit the Application.mk file which has
APP_ABI := all

to

APP_ABI := APP_ABI := armeabi-v7a

and that at least works for the K2 and speeds up the compile as it only builds once instead of about 8 versions.
Oh I just found the setting in makefile settings, under application ABI, you can tick on and off the different ones to find which works best for you

Download via usb is also not very fast but once its installed and running the debugger works and all seems to be fine. I'm now a little more hopeful that we can get somewhere with this for those who only have android based SBC's, like the K2

Its a pity there are not more really good OpenGLES2.0/3.x tutorial sites around. Its something of a niche I guess, so maybe this will turn out to be a goto place in due course.

But OpenGLES2.0/3.x is in itself a subset of normal OpenGL, for which there are a lot of tutorial site around, and one of the very best for learning it is

https://learnopengl.com/Introduction

The early demo's are mostly pretty easy to translate into OpenGLES for SBC's, though your power levels will probably not allow some of the more advanced stuff to work, but for a general idea of how to get things up and running and improve your visualisation of how they work, this is a really great site.

If you have a PC,  just work through the examples as normal OpenGL tuts, after that its awesome practice, fun and no small amount of frustration to convert to OpenGLES2.0

I'll give a free online hug, to the 1st one who reports getting the PBR examples running at a decent frame rate.

Those of you who are a bit more advanced might also enjoy checking out my colleague at IGAD,  Jeremiah van Oosten's website at https://www.3dgep.com/

It's a little less well organised and focuses on some really high level stuff as well as the basics, but it is a great resource to keep bookmarked and dip into from time to time. He's updating it a little more often now that he's just finished his masters degree. Some of the stuff he does makes my head spin, but its a good indicator of the level of tech you will need if you want to get into graphics coding at a professional level.

I've been sticking with my 3B for a while just to make sure all is compatible and well, but its time now to start using the 3B+.
There's no extra graphic power in this yet, (there maybe a slight upgrade soon), but mainly its the faster CPU and networking that I'm going to enjoy.

There are one or 2 minor issues, all my previous Pi's are mixed SD's using Jessie and Stretch, in other words they were Jessie versions which upgraded but never lost the Jessie files. So my older projects still worked fine on them with the old simpler lib files.
But the 3B+ has to use the new  Stretch Raspbian and has to use the new Stretch libs...so some things don't behave quite the same.

It's the small things, like I have to use my keyboard differently (its always the damn keyboard)


Anyway if anything comes up I'll let y'all know.

ermmm well, I can get the Friendly core Xenial build to run, as a text only system, no drivers for OpenGLES

and Ubuntu version appears not to boot at all, though the green LED is pulsing, so it should be there

Armbian is still in test

So it looks like the K1plus has to stay in the drawer of shame for a month or 2 until the software is a little more stable, which is a shame, as I had high hopes for this H5 board.

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