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

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 51
» Latest member: viktorbaukh
» Forum threads: 188
» Forum posts: 689

Full Statistics

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

Latest Threads
Pine Pinebook
Forum: Other SBC's
Last Post: Brian Beuken
08-18-2019, 04:07 AM
» Replies: 17
» Views: 1,586
Fundamentals of C/C++ Gam...
Forum: General Chat
Last Post: Brian Beuken
08-14-2019, 09:26 AM
» Replies: 1
» Views: 102
New Raspberry Pi 4
Forum: Raspberry Pi questions
Last Post: Brian Beuken
08-14-2019, 09:24 AM
» Replies: 7
» Views: 680
Opening this sub forum to...
Forum: Scratchpad Games
Last Post: Brian Beuken
08-06-2019, 12:30 PM
» Replies: 3
» Views: 2,427
hello
Forum: Scratchpad Games
Last Post: Brian Beuken
08-01-2019, 10:49 AM
» Replies: 5
» Views: 3,023
Which Pi am I?
Forum: Raspberry Pi questions
Last Post: Brian Beuken
07-13-2019, 12:41 PM
» Replies: 1
» Views: 248
Raspberry Pi 4 is differe...
Forum: Help my code won't work??
Last Post: Brian Beuken
07-03-2019, 11:10 AM
» Replies: 0
» Views: 239
Odroid N2
Forum: Other SBC's
Last Post: Brian Beuken
07-03-2019, 08:13 AM
» Replies: 3
» Views: 428
Disable OpenGL, for faile...
Forum: Help my code won't work??
Last Post: Brian Beuken
07-02-2019, 12:39 AM
» Replies: 2
» Views: 2,163
Raspbian Buster
Forum: Raspberry Pi questions
Last Post: Brian Beuken
07-02-2019, 12:36 AM
» Replies: 3
» Views: 464

 
  Fundamentals of C/C++ Game Programming in Class form
Posted by: jomoengineer - 08-14-2019, 04:18 AM - Forum: General Chat - Replies (1)

Hey Brian,

I was wondering if you have thought about offering the teachings from "Fundamentals of C/C++ Game Programming" in some sort of online class form or MOOC?    I think something like Udemy would be a good place for this and could broaden the audience for the book.   Maybe even combine the MagPi articles with the material from the book?

Any thoughts on this?

Cheers,

Jon

Print this item

  Which Pi am I?
Posted by: Brian Beuken - 07-13-2019, 12:41 PM - Forum: Raspberry Pi questions - Replies (1)

Now that we have the Pi4 on the market, we have to finally accept that some differences exist between the different versions of Raspberry, (and libs they use)

For the most part we can build projects on the Zero, 1, 2, 3, A or B/B+ with no real care about the hardware as long as we are running the same OS we build on. That updates every 2 years or so but even so it tends to be compatible, so a project built on a new Stretch or Buster OS will work fine on a Jesse or older system.

The only real issue is that some machines are much slower than others and have less memory. Those kind of things can be dealt with by just checking that your project runs on a minimum specification, and using good optimisation.

But the Pi 4 introduces a wrinkle in that nice level of family compatibility, becuase it has a totally different approach to graphics and graphic code written for the older Pi's won't work on them, nor will Pi 4 code work on the older systems

There's 2 ways to tackle this.
1 Use Multiple configurations... where you create a specific build for a specific target system, or group of systems.. ie one build for the 1,2,3 and 1 for the 4.
   Thats an easy option, and you can just build in pre-process values to set up the correct build.

2 Runtime detection of the target.
   Where you actually try to work out what Pi you are running on, and then branch your code to do one set up for the older systems and another for the later ones.

There's pros and cons to both methods but for the most part, the only real difference between the units is graphics, oh and memory, but graphics is the killer. So lets try and do a simple detect and based on the results of that detect set up graphics accordingly.

There's no system call that automatically tells you what machine you are working on, but there are files on the system that you can read
 /sys/firmware/devicetree/base/model
or
/proc/device-tree/model

These can be read in and parsed by your init systems to give you the info you need and set up the correct system. Once we know we're on a Pi2 we can use ES2.0 and BCM EGL, instead of X11 (trying to work out a DRM system though) and Mesa EGL for Pi4.

If you plan to incldue OpenGLES3.0+ features you can also set up conditional tests to do one draw system or another...probably routed through a simple render class that is instansiated depending on the type.

We can also get a good idea of how much memory our system has by reading
/proc/meminfo
Since there's bound to be a tendancy to assume you have 3 or 4GB of memory free, this will allow you to know roughly how much you can use, though be careful again as the Pi4 dynamically allocates GPU memory when needed so you can only use such info as a rough guide.

I'll use these info systems as a means to put together a general new graphics system that readers can replace the current systems with and upload the code as soon as I can.

Print this item

  Raspberry Pi 4 is different, book code won't work!
Posted by: Brian Beuken - 07-03-2019, 11:10 AM - Forum: Help my code won't work?? - No Replies

Well it had to happen, the new Raspi4 is a lovely machine with some impressive graphic potential, but it does not work the same way as all the other Raspberries so the book examples won't work, there has to be a new version of the graphics startup code.

The previous Raspberries used Broadcom IV graphic drivers with binaries and libs located in opt/vc/lib and opt/vc/include

The Pi4 still has these libraries and locations but they don't work on the 4, though you can use the Buster OS with any other Raspberry.


1st things 1st you need mesa libs which can be installed by opening a terminal and typing

sudo apt-get install libgles2-mesa-dev 

Now you need to change some of your project library needs and directory access. The increased number of libs needed to run on the older RPis has been reduced to just 3,  EGL, GLES2 AND X11 (other display systems are possible though but not right now)


And include libs are now usr/lib for the libraries and usr/include for the h files
Also, and this is very important, do not disable the OpenGL drivers as we had to do in older Raspberry's


If you are using one of the multi build configs on the site, basically Raspberry has reverted to the normal way to build a Linux project, so remove the RASPBERRY pre processor instruction and let it build like a normal Linux build and it should be fine.
Here's the init code to set up an X11 window, EGL and get ready to work with OpenGLES2.0

Code:
///
// 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 };

    
      /* 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)
        {
            
            printf("Sorry to say we can't create an Xwindow and this will fail");
            exit(0); //return ; // we need to trap this;
        }
    eglBindAPI(EGL_OPENGL_ES_API);
    root = DefaultRootWindow(x_display);
    screen = ScreenOfDisplay(x_display, 0);

    
    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)
    {
        printf("Sorry to say we have an EGLinit error and this will fail");
        EGLint err = eglGetError();
        return; // EGL_FALSE;
    }
    
        
    // Initialize EGL
    if (!eglInitialize(display, &majorVersion,&minorVersion))
    {
    
        printf("Sorry to say we have an EGLinit error and this will fail");
        EGLint err = eglGetError();
        return;// EGL_FALSE;
    }

    // Get configs
    if (!eglGetConfigs(display, NULL, 0, &numConfigs))
    {
        printf("Sorry to say we have EGL config errors and this will fail");
        EGLint err = eglGetError();
        return;// EGL_FALSE;
    }

    // Choose config
    if (!eglChooseConfig(display, attribute_list, &config, 1, &numConfigs))
    {
        printf("Sorry to say we have config choice issues, and this will fail");
        EGLint err = eglGetError();
        return;// EGL_FALSE;
    }


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

    // Create a GL context
    context = eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs);
    if (context == EGL_NO_CONTEXT)
    {
        EGLint err = eglGetError();
        return;// EGL_FALSE;
    }

    // Make the context current
    if (!eglMakeCurrent(display, surface, surface, context))
    {
        EGLint err = eglGetError();
        return;// EGL_FALSE;
    }

    state->display = display;
    state->surface = surface;
    state->context = context;
    
// just for fun lets see what we can do with this GPU        
    printf("This SBC supports version %i.%i of EGL\n", majorVersion, minorVersion);
    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));

    
    
    EGLBoolean GLtest = eglGetConfigAttrib(    display,
        config,
        EGL_MAX_SWAP_INTERVAL,
        &minorVersion);
    
    EGLBoolean test = eglSwapInterval(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
    // on xu4 this seems to have no effect

    // Some OpenGLES2.0 states that we might need

    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_LEQUAL);
    glDepthMask(TRUE);
    glDepthRangef(0.0f, 1.0f);
    glClearDepthf(1.0f);

//these are the options you can have for the depth, play with them?
//#define GL_NEVER                          0x0200
//#define GL_LESS                           0x0201
//#define GL_EQUAL                          0x0202
//#define GL_LEQUAL                         0x0203
//#define GL_GREATER                        0x0204
//#define GL_NOTEQUAL                       0x0205
//#define GL_GEQUAL                         0x0206
//
    glViewport(0, 0, state->width, state->height);
    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
    glCullFace(GL_BACK);
    if (glGetError() == GL_NO_ERROR)    return ;
    else
        printf("Oh bugger, Some part of the EGL/OGL graphic init failed\n");    
}




I will put new builds forPi4 up on the site as soon as I can, if you need help, just ping me on here or drop me a mail

Print this item

  Libre La Frite
Posted by: Brian Beuken - 06-27-2019, 11:44 AM - Forum: Other SBC's - Replies (2)

[Image: 84988b14aa58054c0a4cbf8c03466fa9_origina...d7e5d5f8a4]Been a lot of delays for this but its apparently  on the way so hoping it gets here soon.  Considering that Libre Tritium H5 is still in the drawer of shame awaiting GPU drivers I don't hold out a lot of hope this will be usable out of the box but we'll see when it gets here.

Print this item

  Odroid N2
Posted by: Brian Beuken - 06-27-2019, 11:39 AM - Forum: Other SBC's - Replies (3)

Going to be a busy month for me with lots of new systems coming in.  Latest is this beast from Odroid
https://secure.reichelt.nl/odroid-n2-6x-...stct=pos_0

Happy to see that Reichelt in Germany has stocks and getting them from Korea is a bit hit and miss... 

It should be here in a few days, so I'll try to do a review at the weekend along with a couple of other new arrivals I'm expecting.

Print this item

  No reply to mail? Here's an alternative mail address
Posted by: Brian Beuken - 06-27-2019, 08:06 AM - Forum: Scratchpad Games - No Replies

It seems the spam bots are not content with just posting on the forums they also have been sending a lot of messages to the mail box and clogged it up quite badly. Resulting in mail not getting to me.

I've cleaned it up now, and will check it a little more often to prevent it getting totally filled. But if you mail me and get a bounce or no reply, contact me on this email as well

brianbeuken5  which is at good old gmail and thats a dot com....

Print this item

  Raspbian Buster
Posted by: Brian Beuken - 06-26-2019, 11:02 PM - Forum: Raspberry Pi questions - Replies (3)

So there's a new version of Raspbian, which the Raspberry 4 needs to operate, but those of you who still have older Pi's will probably want to try it out, so here's the basics 

I set up Buster on a Pi 3B+
It's initial set up is a bit more fussy than previous versions but its all fine aside from insisting I must speak Dutch if I set my locale to Amsterdam...I wish it would understand that being in 1 part of the world does not mean you speak that language.. Fortunately there is an English only tick box.

It does seem a tiny bit clunky in use on the 3B+ maybe it expects a bit more power to run, but thats not the Raspberry way, so will see how it gets on after its finished updating and installing.

And that took a while but, yes it seems a bit smoother now.

SSH and VNC are disabled by default so you need to enable them if you are using headless systems or coding on a PC

STB and GLM need to be installed 1st and bullet physics

But...thats it... all libs are in the same places, and it builds and runs demo's fine. It still needs the _static libs of Stretch but no problems at all getting things up and running.

Interesting to note checking the libs folder there is currently no GLES3.0 folder... that maybe due to installing itself on a 3B+ I'll see if it installs the libs on a 4 when my monitor cables come.

So..all good..at least for my level of usage (ie not so much on the Pi itself). If there are issues I'm sure users will find them. But on a 3B+ at least Buster seems to work just fine.

Print this item

  New Raspberry Pi 4
Posted by: Brian Beuken - 06-24-2019, 08:29 AM - Forum: Raspberry Pi questions - Replies (7)

Wasn't expecting it, but am very happy to see it.
I've got one on order so have no idea yet on what changes if any are needed to the builds... I'll provide any updates as soon as I can.

https://www.raspberrypi.org/blog/raspber...GSTODvyYnI

Print this item

  We're going to need a bigger book
Posted by: Brian Beuken - 06-24-2019, 07:46 AM - Forum: Scratchpad Games - Replies (5)

Its not even Pi day...but look..the Pi 4 is out, and what a beast it is.


https://www.raspberrypi.org/blog/raspber...PaZCxXpa10


Im overjoyed about this, and also slightly amazed.. 2-3times the power and OpenGLES3.0 (maybe 3.1 or 3.2?) They have it listed as 3.0 and 3.x so curious to know which it is.

Also 1-4GB of LDDR4 memory, thats very refresshing, much more speed and more speace. The Raspberry now really has a place as a desktop system.

Can't say I'm overkeen on the dual screens, not sure why a Pi needs it, and the need therefore for mini adaptors but hey ho.. if people want it they get it,

I'm curious about the USB3.0, will the again share a bus? And a full Gigabit ethernet.. 

It really is a perfectly awesome little machine, and still at a base $35 for the 1GB, though I've gone for a 4GB model.

Well I guess its time look at adding those GLES3.0 chapters.

Print this item

  Another new board coming soon Vim3
Posted by: Brian Beuken - 06-22-2019, 01:06 PM - Forum: Other SBC's - Replies (2)

I rather like the Vim2 I have, though it does not have full drivers for it GPU, its one of the few Octacore systems that I find can comfortably handle some serious processing. I don't really like the case its in or the lack of heatsink though that does cause a few issues when seriously strained.

Khadas seem to market these mainly as Android/TV boxes and they do rather well, but a new one is on the horizon that will have some interest for us as game devs and possible AI dev.

https://www.khadas.com/vim?utm_campaign=d0e49486-86fa-419f-b885-a80af7b4aa43&utm_source=so

The Vim3 is using a new CPU to the market though, the hexa core A311D, which probably means it'll be 6months of more before we see any real good OS's, I suspect Armbian are on the job already. But once it beds in it should be quite a nice machine. It has a lot of very nice features that are more common on maker boards than Android/TV boxes so perhaps Kahdas are expanding their target market which is good for coders.
On paper this is a mega fast Arm 4x2.2GHz and 2x1.8Ghz, and should be able to blast out a lot of processing, the fact it also has a PWM fan header means you can put some seriously good cooling onto it to keep that performance at its limits.

It has a next Gen Mali G52 MP4 GPU, which isn't really going to trouble the Jetson or Rockchip systems, but it will outperform almost all the other systems, if/when it has hardware exposed. Amlogic havn't been to easy to get drivers for in the past except for Odroid. All the extras it has could make it very competative with the Rockchip machines.

Priced at $99 it falls under my $100 limit, so its going to join me at some point. There is a slighlty contrived launch discount being offered that can knock it down to $69. If you manage to share their promo material around, sadly I failed to even get a copy link on facebook...(not not just cos I'm stupid,I followed the instructions and the options expected didn't appear).

I'm hoping I can get hold of a sample board and put it through its paces, if not I'll leave it a few months till the OS is in place and try to pick one up.

I hope it does well.

Print this item