Not so much a mistake as a confusion, when you have got your photoframe up and running, we are getting ready to start work on a proper game using a dynamic buffer, the code for this is explained in 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 just 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.

There were a couple of Chapters I had to chop out the book to keep the page count to the publishers requirements. At some point I may tidy these up and include them here or if there's ever a 2nd edition.

The one I enjoyed working on most was the creation of a proper 2D framework, fully using the GPU and moving away from the clunky but simple surface system. That would be much more appropriate for some kinds of bullet hell games. but it was quite large, and aside from the better GPU usage didn't offer anything more than the Skramble chapter did. If you get to the point of understanding how the 3D games work, then setting up a 2D viewpoint is not a huge leap so I dropped it.

There was also a chapter on optimization, which provided ways to almost double frame rate with a range of simple and not so simple tips. It was mostly technical issues, to point out the failures of the code that went before it, but I thought about it and I feel I gave readers plenty of notice that there were several ways to optimize code and that they would get more of a thrill from that if they discovered them alone. So I left it out. But I'll drop hints in this forum.


A few chapters were not quite finished but would have added some useful technical content;

I wanted to do a lot more on shaders and light and using bump mapping and other tricks, but I noted that the performance drop was so severe on the Pi, that it would have been even worse on lesser machines, I decided to not commit to it and will leave it to discussion here.  I spent quite some time doing cool things on the Odroid XU4 only to discover that the Raspberry's frame rate would drop to single figures doing the same things even at lower res, making it clear that specific optimizations would be needed and that would cause too many individual case situations to be explained. Its better if I add content to the site and then people can choose if they want to use particular effects as they need them.


A more detailed chapter on multi core usage and use of a job manager to vastly increase performance, but I did find that most of the multi core systems I used, especially Raspberries became overheated very quickly, so I needed to do more research on that, which I will return to. I think the conclusion I reached then, was to consider a sparse use of multi core work which is not really a good design method for game architecture. I am not convinced its an SBC issue, I'm pretty sure it was my methodology and I didn't have enough time to fully explore it.

There was also a chapter on creating a (very) simple Physics engine, but I actually scrapped that when I realized that it was just easier to use Bullet and avoid long and rather dull math heavy content, which I don't enjoy.

I also put down an outline chapter on a more accurate bullet physics vehicle controller for the race game to get something like this but noticed I wasn't really explaining anything differently from the examples I found on line, and I didn't want to just parrot the code that was available,  so if you want to do more accurate vehicle physics its probably best to check out the bullet forums and review what they say. But I will be using this more accurate car control in the finished version of the Race game (coming soon)

Finally I did a nice outline chapter on procedural terrain generation, and fake instancing of detail, but again it was overreaching the base level target of a raspberry Pi system, though it was so much fun to do, maybe I'll come back to it if I can include the performance improvements that would be needed to make it viable.

In the listed graphic setup code for the early projects, the init_ogl function is a basic system which works fine for windowed EGL display, but it should also be possible to set full screen mode by sending either 1920x1080 or the returns value from

Hello,

When I try and get the pi to display the window in full-screen my monitor will turn black and stay black until the project breaks. When I hard code the resolution it works fine. For now I am just running the code with the resolution hard coded but any tips regarding this subject would be cool. 

I am also having another issue that could very well be a typo. When I try and get the picture of Lenna to come up I can see a opengl window opening up but the program output gives me a error until I break the program. I believe it has something to do when I draw the rectangle but I am not certain.

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 defined as below, if you have expanded from the cubefast demo, you will need to update your attribute list to look like this, the hellocubestex demo already has this set up.

static const EGLint attribute_list[] =
{
EGL_RED_SIZE,
8,
EGL_GREEN_SIZE,
8,
EGL_BLUE_SIZE,
8,
EGL_ALPHA_SIZE,
8,
EGL_SAMPLE_BUFFERS,1, // if you want anti alias at a slight fps cost
EGL_SAMPLES,4,  //keep these 2lines, espeically useful for lower resolution
 
EGL_DEPTH_SIZE,5, //<<<<this allows depth buffers to work
EGL_SURFACE_TYPE,
EGL_WINDOW_BIT,
EGL_NONE
};

Page 311 says you will get 100 times the speed using VBO's

yeah, well hmmm, a slight exaggeration on my part, it does depend on what target you are using, and also what format the data is, how much there is of it etc.  So while it is actually possible to get 100x the speed, really with the cube demo, it will only get that good on one of the bigger 8-16core high clock GPU systems I have here, the standard Raspberry 3 and lesser models, can't really match that. Though with  proper optimizations you can get pretty close to that.

But even if you can't manage 15000 cubes in 30+fps, you will notice a big boost in speed simply by avoiding doing too many repetitive calls to the GPU and focusing only on doing the minimum number of draw calls.

The cube demo could be a great demo to show you fake instancing, which allows you to draw around 32 cubes with one draw call.. Now..that does give you a massive speed boost as does using indexing, which I don't use anywhere in the book...try checking it out. 

I think I should make it clear in the next edition, that 100x is really for the higher end GPU's and the majority Raspberry users won't get that much

Hello my name is Juston Metarref. I am currently a student programmer and am looking forward to making games. I'm mainly here to ask questions about the book. Looking forward to the adventure.

Got asked if I was going to include OpenVG in any tutorials.

I really don't know, I tinkered with it when it 1st came out but only as far as the usual make a shape kinda demo's, I never saw any point in using it in games.

I'm not too sure if it would add anything to a game framework other than making menu's a bit simpler. I don't even know if it can co-exist with OpenGL render buffers doing their thing

Perhaps others can give some input here.  Looking at the Raspberry forums, its a viable concept for 2D and menu systems, but I can't really see what it offers those of us doing 3D?
If it could handle overlays then it might be an interesting way to quickly create text boxes, so its worth an investigation at least.

I do have Jan Newmarch's book Raspberry Pi GPU Audio Video Programming which has a small section on using OpenVG for text rendering, so I might work through that and see what I can do with it.

This one might happen by accident when you are setting up your project or changing some values in the makefile settings

Check the type of project you are making in Makefile settings Project Type, it should say Executable, if its one of the other 2 options it will not run.

It may be you accidentally set this value by moving a mouse over it and not noticing, or you edit the makefile in error.

But bottom line is the fix is to make sure you are building an executable, just click on the box and select executable, then apply.

In Chapter 6, Buffers Buffers everywhere, 

I got a bit mixed up with trying to explain OAB's Object Attribute Buffers, which are actually a generic concept not an 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 quite wrong to refer to them as OAB's

And in fact 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!


I'll make a note to tidy that section up