this car has caused me so much pain off and on..

It was intended to be used in the book and part of a chapter on optimising and rendering transparent objects, but 2 things happened, the book got too big and the optimising chapters got droppped and this model, turned out to be a bit of a pig to render on a raspberry.. So I left it alone. It came from a free model site, Turbo squid I think and I asked the modeller if I could use it, but it had a lot of extra content in it that my renderers then just didn't know how to deal with, and I struggled to get it to show itself in its complete form, especially with the canopy.

But I popped back to it from time to time, and as I will be doing a lesson soon to my class about rendering with light and transparency, I dug it out again and made some progress at last.



Its not actually a good example of rendering yet, I'm frigging the transparency a bit by isolating the canopy shape then forcing the shader to use a blue tinge, but its coming along, its forced me to examine more of the material content for the OBJ file, and use it as part of the render rather than just abandon it for speed reasons. I'll soon have an OBJ render system that can just draw things like this without any special isolations... though performance might drop, its good to have options of quality needed.
Its one of the questions you need to ask yourself as a game coder, do I use a special shader just for this model that gives me speed, or do a I use a general shader that will draw it and every other model but with a speed penalty....questions like this need to be asked! (And in nearly every case, unless there's a memory/tech limitation on numbers of shaders, you go for the fastest option)


Going to add some normal and specular mapping next to really make it pop out.

Oh and a Rpi 3B (not a 3B+) is comfortably rendering this  model with Total Triangles 25344 Total Vertices 76032, in 60fps, with no optimisation at all, I'm going to also use it to demonstrate how render speed can be improved with shader managment, batch rendering and the old favourite of index buffers. The actual model does have far fewer vertices than that, but TinyOBJ triangulates all the faces so the triangle count bumps up quite a bit, I plan to have a look at that sometime and see what can be done to make better uses of strips and fans as well as indices. For that reason this was a good model to use even though it didn't make the book.

60fps...really neat. It managed 2 of them at that speed, 3 though. saw it drop to 40, so my aim is to get maybe 10 of these at 60 htz.. on a Pi3B

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  GLES     1291/514 (jellyfish corrupts)
Up Core  GL3       1259/495 (jellyfish still corrupts)(just to compare gl and gles, no real advantage apart from easier coding

Odroid XU4          743/410 (yup we've had this level of power for years)
Pine RockPro64    714/locked
NanoPiNeo4         519/locked burned new Friendly elec desktop and performance is back baby. 
Tinkerboard         470/locked ( recent updates have seen this drop to around 390-410...)
NanoPi T4            330/locked
Odroid C2             323/122(ubuntu 16.04) -Odroids have always been the power systems for graphics. (18.04 isn't significantly different)
Raspberry Pi4B     300/136


Libre La Frite         277/uggg   only logged scores of 7 or 8 on screen, so lots going wrong there but has clearly got drivers off screen
Libre Tritium H5    260/locked (actually there's more to this, it actually runs fine with its mali450 off screen, but onscreen is painfull, maybe x11 issues?)
Radxa RockPi4      249/locked (bit dissapointing this, but it does seem to be running with es3.2 drivers)
Tinkerboard 2           233  /locked Mali 864 OpenGLES3.2 X11 out ... bit surprising.
Odroid N2            212/locked (currently have to use GLmark2-es-fbdev) <<< this is no where near what it can do, waiting for updates to see the beast rise. (Im told...but yet to confirm the newest Ubuntu 20 with wayland composit can rate at 1200......hoping to test soon)
Pine Rock64          200/39 Ubuntu 18.04 (though shows Debian screens) bugged out on the test though going to try other OS's
Pine Pinebook       192/36 KDE  This seems to be the only version of an OS with drivers and its modest 400Mp2's work fine, but its a chuggy machine.
Odroid C1             188/111 ubuntu 18.04 less powerful CPU  but the same GPU as the C2, 1 less core, interesting to see the difference cores make
Rpi3B+(KMSdrivers)    187/80 using X11/mesa and full the KMS drivers, not legacy but running ES2.0
OrangePi Zero+2  150/79
Nano PiM1                144/72  (some tests failed though)
Dragonboard 410c*   144/65
NanoPiNeo4         136 /locked The entry above is for different os, this is for Ubuntu16.04... , but in anger the system is quite capable.
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)
OrangePi Win*        40/18 pity, this is a nippy CPU and adding GPU drivers would make it quite a beast but no sign of any on the horizon (ubuntu 16.04)
Raspberry Pi3B+*    37/25 (it does have gles2.0 drivers but glmark2 and glmark2-es2 emulate, as it can't recognise broadcoms VC4 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

Rpi3B+(KMSdrivers)     0 failed using X11/Mesa but running glmark2 as OpenGl 2.1 for comparison, but crashes out with a segmentation fault

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