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.

I realize this is a bit last minute, but there will be an INSERT COIN Pleasure Dome Watch Party via the Alamo Drafthouse On-Demand Virtual Theater experience. INSERT  COIN Pleasure Dome Watch Part
https://ondemand.drafthouse.com/film/ins...gon-qanda/

INSERT COIN is a documentary about the Chicago's Midway Games from the Arcade days where games such as Robotron,2084, Mortal Kombat, and NBA Jam.  The doc was create by filmmaker Joshua Tsui and the Watch party is hosted by Polyon.
https://www.polygon.com/2020/11/24/21611...atch-panel

More Info:
https://www.insertcoindoc.com/

I still like to use free and functional libs even if a little old so long as they still serve their funtion I'm happy. So while looking into doing a network project, I reviewed what some of my students did a while back producing Battlehips. Its a great game and cross platform. One of the most complete examples of cross platform work I've ever had from 1st years.

And they used RakNet for networking. A nice lib I have used many times in the past, which was originally free or low cost for indie developers when I was coding in anger. Its since been bought out by Oculus as they wanted to develop networking libs, which in turn meant it was bought out by Facebook.

And Facebook did something nice, they made it freely available to all via a git hub so we can all use it.
https://github.com/facebookarchive/RakNet

As its not been touched for a long time there are a couple of quite minor issues with it, mainly because modern compilers don't like a particular line in ReplayManager3.cpp which needs to be edited so that line 141 where it says  == false is changed to == nullptr

There's a few steps to this, in a console on your SBC enter

sudo apt-get install cmake -y
git clone https://github.com/facebookarchive/RakNet.git /home/pi/RakNet
cd
cmake .


now open up a text editor on your system and do theedit to ReplayManager3,  oh and this is important, if you are using a 64bit OS you do also need to comment out line 24 of FileList.cpp, or it won't build on Arch64

once you've made and saved the edits go back to your console and do this
make
make install

And its built, you'll get a few warnings but it wil be ok, if your system throws out an error though, we might be stuck, let me know. Next move the lib into a more useful space on your system using these console commands

sudo mv Lib/LibStatic/libRakNetLibStatic.a /usr/local/lib
sudo mv include/raknet /usr/local/include/

Done.. you can keep the source and build files if you want but they don't get used, you've sent the important files to your system, and can be incorporated into your project

You can remove with this command.

rm -rf /home/pi/RakNet