Errors, Typos and plain old fashioned mistakes

click on image for a FAQ page

Library changes

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.

GDB now updated

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.

Keyboard and mouse

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.

American Spelling

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!

Raspbian or Rasbian

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.

Errors in the book text (paperback version)

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

Should read:
"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 47, the listing for the initial version of the graphic set up, lacks the ability to set a full screen mode due to some missing setup values, review the fix on the forums here. It will work fine on a non full screen windowed display, and download versions have this fix.

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 68-77. You can add this code to your photoframe example and get it up and running with not too much effort, but really its explaining the code you will be downloading to use in Chapter 5, so typing it all in is optional. I should have made that clearer.

Page 88- The code listed does not specifically give an example of the overloaded Objects(char*, MyFiles*); constructor, or the overridden update method in Objects, the constructor has been added to the InvaderStart source code though, so if you download (as suggested) you will not have a problem. You need to add your own overridden update method as you see fit.

Chapter 5 generally...94- specifically. The's quite a few code snippets describing the invaders code which is there to aid a discussion and show examples of methods to use, especially page 94 and 95 where I discuss using an array, then a vector. The snippets of code are not intended to be directly slavishly copied in to your Invaders project, there are a couple of missing values and changes to the constructors that are not obvious. The text and code are there to debate the use of an Array and then to use a vector as a better solution See forum

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