Pretty sure I have this elsewhere on this forum but adding it again for students to see.

OpenGLES2.0 has limited error handling
GLint err = glGetError();

Only gives you an indication that an error happend once, sometime ago... you need to step back and  find it

Its far easier to check an error when it happens, and OpenGLES3.0 allows that. You need to install some libs, your system may not need all of them but best to try and install them.

sudo apt-get install libglx-mesa0-dbgsym libglapi-mesa-dbgsym libgl1-mesa-dri-dbgsym

Also as this is also an extension it will also need libdl added so add dl to your binary libs it shouldn't need to be installed it should be onboard

Next you need a small callback function somewhere in your code but you need to set that up I use this, which is the actual callback and the init function, this lives in my main.cpp file and is called after openGL is initialised.
My sincere thanks tomy collegue Phil de Groot for working this out, its proved very helpful.

What is it with me and RockPi?

I really want to like these boards but always seem to find them lacking, often due to OS issues... but... anway, I took advantage of the preorder discount at the start of the year and today was finally allowed to make the order, technically with the discount the board came in at $79 so inside my $100 limit, but I did add ac ase and power supply then postage, so yeah it went over $100...

That said the Rocks are functional, just not the Raspberry beaters they ought to be, I pulled out my rockpi4 for a bit of testing the other week after a painful update and resetting of things, tbh it was no better so I put it back in the drawer... But maybe the 5B is the answer. (or the 6 or 9?)

So one of these should be hitting my desk around November....
On paper... as always, a beast... I hope it actually lives up to the promise a 2.4/1.8ghz octacore and a stunning  Mali G610MC4 GPU should make this a total monster.....also has NTU, but thats not something I know a lot about


Fingers crossed

https://www.cnx-software.com/2022/01/09/...-computer/

It's not so much that my code won't work as it is that it doen't work how I think i should.

Having built and run the first triangle example, VisualGDB asked me to install XMing so that it could display the X11 session on my Windows box. I'm building on the Pi currently, not cross-compiling.

I was expecting the graphics to show up on the actual Pi's X11 session; that's what it looks like happens from the screenshot in the book.

VisualGDB only has a "Local Windows Debugger" option available in the dropdown (VS2022, Win11). However, I've only recently moved back to Windows from macOS and I usually use VSCode and/or the Jetbrains IDE's, so it's possibly just not knowinbg where to click!

How do I launch the program (in debug mode and normal running mode) on the Pi from my development host?

I've recently purchased the book and am trying to get the initial triangle code running. I've some experience with normal OpenGL but I'm by no means a graphics programmer. I have no experience with SBC and thought this would be really fun. But I'm struggling to figure out what needs to change to work on the current hardware, despite the helpful posts dotted around the forum.

Specifically, I currently get squiggly red errors that EGL and GLES cannot be found when included. Here's my list of libraries and includes from VisualGDB:

Include directories:

• /usr/include
  
• /usr/include/interface/vcos/pthreads
  
• /usr/include/interface
  
• /usr/include/interface/vmcs_host/linux
  

• /usr/lib
  

• GLESv2
  
• EGL
  
• X11
  
• bcm_host (although I don't think I need this)
  
• pthread
  

• libgles2-mesa-dev
  
• libxrandr-dev
  
• mesa-utils
  

• GLESv2_static
  
• EGL_static
  
• vchiq_arm
  
• vcos khrn_static
  
• bcm_host
  
• pthread
  

Hi all
Well we've reached a point sadly where the rpi3 code is not going to work any more using Bullseye. all the old Broadcom vc4 drivers have been depricated and are no longer part of the bullseye install, so the code will no longer build or run as it stands.

Generally this isn't a massive issue, as once we have the graphic systems set up we can ignore the OS, but in the case of the Rp1-3 the broadcom DispmanX system was used to make the graphics framebuffers. Without them the code isn't going work

But in theory installing the mesa libs which now have VC4 support you can get things up and running, the set up is similar to how we do the Pi4 code, and we now use X11 to send our graphics to the screen.

But there's a small problem at the moment with the EGL drivers not initialising, I am looking into it, when I work it out, I'll post a new hello triangle project set up for you here to allow you to progress if you are using a Pi1-3

Im working on the issue and will try to get the fix to you soon, I've also asked the Pi forums if theres a way to install the depricated system.. I suspect not but who knows.

Something I was not aware of, but am passing on here relating to extensions in OpenGLES3.x

Though it seems odd, the gl3ext.h file is redundant, it has no content, in fact all extensions for OpenGLES3.x are actually listed in gl2ext.h

I know right? This was news to me, but happy to have been informed about it.

Anyway, I post this because I was just trying out the new Geometry Shader extensions on the latest mesa drivers for Raspberry (Bullseye OS, mesa 20.3.5) and was having some issues getting it to recognise GL_GEOMETRY_SHADER  as a valid shader type to compile and link. 

Geometry Shaders are a 3.2 feature of course, so I included the gl32.h header and it worked fine and is an exciting addition, expecially to make particles more interesting and for a quick normal display debug option. But it niggled me that was probably going to cause an issue using that header, and posted a question on the Raspberry forums which I'm happy to say was responded to promptly.

Use the gl2ext.h header and for the type of shader use, GL_GEOMETRY_SHADER_OES and now we're in business. The only other thing to do is make sure in the gshader itself you inform the shader to use a couple of important extension values to allow it to compile, it needs to be version 310 es and you have to inform it about 2 extensions that are required to make it work

#version 310 es
#extension GL_EXT_geometry_shader : require
#extension GL_EXT_shader_io_blocks : require


thats it.. when you make a PO, just add the geometry shader you compile to the vertex and fragment shader before you link. It will sit in the middle of them, they seem to work very well, though I've not pushed them to any extreme, I can indeed generate new vertex outputs. I will tinker with them a little more and report any problems.

There's a great tutorial on geometry shaders here

As I've been doing a lot of research to create new OpenGLES3.x systems and at the same time prepping my students to do a Pi4 project this year, I have decided to roll the research and student project into making a full scale freeware game..

I'd like to update my webpage to show this but as I've just completed a transition to a new PC i dont' currently have the tools in place to do that, but will sort it soon..

Details of the project are on my Patreon page at www.patreon.com/BrianBeuken 

If you would like to support this, please sign up, even a few dollars can make a difference.


I won't post too much on here until its done but when it is complete I'll use make the key componants available and useable for readers to build their own content.

I've been looking for some nice models on line to do a tutorial on model rendering and shading, and found these lovely things
This is just diffuse and ambient, going to add normal mapping, emissions and specularity. Might even tinker with a bit of PBR since I got the contet
I had to buy these, I don't normalluy but my own attemps are not great.

I also got some smashing lower res models also with mapping textures that will look very good when I take the demo a bit further.

I have a very bad habit... when defining classes in C++ I often just put the label and type... This is usually ok, since I seldom write release builds.

The reason there's a difference is that in debug builds the compiler usually nulls all variables and clears memory to 0..release builds don't, memory is as it is when it fires up.

Usually.

I discovered the compiler on the Arm64 Jetson doesn't.......

And it took me 6 hours to work out why, in a demo I was workig on that worked perfectly on 8 other machines, only the Jetson redused to display the 1st of 4 test models........


I had not 0'd a rotation Vec3, and in the update of the model I was rotating assuming 0.....


Bad habits only get broken when you make bad mistakes.... 6 hours though...ooooff.. I should know better.

I have now put default values in all class varibles in the class define.

bugger... oh well I got it from a proper supplier, so sending a return request.