There are a few people still making MD2 models which will let you create some cool games using the basic MD2 loaders explained in the book, one of the best is.
http://md2.sitters-electronics.nl/

You should also try to write systems for MD5's and I'll cover that on this site soon as well as a few other model types. 

I did get asked by some students for FBX, but that may be aiming a bit high for an SBC, but at some point I'll give it a try, if you do it, let us know.

I soooo want to love the Tinkerboard, I really do, and I suspect I will, but I need to wait just a little bit longer for the software to be just right. But for sure its been improving with each release, its almost at this point usable.

It does have graphics, now (it didn't when it was first released) it does have X11 video GL2.0 and GL3.0 drivers, and therefore it will build the current maze demo, but the GPU does not yet seem to be accelerated, so for the moment at least it chugs like me in a 10m sprint to the donut counter, ie it does the job, but not fast. 

It has the potential to be a monster machine with ES3.1 (maybe 3.2) and it does report that 3.1 is possible, so it may be we can play with some 3.1 shaders, but until the acceleration is switched on, its not going to be quite good enough.

Soon though, very soon.

A very interesting board indeed, its a zero in its layout, but this time a quad core.. Sadly only a Mali 400Mp2 but it should out perform or at least match the Raspberry Zero in graphic terms, and blow it away in full computing mode.

As always though the software isn't here yet, Armbian does a fair attempt at getting it up and running but terrible graphic glitching makes it useless for any kind of graphic systems, and its GLMark2-es seemed to think it had OpenGLES3.0 GPU on board, the Mali 400's are strictly ES2.0 which probably explains why it wasn't able to complete the tests,though it did get quite far into them, though very slow

I'll do an update/upgrade cycle on it from time to time to see if there's any improvement, but for now this is a non starter for our gaming purposes.

Also interesting to note it gets bloody hot, I put a heat sink on it, wouldn't want to run without.





edit... ok I found a slightly older verison of the Armbian/ubuntu test build which installed at 720p and it is much more stable, after update and upgrade it is still quite stable, no glitching and GLMark2-es2 worked better, showed as Mali400 and ran all the tests, but it reported a really crap score of 52, which is feeble compared to a Raspberry zero which averages 100. I suspect its not fully accelerated even though it got through all tests.

Not sure what to make of this, its quad cores make it a great unit, its crap graphics make it pretty useless, but functional barely. I guess as with all maker boards it depends what you want to do with it, if you need a small cpu system, its amazing.
I can't really tell if the GPU is accelerated, but given its an Allwinner it probably is/will be, so that score might go up as the Armbian guys get things moving on it.

Maybe Banana Pi themselves might get round to putting a decent OS with acceleration (don't hold your breath there though)

My students are working on a Raspberry Pi project and one of them was looking for a nice screen grab program. Its not as easy to do as it might seem since the Raspberry does not use X11 to display its screens, instead it uses Broadcom's Dispman system. 

but there is a great package I used for all my raspberry screen shots. fast, effective and once set up, very reliable.

Use Raspi2png

you can get it here
https://github.com/AndrewFromMelbourne/raspi2png

clone the rep, compile it, and its there when you need it, its especially useful to activate it from an SSH console.

67 introduces some graphics into the mix which will see us begin to create basic systems that we can build on.

We still have some tech stuff to deal with, and its glossed over a little for the beginners, but once we can put our own graphics on screen we're nearly at the point of being able to place and scale them to create game environments.

oh damn, what a horrible feeling, there is a tiny error on the Amazon preview which I assume will also be in the book, (I've not seen the finished book yet)
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."


I'm sure there's a lot of errors in the final book, it was proofed by various different people, but things get missed. If there is ever a 2nd edition, I'll fix things like that, but nothing I can do at the moment as the book us currently at the printers (or just been printed)

Getting OBJ files to load isn’t the hardest thing in the world, but it does present a few challenges.
OBJ is a fairly standard format, but it’s been around long enough for it to have had a lot of additions and updates to make variations a problem. So if you write a reader for your own very specific types of OBJ’s you may find it lacks the flexibility to load other supposedly standard OBJ’s.
OBJ’s are important though, they represent the simplest kind of multi face model you are likely to load into your project, once you get to the realization that typing in anything more than a cube is a major pain.
Key to the OBJ standard is that it is text based and readable meaning you can check in an editor what kind of data your OBJ file has, make sure it has no strange extra features and get a reasonable assessment of how many sub objects it has and what their names are, which can be useful if you want to do work on specific sub objects, like a car wheel for example.
OBJ files are also usually (but not always) associated with a MTL or material file, which provides additional information that relates to textures and lighting features your renderer has to accommodate.
I use a software library to load OBJ’s,  TinyOBJLoader, and I do that for 2 reasons

1 it works almost 100%
2 it gets updated to cope with additions to OBJ standard.
 
Getting TinyOBJLoader installed and working, is not in itself very hard, but understanding what it provides can be a bit of a leap. TinyOBJLoader is a parser for data, it reads the text and stores the resulting numerical data….somewhere.
It’s important to note that not all the data is parsed, only the data it currently understands, and also it’s stored in data structures which are supposed to be passed to it, and supplied by the users app. But for us, just wanting info on the vertices/uv and textures we can extract all we need, if we also need normal and lighting info it’s there too.
So to help in understanding what TinyOBJLoader does, we need to look at what it provides. Data…but in what format? Fortunately for us there is a very nice example of its use in the github repos which proves a very simple loader and viewer. The viewer itself is old OpenGL1.0 format so not much use to us, but it does give us a good guide how to use TinyOBJLoader
The Viewer.cc file is a simple C++ system that loads and renders a model. The key part we want is the LoadObjAndConvert function which has these input values

static bool LoadObjAndConvert(float bmin[3], float bmax[3],
                              std::vector<DrawObject>* drawObjects,
                              std::vector<tinyobj::material_t>& materials,
                              std::map<std:: string, GLuint>& textures,
                              const char* filename)

For coders that should be all we need to know about… the bmin[3] and bmax[3] are simple arrays we can pass that will provide box min and max xyz values to allow us to have bounding boxes.
Then we have 2 vectors containing pointers to DrawObjects which is a simple data structure defined beforehand, and the other is the location vector of a material structures, also defined in TinyOBJLoader.
Next up is the location of a std::map, which will associate texture names with texture handles.. allowing us to load a texture one time (per model)
All these things are defined in the example for us to use in our own code.
  float bmin[3], bmax[3];
  std::vector<tinyobj::material_t> materials;
  std::map<std:: string, GLuint> textures;
 
and DrawObject is a structure and looks like this
typedef struct {
  GLuint vb_id;  // vertex buffer id
  int numTriangles;
  size_t material_id;
} DrawObject;
So a vector of DrawObject’s looks like
std::vector<DrawObject> gDrawObjects;
 
Finally of course the file name, as long as the file is correctly referenced LoadOBJAndConvert, will do exactly what it has been named to do and can be called.
Each DrawObject is essentially a sub object of an OBJ Model, some models may only have 1 sub object, but more complex models will often consist of several, A car model for example may have a body and 4 wheels, making 5 sub objects. So the vector’s size will tell us how many objects there are.
Now, when we call this function, we load the model, in all its parts, its material info goes into the material vector, the gDrawObject vector contains all the sub objects needed (with a VB(O) rather than a vertex list) and there it’s a simple process to render the object.
We will have to change the location of the vectors and map, so that our individual object can access its own data, but overall that’s not making any changes to the function itself.
 
The Key point is to think about what the function needs to work and what it returns.

When it comes to rendering, the old OpenGL1.0 draw function isn't something we can plug in directly, but we should be able to read the draw function and take note that it is working out how many shapes (sub objects) to draw, each with their own material ID to get access to the texture,(and other lighting info), and the number of triangles needed to draw,

In its raw form, the conversion produced VBO's (with id's held in the DrawObject structures) with 3 floats for verts, 3 for normals, 3 for colours(RGBA) and 2 for UV's You may not need or want to use all these attributes, so you can adapt the function if memory is tight, but you can certainly work out your stride pattern to enable your attribute buffers and send the required attributes to your shaders.
Once you set up your attributes, a simple draw call for triangles gets your models on screen.

have fun.

Readers of the book will have noted that many times I pointed out that there were better ways to do many of the concepts raised.

In fact the way most of the code was written it is very obvious that there are better ways, but I took a decision not to go into much detail on that, simply to allow new users the chance to get totally comfortable with getting their code to work. Forcing people to optimize code before they have fully understood what they are doing is a recipe for disaster, so for me it made sense not to get into that in the book, just show the basic code, get it working and once its working, then is the time to explore how to make it work better. 

It would be nice to have a discussion here on how we can improve the performance of our projects (by quite some amount) if we were to use a more effective render system, and implement some multi core work. I'd love to hear your thoughts on how you can improve things, and show some results to inspire others to really get that code moving.

Hello everyone, 

It seems like I'm one of the first members here. I'm known as Thijs van Boesschoten, I've studied networking and am doing a study on programming at the moment. In my networking classes we were thought how to use the pi as a networking tool/system. As such at the time I bought a Raspberry 0 and Arduino uno and I'd like to see what they will be able to do game wise(hopefully without melting). 

As such I'm seeing myself as a near complete rookie and would love to learn more about using SBC's and game programming.