I've covered this before but its a common error as its one of the 1st things people are getting stuck on. It only applies to Raspberry

If you are having trouble getting Lenna to come up there's 2 possible issues.
1st the formatting in the book for RectVertices is terrible, making it easy to misread, it should look like this

GLfloat RectVertices[] = { 
                                     -0.5f, 0.5f, 0.0f, // Position 0.
                                     0.0f, 0.0f, // texcoord 0.
                                    -0.5f,-0.5f,0.0f, // Position 1.
                                     0.0f,1.0f, // texcoord 1.
                                     0.5f, -0.5,0.0f, // Position 2.
                                     1.0f, 1.0f, // texCoord 2.
                                     0.5f, 0.5f, 0.0f, // Position 3.
                                     1.0f, 0.0f // texCoord 3.
                                     };

Be careful to enter the data correctly, I see a lot of people mistyping that. (cut and paste this)

2nd, this one is my fault, there's a couple of lines missing in init_ogl which didn't cause any issues on older Raspbian GPU drivers but do on the current version if you are setting up a full screen display (windowed displays are "usually" ok)

Where you create an EGL window like this
//Create an EGL window surface
                 state->width = width;
                 state->height = height;

                 dest_rect.x = 0;
                 dest_rect.y = 0;
                 dest_rect.width = state->width; //it needs to know our window size
                 dest_rect.height = state->height;

                 src_rect.x = 0;
                 src_rect.y = 0;

you should add these 2 lines just after

                  src_rect.width = state->width<<16;
                  src_rect.height = state->height<<16;

If its not done the results of your set up are unpredictable, it may well work fine but best to add it as it should have been there in the 1st place.

I've noticed since the last update of VisualGDB that its having a bit of trouble with the timestamp of files and keeps throwing up Stderr warnings about files being in the future.

This is annoying and might be a bug in the new download system of VisualGDB, though it does not seem to stop files being sent to the target it probably sends them repeatedly, but there's an easy fix

In visual studio, go to Tools->VisualGDB->SSH Host Manager

Then find and highlight your device and select edit settings.

Change Transfer folders using .... from On-the-fly Tar to File-by-file SCP(slow)

don't worry about the slow warning, its not really slow

Now files don't throw up that timestamp error.. I've mentioned it to sysprogs

When you create a new project be sure to specify SCP transfer and you will never see this issue.

Have to be honest,  I've had to use the Visual Studio for Linux system a lot more this month due to many of my students working on Raspberry projects without VisualGDB.  And since I first posted my view on this, there seems to have been some updates (or I missed the update 1st time) and the current version of this tool chain is actually very nice.

It's got almost all the features of VisualGDB, though some library locations can be a bit hard to find/set up but once done its all fine.

I'm not going to give up on my love for VisualGDB, but for sure its now perfectly viable to work with the Free version of Visual Studio and hook up your Pi with no purchase of software needed..

I'll provide multi config builds of all projects over the coming months.

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.