04-25-2018, 02:51 PM
(This post was last modified: 04-27-2018, 01:59 PM by Brian Beuken.)
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.
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.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's