I just listened to an episode of CppCast that had Jerri Ellensworth of Tilt Five (formerly she started Cast AR) where she spoke of offering their SDK along with their new Tabletop AR system.  The SDK will support Unreal Engine, Unity as well as GCC for OpenGL type of dev.   Jerri had formerly worked at Valve where she helped to develop their game streaming system and then move to Cast AR that got killed by the VCs. 

The Tilt Five Tabletop AR system is an awesome idea and just shows the opportunities in both AR for devs.


Tilt Five Web Site
https://www.tiltfive.com/

Tilt Five Kickstarter/Pre Order site:
https://tilt-five.backerkit.com/hosted_preorders


Listen to the Jerri Ellenworth interview on CppCast:
https://cppcast.com/jeri-ellsworth-tiltfive/

So, ARM has been working to make Vulkan more accessible to mobile developers and shown their best practices and sample code at GDC 2019 and now they have donate all of this to the Khronos group.   ARM does offer their Arm Mobile Studio free for developers but it is mostly focused on Android.  Here, ARM is focused on Vulkan which is quite interesting.  There was another talk at the last GDC regarding the differences between OpenGL ES and Vulkan and it was stated that Vulkan is best for the newer ARM processors and not so good for the legacy processors which OpenGL ES would perform better. I posted this on another thread.

It seams there is a push for more mobile device development so ARM opening their Vulkan best practices and code with the Khronos group is promising.

https://community.arm.com/developer/tools-software/graphics/b/blog/posts/arm-donates-vulkan-best-practice-for-mobile-developers-to-khronos-1610165794?utm_source=na&utm_medium=email&utm_campaign=2019_client-gaming_mk04-4_na-&utm_term=graphics-newsletter&utm_content=blog&mkt_tok=eyJpIjoiWVRnMU1UUXlNVGRtTm1aaSIsInQiOiJwUkN0MG9hRFdiZjZUMEphOHh5dmJuVkMraXloUFpCTEVMWDRyY1JVTDNxUmFhMmNMOGFsZ1pTMmhYcVZKRVBVNXV0bjNuZlNFbjIzb1FKRVhVWVdNZitQSnduRFU3Zkx5K3k2c1wvckhucDZINDdFaURjdVRMSmZZSGFTVUlvK0cifQ%3D%3D

ARM Vulkan Best Practices
https://community.arm.com/developer/tool...developers


ARM Mobile Studio
https://www.arm.com/products/development...ile-studio

The Nintendo Switch Lite is out for purchase now in the US for a cool $199.99.
https://www.nintendo.com/switch/lite/

This is the non connected version without the Joy-cons.

I found this talk by Jack Porter of Epic Games and Kostiantyn Drabeniuk of Samsung Electronics from GDC 2019 quite interesting. Jack specifically talks about some of the issues they had trying to use Vulkan especially with the older mobile devices where OpenGL ES is better supported.

A long time ago in a galaxy far away, about 10 years ago, some of my University collegues and I put together a basic introduction to C++ for games, and it was hosted on a few game dev sites.
Over time though they started to show their age and slipped down the search rankings. Despite saying every year we would update them, and make sure students were pointed to them, we just never got round to it.

But they have finally been updated, and will soon be hosted on my collegue Jeremiah van Oostens website at 3Dgep.com, where hopefully we can maintain and expand them,  just as soon as my OCD co-writers can stop tinkering with it.

If you want to learn C++ on your PC, and make some basic but functional content that can build into games (not unlike the methods I use for the 2D content in my book) feel free to check it out.

If you are a slightly more advanced coder, Jeremiah site is an amazing resource for you to enhance your 3D graphic knowledge and get into some very (I do mean very) complex content.. But theres some beginner/intermediate stuff there too.

I was hoping to get my hands on a Vim3 with the impressive A311D  but though they were kind to respond to my mail, they didn't send me a free example and as its over my $100 limit I couldn't buy it. It currently tips the scale at $99 but when you factor in a heatsink it tips it over... 

But they have announced a half price Vim3L version with the S905 chip which they had originally intended to use, its missing a few other bits, but I probably wouldn't have used them anyway.
So I've preordered and will wait and see. 


I've always liked the Vim2 I have, its quite a processing beast and actually emulates ES2 better than any other system I have, but like a lot of higher end boards it lacks access to the GPU, I suspect the same here but we will see when it arrives. It'll be a few months.

oops edit... no, the original Vim3 chip was a S922 which is/was a hexacore chip but they switched to the A311D and that also pushed the price up a bit. The S905 is the same quad core you find in the Odroid C2, a powerful chip for sure, better than the Pi3B but not as impressive as the S922... So this should be compared with the C2 and Pi3B in terms of performance, I suspect it will match the C2 but fall behind the 3B, we'll see when it arrives. But one thing, the C2 has a strong community behind it and I "think" it has GPU drivers, I need to dig mine out and update it to see. So it may actually be a more useful dev target than the full Vim3 is... time, as always will tell.

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

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.

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

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.