Small but important point, most of our systems don't have on off switches, so its not unusual to just yank the power cable out of them to switch them off. But that can cause issues, some obvious some not so.. Files which are open while the system is on, may not get closed properly and that can cause damage to them, when next you power up.

It can be subtle like things just not starting or severe like a failure to boot. Linux is pretty robust about things like this but its not immune to it, a damaged/unclosed file may get loaded, it may not, it may report the issue but chances are it will be hidden in a sea of text under your gui.

I have noted on a couple of occasions now that code I was compiling fine one evening refused to build or run the next day, these kind of issues can be very hard to track down, the assumption is naturally that you did something wrong in your code.

But, a new burn SD, restoring the libs or using a back up and things all work again. 


Its a pain and not always obvious, so just try to make a good habit of powering down before you pull the power cable out.

Hi Brian and Everyone,

I'm David Oberlin and it's been a while since I've done any coding. I studied Software Development at Forth Valley College, Falkirk Tech, around the millennium but due to complicated circumstances never found myself a job in what is now STEM.

In the last two decades I've played around with many different engines. From Adventure Game Studio and Arcade Game Studio to just modding other games like Doom, Duke3d and Unreal. I've got some killer Doom levels still kicking around and a few prototypes of other games. However I've never released anything formally, well except Doom levels.

I recently completed a beginners refresher course on c++ targeted for Linux on the Pi [Learn To Program Using C++ On The Raspberry Pi, Phil Gardner.] and I was happy to find out not a lot has changed. Anyway I'm really excited to learn more about the engineering side of game design. So I can hopefully deploy and support some awesome experiences on multiple systems.  At the moment I have a RP3B+ and an Odroid XU4 to play with however in future I'm hoping to get an UP Board for that x86 compatibility.

I'm looking forward to completing this book with you all and wishing everyone the best.

Kind Regards

David

The Up Core is the Up Squared's much smaller little brother,  but with an Intel® Atom™ x5-Z8350 Processor (2M Cache, up to 1.92 GHz) CPU with 64 bit architecture; Quad Core CPU. making it actually packing a lot more power.

It has a much smaller form factor than the Squared though, so you'l need an extension system as you only get one usb and 1 hdmi. There's lots of mini connectors for screens and things if you want to make a tablet or something. But to hook up to a network, either go wireless or use a usb with a network adapter.

That Atom CPU comes with integrated Intel graphics and should be able to outperform even the Squared....I say should because as hard as I tried I just couldn't get this board to function properly. Its software is no where near ready and I hit brick wall after brick wall trying to get it to boot up. Then when I did, it refused to compile anything... I'll come back to it soon, but for now, its a pretty neat board, the worlds smallest intel board, and has a lot of promise..but it stays in the drawer of shame till there's an update.

A very nice board this, intel based for a change, but running a version of linux. It wasn't massively hard to get set up as most of the graphic drivers come with it

I have the lower priced 2GB  Celeron dual core version, but its still fantastically fast compared to an ARM board. the more expensive quad core Pentium version was over my (at the time) $100 limit. I got it on a kickstarter for even more of a discount. Its now selling without case or (6v) Power for the base version at $145 ,so basically it is outside my self imposed price range. The 8G quad Pentiums got up to $350, not sure there's a good reason to buy these unless you need a portable windows 10 system.

Of course that power comes at a price, in this case a massive heat sink and case to hold it all together. But this beast is basically a mini PC, and you can install full windows on it if you want (I might)

Everything compiles and runs just fine....except.

All my model graphics are corrupted, not in a random way, just that their vertex info seems to be wrong. I assume, (perhaps wrongly) that even though its running GLES2.0 and GLSL100 it needs some more clarity in the data being sent to the shaders. I can indeed see that they are in the right positions, scale and rotations are correct, but the models themselves look more like the cubes you get out of car crushers in scrap yards... 

No idea why at the moment, it may be some kind of high/low bit arrangement, or it may be that some data is not initialising on Intel systems as it would on ARM (thats my current best guess), I'll play with it and find out.

One thing though, despite this odd corruption....this is the fastest board I've ever used, it blows all the others away... If I can fix the graphics it will be such a blast to work on.

Hi Brian!

I'm Wilson, a game designer that is currently undercover as a coder on this forum to learn more about programming.
Besides my interest on the book's theme, your apparent dedication to the forum and the laidback writing style convinced me to purchase the book

Still preparing for this journey, although I'm trying to figure a way to travel using my Mac. If any tech savvy Mac users know a good tool setup to follow the book, please share!

Looking forward to create cool games on my pi.
Thanks for writing this book!

The code isn't change a lot this month, but we have used a new key reader, (same as in my book) which gives us much more control and allows us to do multiple things

Also we address some of the speed issues, and refine the code a bit to get rid of warnings we previously just ignored but now have to take care of.

Our 1st framework is now ready, it can still use a few tweeks but we can take this forward to create a much nicer game next month.

well that didn't take long...
there seems to be a pirate kindle version doing the rounds, its cheap, so I can't blame people for buying it, but its very screwed up, the formatting is all over the place and it is barely readable

I have reported it to the publisher hopefully we can get it removed, but if you bought it, please insist on a refund and don't let these cheats spoil your expereince.

While the topic of shadow mapping is on the board, it is maybe a good idea to keep in mind that though the OpenGLES2 spec does not give us a lot of different buffer types, it does give us the ability to use multiple versions of texture samplers, at least 8 according to the spec.

So its quite possible, and often very desirable to use these in detail methods such as bump mapping. Here's a great explanation of the principles here (though the method is slightly different on OpenGLES2.0)

In fact passing large amounts of data of any kind, is nearly always going to have to be done via textures for static data, and frame buffers for more dynamic forms of data.
The ability to use a texture as a large store of info can make for some very exciting features.

The downside is most of these results are best seen in the Fragment shaders which for the majority of SBC's will cause a big drop in real time peformance. But some of the higher end systems can handle it, and FPS speed is not a priority for some sections of your work.

Feel free to post examples of your efforts here

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 through 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
https://www.raspberrypi.org/magpi-issues/MagPi70.pdf
https://www.raspberrypi.org/magpi-issues/MagPi71.pdf
https://www.raspberrypi.org/magpi-issues/MagPi72.pdf
https://www.raspberrypi.org/magpi-issues/MagPi73.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