Since I've been doing a few recently, lets put up some scores and update as I go along/do updates

format is 
name  Offscreen/Onscreen (locked means locked to screen)
* = emulated, so not a true judgment of GPU

Nvida Jetson        396/1995 (yup it really reports slower off screen...odd)
UP^2                  1593/657 (jellyfish corrupts)
Up Core               1291/493 (jellyfish corrupts)
RockPro64           714/locked
Tinkerboard         470/locked ( recent updates have seen this drop to around 390-410...)
NanoPiNeo4         378 /locked
NanoPi T4            312/locked
Raspberry Pi4B     300/136
Libre Tritium H5    260/locked
RockPi4                249/locked (bit dissapointing this, but it does seem to be running with es3.2 drivers)
Odroid N2            212/locked (currently have to use GLmark2-es-fbdev)
OrangePi Zero+2  150/79
Nano PiM1                144/72  (some tests failed though)
Dragonboard 410c*   144/65
Banana Pi zero*     50/50
Raspberry Pi3B*       50/50 both locked, though Raspberry has drivers GLmark2-es2 does not recognise them correctly.
Vim2*                    44/44 
OrangePi One+       44/29 (should be a lot better but drivers are just not there)
Raspberry Pi3B+*    25/37 (it does have gles2.0 drivers but glmark2 and glmark2-es2 emulate, as it can't recognise broadcoms dispmanx so its actually quite a bit faster than this

Nano Pi 2 (fire)*          0 failed

Raspberry's (though not the 4) have a very nice trick where you can set the size of your EGL buffer to be half, or quarter the size of your resolution and the display will zoom it to the full size of the screen.
This is handy because rendering a full 1080p screen is just ever so slightly beyond the power levels of most of our standard GPU's. But half size is quite possible. 


But I've never been able to do that on standard X11 systems, which has meant running them in windows, or just letting them fail to keep up the frame rate for their generally poor GPU's
I always set the Raspberrys to render at half scale and draw via zoom to full. Sadly I can't do that with the RPi4 since I'm using X11 to render..and at full res even that does struggle to keep the same frame rate as the 3B/B+. I could just render to a same size window but games really need a full screen display.

But today as I was tinkering, (literally, on a tinkerboard) I had a brainwave...Instead of trying to replicate the antics of a Raspberry, which does not seem to be viable, just change the res of the screen, when the game starts up... Now I didn't actually know how to do that, in code, but a bit of googling found that there is a nice library libxrandr-dev that gives you the ability to interrogate and SET the res..
I found this on stackoverflow which explains it really well
https://stackoverflow.com/questions/1138...-and-linux

The only issue  here is that it does not make it clear you need to have libxrandr-dev in place before you try to build, using
sudo apt-get install libxrandr-dev and of course reference them in your build config

I've tried this now on a few of the lesser non raspberry linux systems and the method works on all so far, and even dropping the res down on the really low end systems makes them all viable dev platforms.. I'll incorporate a change res function into the graphics files and provide a demo soon. But this is a very nice solution to a long standing problem which will make it easier to compare Raspberry and non Raspberry systems by levelling the playing field as far as their renderbuffers are concerned.

I also tried it on the Raspberry 4, and of course it has to be different, yup I can change the res, but strangely the performance is still poor on the test projects at 720, only picking up at sub par resolutions like 800x600, I really don't think the drivers are fully mature yet, but at least I can alter resolutions to suit the abilitiy of the target, thats a big step.

yeahhh another new Orange....... I think I only have 1 in my drawer that actually works with graphics, can't remember now. I buy them, find them to lack drivers and put them back in the drawer..maybe I should do a recap sometime soon as their OS's must have had updates and maybe have GPU drivers now.

Its not really something I should grumble about, Orange make no claims their boards are for anything other than maker projects and many makers just don't need accelerated graphics (and are often quick to point this out when you complain about the lack), but the rise in retropi builds is seeing more and more units needing support and the combination of low cost and high features of most OrangePi boards makes them appealing to that market.

Anyway, this is another RK3399 board, and indeed most of the other RK3399 boards have had drivers, Rockchip  must be releasing the drivers so hopefully this one also has the goodies on board.
Its under the $100 limit, and the addition of an AI support chip may be interesting, though I find most of these add on's to be very very specific to deep learning which isn't a topic that interests me much (I wonder if there's other things I can do with them), but with Rock Pi and NanoPi selling at a little less, its going to be down to market penetration to see which succeeds (Orange do have a good retail network, and ali express is pretty cool)


Orange  have a tendancy to chuck these boards out and then move on to another design but this does look promising, even though its more expensive than the NanoPi M4 (my current fav RK3399 unit, an awesome, but a little flaky with its eMMC, board), though with 4GB rather than 2GB or RAM.
I must say I like the moves toward more ram, 1GB was nice but  4GB is 4times nicer

I'll order one next month and try it out.. I do hope it is driver supported, the Mali T860Mp4 is a nice GPU and I'd love to try to compare it and the other RK3399 boards, with the Raspi4's new videcore chip.
There's no sign of a case or specific heat sink, which for sure these puppies will need, the Rock and Nano Pi units come with solid lumps of aluminium to keep them chilled, and a standard RPI stick on ebay unit wont' do much to keep these babies from running a fever. Might be wise to wait till suitable cooling cases are ready.
https://www.cnx-software.com/2019/11/29/...Hc2fnQ2B4k

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