I've noted before that I had some trouble with ubuntu systems throwing up strange errors unable to open Displays causing failure of our test projects I thought it was limited to Ubuntu, but today I had it on a Tinkerboard system which is Debian, it did however throw a much more useful No Protocol supplied, error, which after a bit of googling resulted in some answers.

I can't honestly explain much about how any flavour of Linux works, its a total mystery to me and the way it seems to over protect things you want to directly access is frustrating, but it does seem that  some of our issues are related to lock of display system by the OS.

If you don't have root access we know some things get hard to use, like keys and mouse, but it seems also the screen....


One solution is to enter 
xhost +  
on a terminal, and then you can finally open the screens.

But then of course you have all kinds of other issues

The book seems to be selling well but I'm quite surprised at the lack of chat/requests for files we should be seeing here.

Are people having issues with this forum, or with the book, mail me if you need help?

I was not very happy with the price of my book, on Amazon, but its something I had no control over, but now I'm happy to report the price has been slashed on both the UK and US Amazon sites..

It might seem strange to be pleased at losing money, after all I do get a royalty for each sale, but the book was never intended to make me rich lol, if such a thing is even possible now, just to get people trying things out on their SBC's. 

Lets hope the new price attracts more customers and brings them here to try things out and share their work

https://www.amazon.co.uk/Fundamentals-Ga...544&sr=8-1

I have had a few issues getting a 100% reliable keyboard routine, but generally its only wireless keyboards that seem to give a problem.
My own personal keyboard when coding is a small Logitech keyboard/mouse combo, it works great, but it is not actually recognised by all my Pi's in the same way, some think its a mouse, some think its a keyboard

You need to review the AreYouMyKeyboard method in the Input class, it will normally be set up as kbd, but I sometimes set it up as mouse, whichever version you have, and you find its not working, try the other.

There are also a very very few cases where this fix does not work, but its very rare, in which case you need to directly enter the event file for your keyboard in the keyboard handler.

If you can't solve it, feel free to mail me and I'll try to help you out!

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: 1)

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