well quite a lot actually...

check this out, and this is only half done

https://tinymonstersplayinggames.blogspo...thing.html

So I've been using STB and TinyObjLoader for a few years quite happily on my stock projects, which have no major issues, but recently I needed to load a model and tinyobj could not cope with it, nor load the jpg textures. This was a bit of a pain, especially when I noticed my students were managing fine.

Well at least the old versions of the code I have on my projects couldn't, the new versions can.... so I'll have to produce some builds that link to freshly updated onboard libs rather than continue to use my now outdated versions in source code...coding is never ending fun isn't it

New SBC day, which is good since Im in lockdown due to the Corona Virus and was getting a bit stir crazy.

Ordered the Rock64 2GB board from Pine, with a nice black aluminum case for passive cooling last month, it finally arrived but I am not upset at the time, given the world situation its not something to lose sleep over. Anything from China is going to take longer for a while.
Love the case, but if you need access to the GPIO pins....sorry..


What a nice little board and case combo. Another Rockchip board but this is Rockchip RK3328 Quad-Core SOC with Mali 450MP2. up to 1500Ghz A much lower  end Rockchip compared to the ones on Tinkerboard and RockPro64 etc. So CPU wise with 2GB of LPDDR3 RAM it should match or slightly outperform a Raspberry 3,

In use its as easy to set up as any other Pine board, the very cool Pine installer app lets you select a few different os's to burn to the SD and off you go though it does not give any indication of the feature sets of each OS, but various Ubuntu, Armbian and a Debian flavours are on hand do a bit of reading 1st to select the OS that has your needs.

One thing I didn't know which the installer showed up, was there is a V2 and V3 version of the board...hmm mine is V2 despite the V3 being out for a while, and mine being a recent order..Not too sure what the difference is. Not something I'll worry too much about given my try it and store it appriach to boards.

I started with a version of Ubuntu 18.04 LXDE which installed and booted no problem but in a low resolution..uh oh, but not to worry I found the display settings and set it to full size no problem 
After a quick update and upgrade cycle, I installed GLMark2-es2 and ran it, on screen, right away my heart sank, it was really low, the 1st couple of tests usually give a good indication of speed and 31 and 39 were not inspiring.. So I stopped and ran it off screen, expecting to see the same numbers indicating emulation but no it started throwing out some great 300+ numbers.. So there are drivers but the EGL/X11 pipeline isn't ideal.

Sadly though it crashed out with errors on the last few tests and recorded an average score of 200 off screen. I ran again on screen and it gave a pitiful 34.... oh well
Since its only a Mali 450Mp2  I guess thats ok, its on a level with a Pi3 maybe a 3B+ off screen at least.
I wasn't too impressed with that so decided to try a "feature complete" Debian build 

Debian by MrFixit sadly refused to boot, going into an on off cycle, I was using a V2/V3 version so decided to try a V2 only version and then discovered it was the same version, but I flashed it again...still refused to boot.
I tried a 64bit minimal Debian version, it was a bit flaky, and no desktop but after a couple of crashes and restarts it seemed to stabalise and I did an update/upgrade and installed mesa libs and build glmark2 to see what I'd get... That took a while, maybe the case isn't cooling as well as I'd like and its throttling? (later tests with a desktop CPU temp display showed it running comfortably around 50deg, so the case works)


But nah nothing doing there, I was kinda wondering if I could open a window and run opengl even in a text system...oh well
Armbian does have a GPU addon for this board...but I'd lost interest by then.

In the end I went back to the desktop Ubuntu version with its dodgy x11 updates, and ran my usual maze game test...it built just fine...but mysteriously refused to run...need to investigate that, cos that seldom happens. It seems to regard the executable as an ,so file??? It did run if I tabbed to the dir and manually entered ./runnabledemo but it was very slow, maybe due to the full res, I wasn't able to do much debugging to improve things.


Overall the board itself on paper, is nice, well featured, but not especially fast, I didn't see it hit 1500ghz even when runing 6 threads to compile.  2 USB2's (one with OTG) and a usb3 are fine, an IR port , reset and power switches are nice to see. It needs a thin 3A5v power jack socket rather than micro USB.  I love the $13 case that keeps it all nice and tidy and cool (though the plastic LED lens refused to fit). The software clearly is a bit hit and miss at the moment, so it goes back into the draw while we wait for updates.

Value for money wise though the Pi4 offers much more speed and graphic power and is a lot easier to get hold of and it runs out the box. Not sure this really offers anything useful to me as a graphic coder, but perhaps for a builder who needs an IR and a standard power system it might be nice.

I would have expected better though, the RockPro64 is an absolute beast with nice GPU drivers in place, and even the Pine64 is now a nice stable system. If this is what Pine are hoping will target the Raspberry market it might be a misfire.

oh dear, I don't quite know what happened, but a reader contacted me last night to ask where the chapter 12 files were on the DVD collection of Magpi mags he bought.

I have to take full responsibility for this, I don't appear to have sent them to Magpi, meaning they were just left out of the repo. I will have to reconstruct the files and upload them...sorry if you are waiting to finish of a great game..Watch this space.

Its almost Pi day... I wonder what they will do this year... I read in an article a few months back that they have some super secret project tucked away in a room.. But of course no one knows what... It might just be something like a screen or a hat. It may even have been the USB fix, but I'm guessing it will be something more substantial.

I can't see it being a new Pi, the 4 is settling in and being accepted by the community, its little flaws being slowly fixed.

So... maybe a laptop using the Pi4 as its core?

Lets see on Saturday.

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.