There is a an example and instructions on how to run OpenGL ES 2.0 with QT
https://doc.qt.io/qt-5/qtopengl-cube-exa...ngl-es-2-0

This is more for my reference than anything in the book but if you are using an OpenGLES3.0+ system you will get significant flicker on your models.

Its being caused by an issue with the Depth Functions,  I don't know exactly why at the moment, but I have worked out if you disable dept_test you stop flickering...sadly you also get messed up culling on your poly's but at least step one in the bug hunt is reached.

Now...why are OpenGLES3.0 depth buffers different from OpenGLES2.0...thats step 2. I'll let you know.

a few of my students have been working with Linux dev options and that has thrown up a couple of gotacha moments.

1st you need to make sure your visual studio 2017 is updated to the latest version, it needs it, or it has issues working out the remote access.
2nd you have to have Linux devdlopment with C++ installed 

both the update and Linux dev options can be checked at Tools->Get Tools and Features.

Even though you may get options to create new linux project. or it may load one of my dual config demos, you will have issues if you have not updated and installed the features.

Hey all, a reader has pointed out there is quite a lot of missing files from chapter 6 on, sorry I thought that the book made it clear you are building on the code you produce, but I accept that might not be as clear as I intended, and indeed some small demo files I reference are not on the download site, so I am going to start adding staged builds for chapter 6 onward to help you, though I still want you to try to build on the code base as you go.

I'll get this in place over the next few weeks

The Download page now has a dual config version of Space Cadet, both VisualGDB and VisualStudio for Linux
Be sure to add a connection to your SBC, in the Tools->Cross Platform->Connection manager, and change all the current targets to yours. And build as an ARM config

At the moment the build is Raspberry Only, but its not a massive leap to make it generic to all Linux SBC's

I also note that you need to use the Linux Console window to see the code's printf output. Debugging/break points and watches, all work fine but there's a bit too much strange info you don't need, not sure how to turn that off.

If your VisualGDB Trial has run out and you don't want to buy an extension, you can continue with this Visual Studio version, its a little clunkier, and does sometimes crash your Visual Studio, but generally it works ok, and its free.

Had this for quite some time but found it a bit hard to get going due to poor software, but thats changed, its got a bit more mature and has a decent degree of support now.  They have a decent Debian (Jessie) and Mesa Libs go on. It actually has GLMark2-es2 on board when installed, and does seem to run pretty well through the intital runs, though it never completes the cycle so gives no score. But it seems very fast. Its an OpenGLES3.0 system so it should be pretty nippy.

Of course no native drivers on board, so Mesa is doing the work and it does seem to be emulating a lot.

Test code does build but with a bit of effort, it can't run more than 1 core at a time, it freezes if you try to do 2  or more, so clearly needs a serious heatsink to get some decent performance out of it.

Anyway, demo runs, its ok, no real problems, but only at 26-30fps, which is way below what that GPU is capable of. So while I know this to be a beast, until proper drivers come out its not going to be high on my list boards to play with.

I'll keep an eye open for updates though, if it gets its GPU sorted and maybe has a better heatsink fitted it could be really nice.

Now 3.0 and 3.1 gave us a lot of new stuctures and buffers to use making it really quite on a par with OpenGL itself. 
There was also an impressive Extension pack for 3.1 which was available only for Android

However those Android only features were then wrapped into OpenGLES3.2 as standard features and this has allowed OpenGLES to continue with its alightment of OpenGL by adding few very impressive extra features including two new shader types


Tessellation shaders
Geometry shaders
Now some OpenGLES3.1 boards do have Geometry and Tesselation shaders as extensions (Tinkerboard for example) but thats just because they have the Android Extension Pack. Its safer to only attempt Geometry and Tessellation on a full 3.2 board in Linux, but probably safe if you are coding in Android.


These don't in themselves give you any extra power, in fact they can be quite a cost on framerates if you over use them, but they do allow you to greatly enhance the detail of your graphics from reasonably simple basic model types. 

Tessellation shaders (they come in a pair) in particular, really need a massivly powerful GPU, but when used well can create wonderful Levels of Detail in our models, but I confess I find using them to be overcomplex and combersome, running a few tests on a very simple PC GPU card shows significant slow down, I havn't tried to build anything on an SBC, but I imagine the frame rates would plummet. But for fairly static screens, not requireing real time updates like menus you can turn simple models into things of beauty.
Here's some info on Tessellation shaders...prepare for a brain melting.. 
http://ogldev.atspace.co.uk/www/tutorial...ial30.html


Geometry shaders however used sparingly can do some really cool things, and my favourite OpenGL tutorial site has a great demo on how to use them.
https://learnopengl.com/Advanced-OpenGL/Geometry-Shader


There's also more advanced texture types, ability to work with compressed textures reducing our footprint,  new blending capabilties and mutlisampling added as well as (praise the coding gods) some debug features which really start to be needed as all these extra features can make a shader chain much more prone to bugs.

As with OpenGLES3.1 though we must be aware that we have very very feeble GPU's on an SBC, and just becuase they can do something, does not mean its wise to do it. In the same way as per pixel shading looks amazing, don't expect 60fps updates if every model uses it. Likewise Tesselation and Geometry shaders can greatly enhance the visual effect of your project with little effort on the coding side, it all takes up processing cycles and can slow things down.

But we dont' care do we
Even though its been out a couple of years now, there really are not many devices using it yet, Only high end phones and tablets, but developers are are still mostly targetting 2.0 and 3.0 as base level systems due to teh market share they present.

So with only a few devices, there's not a lot of demo's out there to show the real power of the new shaders... I llike to refer to the ARM developer site for tutorials and explinations, well more explinations than tutorials.

However do remember what I said about OpenGLES3.2 being more complient with OpenGL, if you check out some OpenGL4.0+ demos you'll certainly get some ideas of how to use GLES3.2 in anger.

https://developer.arm.com/docs/100587/la...engl-es-32

There are a number of small tweaks to 3.0, but overall its not a massive leap in the same way 3.0 was over 2.0.
But there is something that is wonderful to play with and can really give us quite a boost.

Compute Shaders

Compute shaders basically let us pass over some of our more complex graphic tasks to the GPU to handle. Its not quite the same as multi core coding on CPU, since the CPU itself can't actually get hold of any of the info the compute shader produces (well yes it can, kinda, but only by grabbing buffers which is slooowww), but it is essentially letting us use redundant computing power in our GPU to release some work from our CPU instructing our GPU to do things.

The compute shader is best used for repetitive graphical processes that don't need to be interrupted, and can run in the background creating different buffers or textures that your normal draw called shaders can make use of. While you are busy setting up your models, doing your physics, working out what AI is going to do, the GPU is idle, so we can make it work on creating buffers for things like shadows or lighting systems or even ambient colours to indicate passage of night and day. that can be stored in a GPU buffer ready for your shaders to work with when you are ready to execute a draw call.

A short intro here.

https://community.arm.com/graphics/b/blo...te-shaders

Now sadly it has to be said, SBC GPU's are not great for this kind of work, they are often massivley overloaded just trying to render so don't have a huge capacity to run compute shaders as well, but as with all things SBC, a little used wisely can go a long way.

Here's some excellent simple tips on changing your work flow from OpenGLES2.0 to OpenGLES3.0

http://www.shaderific.com/blog/2014/3/13...engl-es-30

The key thing to consider is that there's not a huge amount changes on the client (main code) side, the bulk of the changes happen in the shader language itself.
There's a few new features you might want to send values to but its still a case of the client sending attributes, now called in values,  and uniforms and letting the shaders to their work.


That said there are rather a lot of nice things in OpenGLES3.0, heres a list I found on stackoverflow. Most of these relate to new data structures you can use, or extensions to exisiting structures, making your shaders far more flexible.  Most normal mortals won't use but a fraction of these new features but you may discover that something you are trying to do, but failed or found too slow, is now much more plausible.  
For me the biggest thing is VAO's and Instancing and multiple render targets. These make it very easy to populate and dress a scene with large numbers of the same model, with or without manipulation, as well as a far easier way to create shadow buffers and light effects.

• OpenGL Shading Language ES 3.00
  
  
• transform feedback 1 and 2 (with restrictions)
  
  
• uniform buffer objects including block arrays
  
  
• vertex array objects
  
  
• sampler objects
  
  
• sync objects and fences
  
  
• pixel buffer objects
  
  
• buffer subrange mapping
  
  
• buffer object to buffer object copies 314
  
  
• boolean occlusion queries, including conservative mode
  
  
• instanced rendering, via shader variable and/or vertex attribute divisor
  
  
• multiple render targets
  
  
• 2D array and 3D textures
  
  
• simplified texture storage specification
  
  
• R and RG textures
  
  
• texture swizzles
  
  
• seamless cube maps
  
  
• non-power-of-two textures with full wrap mode support and mipmapping
  
  
• texture LOD clamps and mipmap level base offset and max clamp
  
  
• at least 32 textures, at least 16 each for fragment and vertex shaders
  
  
• 16-bit (with filtering) and 32-bit (without filtering) floating-point textures
  
  
• 32-bit, 16-bit, and 8-bit signed and unsigned integer renderbuffers, textures, and vertex attributes
  
  
• 8-bit sRGB textures and framebuffers (without mixed RGB/sRGB rendering)
  
  
• 11/11/10 floating-point RGB textures
  
  
• shared exponent RGB 9/9/9/5 textures
  
  
• 10/10/10/2 unsigned normalized and unnormalized integer textures
  
  
• 10/10/10/2 signed and unsigned normalized vertex attributes
  
  
• 16-bit floating-point vertex attributes
  
  
• 8-bit-per-component signed normalized textures
  
  
• ETC2/EAC texture compression formats
  
  
• sized internal texture formats with minimum precision guarantees
  
  
• multisample renderbuffers
  
  
• 8-bit unsigned normalized renderbuffers
  
  
• depth textures and shadow comparison
  
  
• 24-bit depth renderbuffers and textures
  
  
• 24/8 depth/stencil renderbuffers and textures
  
  
• 32-bit depth and 32F/8 depth/stencil renderbuffers and textures
  
  
• stretch blits (with restrictions)
  
  
• framebuffer invalidation hints
  
  
• primitive restart with fixed index
  
  
• unsigned integer element indices with at least 24 usable bits
  
  
• draw command allowing specification of range of accessed elements
  
  
• ability to attach any mipmap level to a framebuffer object
  
  
• minimum/maximum blend equations
  
  
• program binaries, including querying binaries from linked GLSL programs
  
  
• mandatory online compiler
  
  
• non-square and transposable uniform matrices
  
  
• additional pixel store state
  
  
• indexed extension string queries
  

Hi Brian,
sorry to bother you again... Are the assets of chapter 7 available for download ?

Ciao,
Gabriele