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

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 41
» Latest member: Bernardsoype
» Forum threads: 103
» Forum posts: 235

Full Statistics

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

Latest Threads
Not much chat?
Forum: Scratchpad Games
Last Post: Brian Beuken
09-13-2018, 09:50 AM
» Replies: 2
» Views: 25
Price drop
Forum: Scratchpad Games
Last Post: Brian Beuken
09-08-2018, 07:36 AM
» Replies: 2
» Views: 132
Keyboard not responding?
Forum: General Chat
Last Post: Brian Beuken
08-22-2018, 07:40 PM
» Replies: 0
» Views: 185
So....what do I do?
Forum: Getting started
Last Post: Brian Beuken
08-16-2018, 04:41 PM
» Replies: 5
» Views: 1,085
The joys of relative and ...
Forum: General Chat
Last Post: Brian Beuken
08-15-2018, 09:54 PM
» Replies: 0
» Views: 110
Building with a toolchain
Forum: General Chat
Last Post: Brian Beuken
08-05-2018, 05:24 PM
» Replies: 0
» Views: 135
Success, 1st steps
Forum: Getting Android working
Last Post: Brian Beuken
08-05-2018, 03:12 PM
» Replies: 0
» Views: 134
Where to start?
Forum: Getting Android working
Last Post: Brian Beuken
08-04-2018, 01:53 PM
» Replies: 2
» Views: 664
Great OpenGL tuts
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
08-03-2018, 03:23 PM
» Replies: 0
» Views: 276
Moving over to Raspberry ...
Forum: Raspberry Pi questions
Last Post: Brian Beuken
08-02-2018, 08:41 PM
» Replies: 0
» Views: 148

 
  Nano Pi T4
Posted by: Brian Beuken - 07-19-2018, 02:33 PM - Forum: Other SBC's - Replies (1)

I'm in love

Its been a long time since I could get a board, burn linux on it and immediately use it.
The T4 is such a board, it came with android installed, but I wanted Lubuntu, and hoped I could dual boot it from an SD, but that didn't work out, so I reflashed the eMMC with Lubuntu, very very simple

And wow, it works, its all there, GLMark2-es2 works fine, though it is frame locked so never went above 50fps, not to worry running it offscreen (avoiding the frame lock) throws up a mark of 312, that's 3 times faster than a raspberry Big Grin  And.....and.....OpenGLES3.2 yipeee


There's a small downside though, its froze on a 2nd turn of glmark2, it clearly got very hot even with the heat sink on board.. So it is a little fussy. Usually updates fix that, but I can' t get apt-get update to work
It says the dirs are locked....hmmm dunno how to fix that, so have posted on the forums.


I'm loving this board already... going to do a quick compare with the XU4 and Tinkerboard (after an update) to see how its glmarks compare. I'll set up a test project shortly to see how the standard demo plays. Its got a Mali 860Mp4 in there so its up there with the latest (in terms of SBC's, 5 years behind phones though) and has a nice bit of grunt, if we can control the overheat, it could be a contender.

Tinkerboard returns GLMark2-es2 score of 392...hmm that's surprising, and impressive, but the Tinkerboard only goes to OpenGLES3.1 

I'll add the XU4 here when I get round to hooking it up again.

Print this item

  A little something from my students
Posted by: Brian Beuken - 07-08-2018, 11:34 PM - Forum: General Chat - No Replies

I give my 1st year  students Raspberry Pi's to work on for 8 weeks each year, mainly as an introduction to OpenGL, shaders and code design to use the GPU well.
Its often fun and some really nice games come out of it. I don't set them any very hard goals, just revamp a retro game, do a quake demo, or for those who want to dabble with networking, create a 2 player networked version of Battleships and visualise it anyway they want.

This year, some of my students decided to polish up their version of Battleships and do a cross platform version.
They even did a small trailer of it, though I can't say its all that good, lucky they are not media students. Big Grin

But I'm still very pleased they made the effort to polish and cross develop it. So thanks to 
Joey Jacobs
Erico Wiggers
Arthur Kuylaars

Team 6 - Block C - Year 1






I'll try to set up a download for you have a go at it, though it needs 2 players with their own pi's to work over a network! (should also work with a PC as the host?)
Edit...now uploaded on the main site's download pages

Print this item

  Code for issue 71
Posted by: SteveSTEM - 07-05-2018, 09:26 PM - Forum: General Chat - Replies (6)

It doesn't look like the code for the latest issue has been posted to GitHub. I don't know who looks after the repi,or if there's an alternative location...

Print this item

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

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

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

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
/usr/lib/arm-linux-gnueabihf

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.

Code:
/*
Set up the EGL and in the case of Raspberry DispamX
Set up OpenGL states needed
*/
#ifdef RASPBERRY

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
    DISPMANX_ELEMENT_HANDLE_T DispmanElementH;
    DISPMANX_DISPLAY_HANDLE_T DispmanDisplayH;
    DISPMANX_UPDATE_HANDLE_T DispmanUpdateH;
    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(
        DispmanUpdateH,
        DispmanDisplayH,
        1/*layer*/,
        &dest_rect,
        0/*source*/,
        &src_rect,
        DISPMANX_PROTECTION_NONE,
        0 /*alpha value*/,
        0/*clamp*/,
        (DISPMANX_TRANSFORM_T) 0/*transform*/);

    state->nativewindow.element = DispmanElementH;
    state->nativewindow.width = FBResX; //state->width;
    state->nativewindow.height = FBResY; //state->height;
    vc_dispmanx_update_submit_sync(DispmanUpdateH);



// 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
    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_LEQUAL);

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

    
// 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);
//    glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ZERO, GL_ONE);
    

    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));
}

#else

#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;
    eglBindAPI(EGL_OPENGL_ES_API);
        /*
         * 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(
        x_display,
        root,
        0,
        0,
        width,
        height,
        0,
        CopyFromParent,
        InputOutput,
        CopyFromParent,
        CWEventMask,
        &swa);
    
    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;
    XSendEvent(
      x_display,
        DefaultRootWindow(x_display),
        FALSE,
        SubstructureNotifyMask,
        &xev);
    

    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

  C.H.I.P.
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, 

https://www.cnx-software.com/2017/09/26/...s-support/

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