Not an error as such, but there were updates to the Linux OS during the course of the book being written, and no doubt updates will continue as long as the book is in use, that may mean that some libraries are no longer available or use different names. You will need to be a little creative if you discover that a library has been updated, but generally the name is going to be something similar, and a quick visit to your board makers support site will often find the problems. I will also list variations here if I know them.
At the time I was using it the Raspbian version of GDB did not match the version VisualGDB was expecting, I provided a workaround in the book. The latest version of Raspbian however, now has the updated GDB and the fix is no longer needed.
The keyboard read system is still a cause of concern to me, it will work on most systems, but some just refuse and I am always looking for fixes. Download the latest keyboard readers from this site and if you find it still does not work after following the instructions in the header file, let me know what board you are using and the OS, I will try to resolve it if I am able.
Because the book is published by an American company, they changed a lot of my UK spelling to US versions. However as a native UK English speaker I wrote my code in UK English...most of the time! I do admit though, that I have been a little corrupted over the years and do occasionally use US spelling in code. Generally though the code is written in UK English and the text in US English. There may be instances though when the text is referring to UK code but accidently uses US spelling, I don't think I need to list such instances here, as they should really be obvious. Trust the code!
Hmm rather embarrasing, and kinda obvious, I repeatedly refer to raspbian as rasbian..sorry Raspberry Pi Foundation, that's a bad one, it slipped through the checks, any future updates will correct that.
Now that I finally have my hands on the hardcopy of the book I am finding a rather large number of what we will call typesetter errors, which show changes to my orignal manuscript text by the typesetters when the book was being formatted. Some of them are rather funny, but also can create some confusion, if there's a 2nd edition I will make sure these are fixed. But of course some errrors are just down to me making spelling or grammer errors that got missed in the proof and typesetting stage.
In the "From Hello World to Halo-It's just code" section, the line on the 2nd paragraph says,
"so even the most code wary the beginner, should pick things up as they go."
"so even the most code wary beginner, should pick things up as they go."
pages 8,11,12 there is reference to a grey dot, the typesetters must have changed this as it should refer to a red dot, they seem to have referenced the monochrome image and not the screen.
Page 61. I didn't explicitly explain where to add the line MyFiles FileHandler; it should be in the main function just after esRegisterDrawFunc(p_state,Draw);
page 63.There is a mention of a while(true) loop, but thats not actually needed until you do the multiple file loads. You can see how this is set up if you refer to PhotoFrame source code. You can add it if you want it will just make the single file display loop forever.
page 175 Again a great typesetter error, OOP stands for OOP. What? I wrote OOP stands for Object Oriented Programming.
Page 309 I got a bit mixed up with trying to explain OAB's (Object Attribute Buffers), which are actually a generic concept not an actual OpenGLES2.0 concept. Other graphic API's use different types of buffers and I think I just tripped over my laces after doing some work on another system and my brain farted that out. OpenGLES has a more limited type of buffer and its wrong to refer to them as OAB's. Also despite my tendency to refer to them as VB's they should strictly speaking be called by their proper name of VBO's Vertex Buffer Objects. So ignore my use of Object Attribute Buffers and call them VBO's.
Which is... a buffer containing various attributes which the GPU can use when properly informed of how the data is laid out!
Page 311 100x times the speed?? Ok, I admit, this is a slight exaggeration because it totally depends on the target you are using and the data you are sending to the GPU. I have had well over 100x the performance using VBO's and other tricks, but the actual speed increase you get will vary. Some of the factors are listed in the source code.
In page 318, The Fixed Pipeline Isn't Quite Dead- Though the text is all correct, there is no specific notice that the EGL attribute_list will also need to have defined a depth buffer, more info can be found in the forum