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

This has been in the drawer for some time, but its time to look at it again as its one of the 1st H6 boards which become available and of course H6 means we have OpenGLES3.0+ possibilities..

Basically a chip replacement for the small form OrangePi One which has an H3, this big brother has 1GB of ram and that H6 with a T720 "multi" core GPU, no idea how many cores, but we've done nice things with dual cores, so lets assume that. Not sure its still currently in production but you can pick it up very cheap ~$20 from AliExpress which is OrangePi's main outlet.
I've been quite harsh on OrangePi's support in the past but even though its still hard to get what you want it does look like they are making a bit more effort, their site is quite well organised now and they do seem to be keeping a decent number of OS's on tap in an easy to find format. It also gives you an insight into just how many of these boards they churn out. 
22 different boards are currently listed... Not all are in still in production though (I assume) but its quite a wide range and they are cheap.


Debian Jessie is available, so I'll install that, and get back to you when I've had a chance to try it out this weekend.

I've not had a proper chance to give much coding advice on 3.0 or 3.1 or 3.2 but there has been a real boom in the last year of boards coming on the market which have the capability to run 3.0+

Sadly of course many of these boards don't actually have drivers to run even 2.0 but its starting to come through. I suspect strongly (but I honestly have no insight here) that Raspberry Pi4 will feature OpenGLES3.0+ so its going to be a big leap in terms of what you can do with your graphics.

But a word of caution.. Though for sure we can do more and there are some optimisations possible, we still only have a limited number of cores on our SBC GPU's so for the most part we will find things easier to do, but performance won't be massively improved (though there are some clear performance boosts), the best performance gains will come from letting the GPU handle things itself and avoid feeding it as is often the case 2.0. 

A few boards that we should look out for include

The Tinkerboard has now reached a quite stable level of support with drivers now available and it is a nice system it certainly handles 3.0, but 3.1 and 3.2 should also be possible (drivers!!!)
The Nano Pi T4/M4/Neo4 range... lovely machines, and very affordable, software is still a little behind and the OS can crash, but it is codeable
The RockPro64  one of several RK3399 based SBC(like the nanopi's) I don't have one yet but it looks like it has good support.
The RockPi4 hard to get hold of at the moment and I don't have one yet but I'm hearing nice things, though can't be 100% sure of CPU drivers
Any Allwinner H6 should have at least 3.0 but good luck finding an OS with drivers, I'm looking at you BananaPi and Orange Pi, though I'm sure Armbian will get there soon.

Hi,
probably is my fault but I'm unable to find the 3Dbase code.
Could point me towards the link?

Cheers
Gabriele

I was, waiting . . . for the email . . . 

Just bought the book. Not really a Windows user and don't think that I will be using Visual Studio any time soon, if ever. So will glean what I can from the reading.

Generally looking to improve my C and gain an insight into a little C++ and rudimentary gaming technique along the way. My background is largely in Unix/Linux, with bash, AWK and C; spending time with a collection of Raspberry Pi, and Arduino nano clones.

Increase in registrations not necessarily from RPi sales, but book sales perhaps.

From lesson 10 onward we are using a maths lib called GLM, but it has come to my attention that GLM does not compile under the standard C++11 compiler settings we have for our projects.

You therefore need to set C++14 instead, that may not be currently clear on your version of code:blocks, it will depend on when you updated your version and when you updated your compiler tools.
 
Generally speaking though if you go to, build options, and tab to Other options, you can add -std=c++14  and all should be well. you can probably untick the Have G++ follow the C++11 standard opion on Compiler flags as that will now get overridden. Newer versions of Code:Blocks will also allow you to tick a box to select C++14

If you happen to have an older version of GLM on your system, you can continue to use C++11, we're not really using many specific C++11 functions just some things are quicker to initialise and access with C++11, and C++14 gives the same options

Lesson 10 has been sent to MagPi and should be on the Github now, with a default setting for C++14

Very happy to see another good review on Amazon.co.uk 4* from a reader called Lee

I hope he comes to the forum soon, as there's an error in his review which states that the software we use can cost 100's or 1000's of pounds after 30days.

This isn't the case, VisualGDB is indeed only free for 30days but the cost of the basic Linux version thereafter is 89euros ($109), with a 50% discount for students or academics, that really is a fair price for the massive boost in productivity it gives you.

But even if you don't want to use VisualGDB, I have detailed elsewhere how to use Visual Studio with Linux Dev (free for the community version of VS) so you can still work on a target system for no money.


I hope Lee joins us soon so we can show him how to code for free.

Btw if anyone else has bought the book from Amazon or an online bookseller, a review (even if you didn't like it, feel free to be honest) would be much appreciated as it helps to spread the book around and lets people get a better idea if its the book for them.