I've been doing it wrong.....

Since I started coding on Raspberries, I've been using a simple framework that displayed my OpenGL content using DispmanX systems, that worked great.
When I tried to use other SBC's it turned out they didn't have DispmanX, so I discovered they used X11 to display.. I thought that Raspberry's DispmanX was a replacement for X11

I was totally and utterly wrong, and its taken 3 years and a confusing thread on the Raspberrypi.org forums to make the clear.

Raspbian does use X11, it ALSO uses DispmanX I guess as a way to draw bitmaps faster, it may indeed be a bit faster than X11, but I would have to do some tests.

The DispmanX stuff is still fine, when all said an done, all we are doing is working on a framebuffer and depending on the system to display it. Both X11 and DispmanX do that, while we are busy working away behind it, not really caring how it gets on screen.

But it does mean, that in principle at least it should be possible to get all Raspberries to render with the same X11 systems as the other SBC's... mind you my first attempts to do that are failing, so for now keep DispmanX until I work out why I'm unable to create a surface despite opening X11 windows and displays and EGL contexts....more research is needed. But it might result in a much cleaner config.

Over the holidays I did a bit of searching and trying to view anything I could regarding OpenGL ES on YouTube, but this search always seemed to land on a vid about Vulkan. Most of the actual OpenGL ES vids or tutorials I found seemed to be focused on Android.  I suppose this does show a need for a book such as "The Fundamentals of C/C++ Game Programming"


With regards to Vulkan, one particular vid I found was from GDC 2018 titled "Getting explicit: How Hard is Vulkan really?" where a  group of folks from various studios described their adventure with Vulkan.  They all seemed to admit that it did take a bit more work to get something going with Vulkan, but once they had it up and running it was relativity easy to other functions working.  The interesting part was from the Dustin Land from id Software where he mentioned that idTech has been completely ported to Vulkan and they are no longer using OpenGL outside of legacy support.

The panel at the end of the vid was even more interesting where most of the folks on the panel mentioned that for any open positions that they had, they had no openings for OpenGL and are only looking for those with Vulkan experience.

https://www.youtube.com/watch?v=0R23npUCCnw


There is even an effort to get Vulkan support with the Raspberry Pi 4 and the VideoCore IV GPU but not much real progress here.
https://www.phoronix.com/scan.php?page=n...-Code-Drop

The NVIDIA Jetson Nano does have Vulkan 1.1 support and seems to work fine with some of the samples I have found. 
https://www.khronos.org/conformance/adop...t-products

Although there is a Mali-T760 support with Vulkan 1.0, I have yet to get it to work with the Tinkerboard running Armbian with manual installed Mali drivers.

It does seem like the industry is moving toward Vulkan so It will be interesting to see how this all progresses as more support is added to Vulkan.

I had seen this on the Raspberry Pi OpenGL ES forums and thought it would be cool to reference it here.
https://www.raspberrypi.org/forums/viewt...8&t=262214

It appears the the Raspberry Pi foundation is moving forward with OpenGL ES 3.1 and perhaps 3.2 support with the Raspberry Pi 4 boards.  

Here is the link from the Khronos site:
https://www.khronos.org/conformance/adop...ission_882

Oh why do I do this to myself.. I only bought it because it has an interesting Mali 470 GPU, but of course no drivers...and its slow and sometimes unwilling to boot

It does have 8Gb eMMc on board so at least its not going to take up an SD card in the drawer of shame. (if I can actually get the eMMc loaded) Though a 2GB version is available mine is a 1GB and only 566MB are available for use,making it choke on multi core tasks as it runs out of memory. I'm guessing some of that memory is also going to the GPU but no real way to tell


Anyway.. I got this months ago and failed to get it to work, this time though after a few false starts it booted up with a fairly recent version of Debian Buster on it.

But it is painfully slow... Nothing useful on the very slim OS to test it out, no glmark2, but after an update which took an age, I was able to install glmark2 and try to run some tests.

Sadly I wasn't able to get the usual maze demo to run...oh well it had issues with EGL that might be fixable

GLmark2-es2 took ages to build locking up frequently even running the builds on only 1 core. It also failed to authenticale EGL
but it managed to run all the tests 


And..... of course it emulated, so runs very slow on and off screen:
On screen score of 21
off screen 31

I might try it with the ubuntu mate version too....someday



So basically, its a dog... don't buy it unless your project specifically calls for it.

Self explanitory title I suppose, hope you are all well. Its been quite a rough 2019 for me, lots of personal and professional stress, some deep loss and some dumb personal cock ups.,  but 2020 is all fresh and new and waiting to be messed up...lets get started.

So, I am looking to join a local extended Game Jam in January that goes for 9 months and was thinking of trying to get a SBC OpenGL ES game going.  Most folks seem to want to use Unity and perhaps Unreal Engine but these seem a bit over kill for a small board. Plus, I do not have a PC that can run either, oddly enough. I'm also trying to avoid anything like PyGame or SDL, although these are interesting as well.

So, anyone have any experience with Game Jams and using a board like a RasPi or similar to create a game?

I'm curious about any thoughts folks might have.


Cheers,

Jon

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, guess it reports its status flag inverted)
UP^2                  1593/657 (jellyfish corrupts)
Up Core               1291/493 (jellyfish corrupts)
Odroid XU4          743/410 (yup we've had this level of power for years)
RockPro64           714/locked
Tinkerboard         470/locked ( recent updates have seen this drop to around 390-410...)
NanoPiNeo4         378 /locked
NanoPi T4            330/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+*    37/25 (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
BananaPi M4*         31/21 (it also lacks memory managment so struggles to run anything large and CPU is painfully slow)
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/