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



Search Forums

(Advanced Search)

Forum Statistics
» Members: 34
» Latest member: EdwardSek
» Forum threads: 130
» Forum posts: 372

Full Statistics

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

Latest Threads
Game Development Process
Forum: General Chat
Last Post: Brian Beuken
12-03-2018, 06:27 PM
» Replies: 1
» Views: 194
David Jones creator of Fi...
Forum: General Chat
Last Post: Brian Beuken
11-30-2018, 11:09 PM
» Replies: 3
» Views: 146
the importance of culling
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
11-28-2018, 11:31 AM
» Replies: 0
» Views: 95
Making maps is easier wit...
Forum: Assets, Tools, Libraries and other useful things
Last Post: jomoengineer
11-27-2018, 04:07 PM
» Replies: 1
» Views: 86
New Odroid on the way the...
Forum: Other SBC's
Last Post: Brian Beuken
11-21-2018, 10:09 AM
» Replies: 2
» Views: 334
[Chapter 05] Objects miss...
Forum: Fundamentals Errata/Questions
Last Post: Brian Beuken
11-20-2018, 09:36 PM
» Replies: 3
» Views: 319
Another new Raspberry?
Forum: Raspberry Pi questions
Last Post: Brian Beuken
11-19-2018, 08:52 PM
» Replies: 2
» Views: 151
missing Rand function/mac...
Forum: Fundamentals Errata/Questions
Last Post: Brian Beuken
11-19-2018, 08:27 PM
» Replies: 0
» Views: 74
[Chapter 05] KamaKazi Bas...
Forum: Fundamentals Errata/Questions
Last Post: Brian Beuken
11-19-2018, 08:15 PM
» Replies: 12
» Views: 443
Wireframe magazine — laun...
Forum: General Chat
Last Post: jomoengineer
11-16-2018, 11:52 PM
» Replies: 6
» Views: 626

  Using Eclipse (IDE) with Remote Projects
Posted by: DieSkaarj - 07-02-2018, 11:04 AM - Forum: Using non Windows systems - Replies (7)

Eclipse is a robust development environment available for linux which offers better scope for dealing with remote projects than other utilities that I've tried on the O/S. With it you can install a GDB add-on and manage your files across a network, perfect for remote compiling. I will offer the links for all the items you will need to code and cross-compile for the Raspberry Pi 3 B(+.) Here goes:

Installing Eclipse should be the first step, you can get it at the official site, as Brians' book is dealing with C/C++ we should install the IDE for working in those languages (Eclpise C/C++ IDE) or you can download it using your favourite package manager. The official website for Eclipse finds its home at: https://www.eclipse.org/

Now because the Raspberry Pi has proprietary hardware we will need to have drivers ready for our host computer to compile against. You can find these here [https://github.com/raspberrypi/firmware] and because the Rpi has a different architecture to your desktop or laptop we need more tools for remote compiling which can be found here [https://github.com/raspberrypi/tools].

With Eclipse installed we need to extract the files we got from github to somewhere. For ease of use I suggest just extracting them to your workspace folder.

Let's start Eclipse and get it ready to speak to the Rpi.

Open a .cpp file, start a new project, import an existing one, whichever way you go you'll need to direct Eclipse to files from both the firmware and tools-master folders. To set this up we need to open up the properties panel in the projects menu at the top bar. Once in there open the C/C++ Build menu and go to settings. And from there, in the newly visible settings panel, you should be seeing Cross Settings.

In the Cross Settings you need to set the prefix to 'arm-linux-gnueabihf-' and set the path to '~/workspace/tools-master/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin' or wherever you have put these files.

It's from the properties panel that we include the libraries and names of the modules we will be using to compile with. First up we include the directories in the Cross G++ Compiler->Includes section. You can find most of these in the section of the book that details setting up Visual Studio, they have paths like '/opt/vc/include/.' In fact this is so similar that it's practically the same thing. Further to setting up the libraries we have to include the names and this is done in the Cross G++ Linker section->Libraries and these look like 'bcm_host' and 'EGL_static.' You can also set the path for the compiler to find them.

For a more in depth, and easier to follow example, you can check here: https://www.96boards.org/blog/eclipse-re...debugging/

However it must be noted that the tools-master and firmware are both required to make the tool chain, again you can find these here: https://github.com/raspberrypi/tools and here: https://github.com/raspberrypi/firmware respectively.

Any questions? Smile

Print this item

  Odroid C2
Posted by: Brian Beuken - 06-22-2018, 07:45 PM - Forum: Other SBC's - Replies (1)

Like the Odroid XU4 set up is identical but performance isn't quite as impressive as you might expect from a Mali 450 which has 3 vertex and 2 pixel units. Not sure exactly what that means really in terms of how it relates to cores on other systems but bottom line is its not that fast

It also seems to have a small issue with inverted UV coords, which needs to be looked at

and finally it needs the chmod hack to get keys working

 sudo chmod  a+r /dev/input/*

But... if I can fix the inverted UV (or whatever it is) its a nicely working system on a par with the Raspberry in terms of its performance.

EDIT... though after testing the frame rates, actually its much slower, so it maybe that the OGLES is not fully functioning, or, possibly that the lack of optimization in the renders is more serious on this GPU.
The CPU certainly seems to outperform the Rpi, but the GPU isn't currently doing it for me.

Print this item

Posted by: Brian Beuken - 06-22-2018, 07:05 PM - Forum: Other SBC's - Replies (4)

Ok this is of course the beast in the Odroid Range, well loved for its emulation ability and octocore performance.

And of course as a target machine it is an utter beast to use, hardware acceleration on the OpenGLES, and able to handle OpenGLES3.1
It has an Mali T628 MP6 on board which is really a major boost, and if you want to get very fancy with it it can do OpenCL for some very intense muli system coding, not that its very practical on a games target.

I love this machine though it does have one niggle, the noisy fan, which does come on and off a lot when you are running it hard and can be an irritant. They do have a silent version basically a big lump of metal heat sink. Not sure of it suffers from overheating with it or not. I can't bring myself to buy 2 of them, as they are a bit pricey. Close to my limit when you factor in the shipping.

So far I've only used mine in anger as an OpenGLES2.0 system for my test code, though I have run a few ES3.0 demos to see it working in its glory :Big Grin
If you plan to do any OpenGLES3.0 this is the one. I am not 100% sure though that the OpenGLES3.1 claim is true as I was unable to get anything to work on 3.1 demos, however I didn't spend a lot of time so maybe I was just not setting it up right

Set up of the XU4 for ES2.0 really isn't too hard. I use their supplied Ubuntu MATE OS which I think came ready to go with no need to install anything else, but its over a year since I got mine and memory might have failed me. If you can't find the OpenGLES2.0 folders then simple apt-get the mesa libs.

Set up in Visual GDB is typical for most non Raspberry systems you need these include libs, assuming you have glm and bullet installed

/usr/include /usr/include/bullet /usr/include/bullet/BulletCollision/CollisionShapes . glm Headers /usr/include/GLES2 /usr/include/arm-linux-gnueabihf /usr/include/arm-linux-gnueabihf/c++/5

and then just this Binary Lib Dir

Library names are...
GLESv2 EGL pthread BulletCollision BulletSoftBody BulletDynamics LinearMath X11

Finally you will need to include some flags for g++
-ggdb -ffunction-sections -std=c++11 -O0 -DGL_GLEXT_PROTOTYPES
the 1st set are normal but the Odroids UbuntuMate version of gcc needs that -DGL_GLEXT_PROTOTYPES or it won't compile

Make sure you don't include BCMHost.h  in any non Raspberry Build

There after there are only 2 issues.. How to get the screen size to set up full screen, and how to set up an EGL window, this time displayed by X11

So make sure you don't define a preprocessor define for RASPBERRY
and you can use this code for both systems.

Set up the EGL and in the case of Raspberry DispamX
Set up OpenGL states needed

void Graphics::init_ogl(Target_State *state, int width, int height, int FBResX, int FBResY)
    int32_t success = 0;
    EGLBoolean result;
    EGLint num_config;


//RPI setup is a little different to normal EGL
    VC_RECT_T dest_rect;
    VC_RECT_T src_rect;
    EGLConfig config;

// get an EGL display connection
    state->display = eglGetDisplay(EGL_DEFAULT_DISPLAY);

// initialize the EGL display connection
    result = eglInitialize(state->display, NULL, NULL);

// get an appropriate EGL frame buffer configuration
    result = eglChooseConfig(state->display, attribute_list, &config, 1, &num_config);
    assert(EGL_FALSE != result);

// get an appropriate EGL frame buffer configuration
    result = eglBindAPI(EGL_OPENGL_ES_API);
    assert(EGL_FALSE != result);

// create an EGL rendering context
    state->context = eglCreateContext(state->display, config, EGL_NO_CONTEXT, context_attributes);
    assert(state->context != EGL_NO_CONTEXT);

// create an EGL window surface

    state->width = FBResX;
    state->height = FBResY;

    dest_rect.x = 0; // (1920/2)-FBResX/2; // if using a non display size you can center it here
    dest_rect.y = 0; // (1080/2)+(FBResY/2);
    dest_rect.width = width; // it needs to know our window size
    dest_rect.height = height; //state->height;

    src_rect.x = 0;
    src_rect.y = 0;
    src_rect.width = (FBResX) << 16;
    src_rect.height = (FBResY) << 16;

    DispmanDisplayH = vc_dispmanx_display_open(0);
    DispmanUpdateH = vc_dispmanx_update_start(0);

    DispmanElementH =     vc_dispmanx_element_add(
        0 /*alpha value*/,
        (DISPMANX_TRANSFORM_T) 0/*transform*/);

    state->nativewindow.element = DispmanElementH;
    state->nativewindow.width = FBResX; //state->width;
    state->nativewindow.height = FBResY; //state->height;

// normal EGL updates are different
    state->surface = eglCreateWindowSurface(state->display, config, &(state->nativewindow), NULL);
    assert(state->surface != EGL_NO_SURFACE);

       // connect the context to the surface
    result = eglMakeCurrent(state->display, state->surface, state->surface, state->context);
    assert(EGL_FALSE != result);

// Some OpenGLES2.0 states that we might need

    glViewport(0, 0, state->width, state->height);
    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);

// stops the targets desktop showing through if we have alpha (but at a frame cost, you can remove if you are sure there are no transparencies)
//    glEnable(GL_BLEND);

    eglSwapInterval(state->display,1); // 1 to lock speed to 60fps (assuming we are able to maintain it), 0 for immediate swap (may cause tearing) which will indicate actual frame rate
    printf("This GPU supplied by  :%s\n", glGetString(GL_VENDOR));
    printf("This GPU supports     :%s\n", glGetString(GL_VERSION));
    printf("This GPU Renders with :%s\n", glGetString(GL_RENDERER));
    printf("This GPU supports     :%s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));
    printf("This GPU supports these extensions    :%s\n", glGetString(GL_EXTENSIONS));


#include  <X11/Xlib.h>
#include  <X11/Xatom.h>
#include  <X11/Xutil.h>

#define EGL_FALSE            0
#define EGL_TRUE            1

// CreateEGLContext()
//    Creates an EGL rendering context and all associated elements

static Display* x_display = NULL;

void Graphics::init_ogl(Target_State *state, int width, int height, int FBResX, int FBResY)

#define ES_WINDOW_RGB           0
    state->width = width;
    state->height = height;
    EGLint numConfigs;
    EGLint majorVersion;
    EGLint minorVersion;
    EGLDisplay display;
    EGLContext context;
    EGLSurface surface;
    EGLConfig config;
    EGLint contextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE, EGL_NONE };

//    EGLint result = eglChooseConfig(state->display, attribute_list, &config, 1, &numConfigs);
      /* create a native window */
    Window root;
    XSetWindowAttributes swa;
    XSetWindowAttributes  xattr;
    Atom wm_state;
    XWMHints hints;
    XEvent xev;
    EGLConfig ecfg;
    EGLint num_config;
    Window win;
    Screen *screen;
         * X11 native display initialization

    x_display = XOpenDisplay(NULL);
    if (x_display == NULL)
        return ; // we need to trap this;
    root = DefaultRootWindow(x_display);
    screen = ScreenOfDisplay(x_display, 0);
    width = screen->width;
    height = screen->height; // resplution of screen
    state->width = width;
    state->height = height;

    swa.event_mask  =  ExposureMask | PointerMotionMask | KeyPressMask | KeyReleaseMask;
    swa.background_pixmap = None;
    swa.background_pixel  = 0;
    swa.border_pixel      = 0;
    swa.override_redirect = true;
    win = XCreateWindow(
    XSelectInput(x_display, win, KeyPressMask | KeyReleaseMask);
    xattr.override_redirect = TRUE;
    XChangeWindowAttributes(x_display, win, CWOverrideRedirect, &xattr);
    hints.input = TRUE;
    hints.flags = InputHint;
    XSetWMHints(x_display, win, &hints);
    char* title = (char*)"x11 window Maze3dHunt";
        // make the window visible on the screen
    XMapWindow(x_display, win);
    XStoreName(x_display, win, title);

        // get identifiers for the provided atom name strings
    wm_state = XInternAtom(x_display, "_NET_WM_STATE", FALSE);
    memset(&xev, 0, sizeof(xev));
    xev.type                 = ClientMessage;
    xev.xclient.window       = win;
    xev.xclient.message_type = wm_state;
    xev.xclient.format       = 32;
    xev.xclient.data.l[0]    = 1;
    xev.xclient.data.l[1]    = FALSE;

    state->nativewindow = (EGLNativeWindowType) win;
    // Get Display    
    display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    if (display == EGL_NO_DISPLAY)
        return; // EGL_FALSE;

    // Initialize EGL
    if (!eglInitialize(display, &minorVersion,&majorVersion))
        EGLint err = eglGetError();
        return;// EGL_FALSE;

    // Get configs
    if (!eglGetConfigs(display, NULL, 0, &numConfigs))
        return;// EGL_FALSE;

    // Choose config
    if (!eglChooseConfig(display, attribute_list, &config, 1, &numConfigs))
        return;// EGL_FALSE;

    // Create a surface
    surface = eglCreateWindowSurface(display, config, state->nativewindow, NULL);
    if (surface == EGL_NO_SURFACE)
        return;// EGL_FALSE;

    // Create a GL context
    context = eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs);
    if (context == EGL_NO_CONTEXT)
        return;// EGL_FALSE;

    // Make the context current
    if (!eglMakeCurrent(display, surface, surface, context))
        return;// EGL_FALSE;

    state->display = display;
    state->surface = surface;
    state->context = context;
    //return;// EGL_TRUE;
    printf("This GPU supplied by  :%s\n", glGetString(GL_VENDOR));
    printf("This GPU supports     :%s\n", glGetString(GL_VERSION));
    printf("This GPU Renders with :%s\n", glGetString(GL_RENDERER));
    printf("This GPU supports     :%s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));
    printf("This GPU supports these extensions    :%s\n", glGetString(GL_EXTENSIONS));


#endif // RASPBERRY

This is pretty much the same for every basic SBC system with an X11 display (in other words not Raspberry),  as long as the graphics systems are on the target.
The XU4 needs you to use the root though so when you create the ssh connection use root, or it won't let you send files to the target,

Print this item

Posted by: Brian Beuken - 06-20-2018, 08:57 PM - Forum: Other SBC's - No Replies

Oh bugger, it seems NTC who made the little $9 C.H.I.P. have gone bust and there's no apparent sign of a relaunch.

Shame, their little board was actually quite nice to use, and cute to show to people, and I recently did an update on it and noticed it was downloading Mali GPU drivers, which I assumed were related to the Allwinner binary blob release. 

Though only a single core CPU and not very fast at that, it would have got a bit of a boost with its Mali 400 working. Mind you not that much of a boost it was only an M1, but any graphic acceleration is to be applauded.

It was really pretty much the worst SBC on the market, but it had a nice clean OS and was simple to get started, though such a low power system was never going to be any good at the wide range of tasks they wanted it to do, there was even a "games console" kit version...hmmm
I really was hoping they'd get another board to market with the same nice approach to the OS and community but with a better more powerful SBC.

I actually rather liked it when I tried it out, and I might get it up and running again soon to see if the updates do indeed provide an improvement. But its dead Jim, so perhaps I'll just try it out, take note of the set up (should be standard debian) and then move on, even the NTC board isn't showing a lot of discussion in its demise so it wasn't that well supported (oh thats probably why they went bust)

Print this item

  Any clever Linux people here?
Posted by: Brian Beuken - 06-20-2018, 08:28 PM - Forum: Assets, Tools, Libraries and other useful things - Replies (3)

Last year Allwinner announced binary blobs for the GPU's were released and could be added to your Allwinner equiped SBC's

I've been hoping to see more Allwiner chips with the results of that release but so far nothing.

But I understand it is possible to add them yourself....But as I'm not a linux developer  I'm a bit confused by the process

The details are here, 


I can certainly understand the script, but how you find/edit/use a DTS file is beyond me.... can anyone help?

Print this item

  Open AL?
Posted by: Brian Beuken - 06-19-2018, 01:00 PM - Forum: Assets, Tools, Libraries and other useful things - No Replies

Oh this is a good one.

"Why are you using OpenAL in the book when its been replaced by more modern sound systems like Fmod? I don't want to have to learn such old tech!"

Ah that is such a good question, and the answer simply is that FMOD isn't available for SBC's, and isn't likely to be considering how large it is and how complex it has become.
I use FMOD in my PS4 and PC development and love it, its really wonderful, if I could get it to work on an ARM based SBC I most certainly would. But until they make a version for me and other SBC game coders (which means both of us), we have to look for the next best alternative.,

The same argument can also be used for MD2-MD5 for models, why do I use these outdated systems. I'd much rather use FBX and other systems but they are not available on any of the current ARM systems. Though I heard there was going to be an IOS version of FBX, I've not see it in action yet and no idea if I can port it to a Pi.

So I used what I thought would work best with the hardware we have to hand. On a low power GPU trying to do too much is a killer for frame rate so MD2 and MD3 don't push it very hard, MD5 does though it can be done and the result is nice easy to view and use models on the Pi and its clones.

Likewise, OpenAL is still very usable, provides 3D surround sound and mixing, and its pretty easy to use with almost any format of sound system if you can convert the data to standard wav format (OpenAL knows nothing of compression systems, it uses only raw files).

It works, its got a small footprint, its not killing the CPU or sound system and theres plenty of help and advice around.

I noted in the book, a lot of the libs we use are 10+ years old and certainly can be considered outdated on PC. But we are not running on a modern PC, and the levels of power we have pretty much match the levels of power of systems form 10 years ago. So use what works.

If you don't like it, I really would love to see you produce something better.'

But rest assured I am always looking for better more uptodate and feature rich systems, so far though...not much on show.

Print this item

  Always power down
Posted by: Brian Beuken - 06-12-2018, 11:39 AM - Forum: Assets, Tools, Libraries and other useful things - No Replies

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.

Print this item

  I'd like to introduce myself :)
Posted by: DieSkaarj - 06-07-2018, 05:09 PM - Forum: General Chat - Replies (4)

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


Print this item

  Up core
Posted by: Brian Beuken - 06-07-2018, 11:54 AM - Forum: Other SBC's - No Replies

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.
[Image: board-layout-white1.png?resize=1100%2C456]

Print this item

  UP2 (squared)
Posted by: Brian Beuken - 06-07-2018, 11:47 AM - Forum: Other SBC's - No Replies

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 timer) $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 impost 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.

Print this item