Now, it has to be said, my book is not designed for total beginners, it does expect you to know at least the basic concepts of C/C++, how to make classes, the different variable types, passing and receiving parameters, understanding data structures, STL, the build process, OOP principles and so on.
It's aimed at someone who has learned C++ from a book or course, but isn't really sure how to create a game with it, I'm not expecting guru levels of knowledge but those basic skills need to be there.


If you really have no knowledge of C++ then you are going to struggle at times. I do keep the code in the book very simple especially at the start, but the book isn't a C/C++ tutorial, that would have made it twice as big and 3 times duller.

I will always do my very best to help you, but there will be times when you need to take a step back and focus on your C/C++ skills before you attempt to tackle the book.
If you have a PC, I very much recommend working though this book which will give you all the basic skills you need to move forward. It doesn't really go into graphic game programming much, despite the title, but it does give you a lot of very useful understanding of C++ that you can use here.

If you don't have a PC and just a Pi, or just prefer to use a Pi, then I might be able to help;

I have been writing a fairly simple monthly how to code games series which is published in the Raspberry Pi foundations MagPi Magazine, which can be downloaded from the links below, as well as my articles there are some other great projects and articles, so if you've never seen MagPi, its well worth checking out and getting a sub to keep it going.

These are very simple articles, which you can work on with just your Pi and will focus on explaining how C++ works, while building a few very simple games. Some of the concepts and methods will be familiar from the book, simple flyweight design pattern, though more GPU based than the book is.


The plan is to make 12 such articles and I'll list them here as they come out.



https://www.raspberrypi.org/magpi-issues/MagPi65.pdf
https://www.raspberrypi.org/magpi-issues/MagPi66.pdf
https://www.raspberrypi.org/magpi-issues/MagPi67.pdf
https://www.raspberrypi.org/magpi-issues/MagPi68.pdf
https://www.raspberrypi.org/magpi-issues/MagPi69.pdf

Hello again, 

I am getting started on the Invaders game and was a bit confused with the bit about creating the object class. 
I am not sure when it is the class is supposed to go. I created a header called objects.h and put the code in there but when I do that my Shooter.cpp gives me errors.

 Severity Code Description Project File Line Suppression State

Error [Clang IntelliSense] Error: no matching constructor for initialization of 'Objects' InvaderStart c:\users\justo\desktop\invaders\invaderstart\Shooter.cpp 10

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.

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.