Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 35
» Latest member: AmateurUnova
» Forum threads: 111
» Forum posts: 249

Full Statistics

Online Users
There are currently 7 online users.
» 0 Member(s) | 7 Guest(s)

Latest Threads
How to Register
Forum: Scratchpad Games
Last Post: Brian Beuken
Yesterday, 02:10 PM
» Replies: 0
» Views: 5
Installation of Bullet, S...
Forum: Fundamentals Errata/Questions
Last Post: Brian Beuken
Yesterday, 12:23 PM
» Replies: 1
» Views: 6
Now using the 3B+ as main...
Forum: General Chat
Last Post: Brian Beuken
Yesterday, 10:00 AM
» Replies: 0
» Views: 5
C++ Coding MagPi #73
Forum: General Chat
Last Post: Brian Beuken
Yesterday, 09:34 AM
» Replies: 0
» Views: 5
C++ Coding MagPi #72
Forum: General Chat
Last Post: Brian Beuken
Yesterday, 09:33 AM
» Replies: 0
» Views: 2
C++ Coding MagPi #71
Forum: General Chat
Last Post: Brian Beuken
Yesterday, 09:31 AM
» Replies: 0
» Views: 2
installing STB and GLM
Forum: General Chat
Last Post: Brian Beuken
Yesterday, 09:22 AM
» Replies: 0
» Views: 5
Asus Tinkerboard
Forum: Other SBC's
Last Post: Brian Beuken
09-23-2018, 08:51 PM
» Replies: 2
» Views: 340
Linux getting in the way ...
Forum: Other SBC's
Last Post: Brian Beuken
09-23-2018, 05:55 PM
» Replies: 2
» Views: 37
XU4
Forum: Other SBC's
Last Post: Brian Beuken
09-23-2018, 05:33 PM
» Replies: 3
» Views: 895

 
  Asus Tinkerboard
Posted by: Brian Beuken - 02-26-2018, 02:06 AM - Forum: Other SBC's - Replies (2)

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.

Print this item

  Banana Pi zero
Posted by: Brian Beuken - 02-26-2018, 01:28 AM - Forum: Other SBC's - No Replies

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.


[Image: zero1.jpg]


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)

Print this item

  Raspberry Screen shots
Posted by: Brian Beuken - 02-25-2018, 10:21 PM - Forum: Assets, Tools, Libraries and other useful things - No Replies

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.

Print this item

  C++ Coding Magpi #67
Posted by: Brian Beuken - 02-24-2018, 01:17 PM - Forum: General Chat - No Replies

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.

Print this item

  Preview error number 1 (gulp)
Posted by: Brian Beuken - 02-24-2018, 12:29 PM - Forum: Fundamentals Errata/Questions - No Replies

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)

Print this item

  Loading OBJ's
Posted by: Brian Beuken - 02-22-2018, 01:46 PM - Forum: Scratchpad Games - No Replies

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.

Print this item

  Optimizations
Posted by: Brian Beuken - 02-20-2018, 10:59 AM - Forum: Scratchpad Games - Replies (3)

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.

Print this item

  First time here, hello from Thijs.
Posted by: McKon - 02-17-2018, 08:33 PM - Forum: General Chat - Replies (7)

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.

Print this item

  FriendlyArm Nano Pi M1
Posted by: Brian Beuken - 02-04-2018, 04:16 PM - Forum: Other SBC's - Replies (1)

One of my favourite of the clones, mainly becuase it comes with all drivers and fully working pretty much out of the box, it does not take a lot to get this very cheap quad core up and running.

Of course being cheap it does not have much in the way of performance, its ancient Mali400MP2 mean it has much less power than the Raspberry, and it only has an H3 running at 1.2ghz  its also a little prone to overheating but not too much.

Its a game little beast, comes with Debian and Ubuntu, I tend to use Debian, and GLMark2-es reports a modest speed of 72, so it is accelerated, its just not fast.

Setting up is pretty much the standard case of installing all the additional libs, locating where the standard libs are, they are not the same as Raspberry, check the generic build demo to see what it does.

And then simply compile and run as usual, it runs about 80% the speed of a Raspberry which is a good excuse to practice some GPU optimization concepts we never covered in the book.

Sadly FriendlyArm seem to have discontinued this very cheap fun board and replaced it with a more expensive M1Plus version with more RAM, eMMC store, Wifi and BT, but at 3 times the price....not sure I can justify the extra cost for the same cpu and gpu.

Print this item

  Khadas Vim2
Posted by: Brian Beuken - 02-04-2018, 01:06 AM - Forum: Other SBC's - No Replies

Not sure actually if I bought the basic or the pro, its reporting 2G of RAM for a basic, but has 32GB eMMC ram for a Pro, on board...
hmmm either way, here's a small report on using it. This is reposted from my Tiny Monsters that play games blog


This is an odd beast for sure, I had trouble with it simply because it uses a USB C cable for power, and even though it came with one my usb output from the monitor never seemed to give enough power and it would frequently die at the end of a boot.
Well finally I got a converter for micro to USB C, and also managed to finally work out how to update the on board memory to have a linux (ubuntu) system instead of the default, but actually rather nice Android

This is an 8 core beast (big/small) which should put it on a par with the mighty Odroid XU4, it even has a better GPU, a Mali T820, but only MP3 , not quite up to the XU4's MP6 but even so its a next gen chip so it might manage it. It's an ES3.2 chip, which even if it can't quite provide the parallel grunt sending ES2.0 shaders to work, its ES3.2 shaders should make them cry.
After a bit of head scratching which turned out to be nothing more than very bad documents that didn't immediately make sense I was able to get it to reflash, and then update.

Time for the graphics fun to begin but of course there's no drivers on board...oh well...

Installed GLMark2-ES2 ok, after I'd allowed the onboard installer to do an update and reset. It does not identify the MaliT820 though so its basically emulating and slowly as you might expect, frame rates so far are nothing to write home about and of course it errors a lot at the death, eventually exiting with no score.

I'll see if I can get the usual mesa libs on board and try to get a test build sorted...should only take an hour

And bugger me, that was actually quite easy, once I'd set up the standard libs etc, and also installed and activated SSH server with

sudo apt-get install openssh-server
sudo service ssh start

So that Visual GDB could make the connections, I had no problems getting the generic multi config Mazehunt to build at run at all aside, from the known keyboard problems, the chmod fix however got me control and off it went.

Its running very slow of course due to lack of hardware access to the GPU but its performing as well as any of the other units without graphics. So I'm genuinely impressed. That was the easiest I've had so far, and the 1st time I've been able to do a -j8 options without the target dying. Most impressive. It does get bloody hot though, and the fact its already encased in a perspect case means I can't add a heat sink or fan to it..but it does not seem to be too worried and is running all 8 course at a nice old rate.

Will it ever get GPU access? I dunno...we'll see. Apparently Android has drivers, so maybe I'll use this as the Android port example.

Its a fast beast too, sysbench has it doing 10000 primes in 1.6212s, thats lighting fast..Odroid XU4 takes over 16 seconds thats a factor of 10 times and yet the Odroid is clocked a little higher.
If the GPU driver is ever released this will be a serious beast to use for dev...and OpenGLES3.2 on board will make it unstoppable...for now though its just a very fast CPU system.

Print this item