In book one I used a library build to gather together all the small frame work methods, like file handling, sound etc, that we were repeatedly using. This was in part becuase the Pi3 is a really slow machine and full rebuilds were taking a long time.  Thats to say compiling them all regularly was slow, but Linking takes alsmost no time, So as I went along I seperated common content to a mylibs build that could just be linked in without the compiler time overhead,  and that worked great

The only downside to that is that as you move along the progression of the books projects, your mylibs does grow and change and it can become less compatible with the earlier projects you build.. Not that many people went back to 2D after 3D but... some did.. I explained to them, just rebuild the lib for each project one time and all will be well.

It can still work great on the new version with Pi4/Pi5/Pc  just make another common project as a lib output and include that lib as a lib.

But these newer machines are soooo much faster that I didn't really see the need to shed off the common files.. You can still do it if you want though, I leave it up to you, Lib managment is a nice skill to have, and you making a portabl lib is a nice idea.

I might make a video on it if people tell me they need it explaining.

Lets put a lilst of common issues here so they are in one place.

And we'll start with the most common of all

Could not connect to the remote system or the connection was lost.

If this is happening on your 1st attempt to connect, make sure your cables are plugged in, Bookworm can be annoyingly fussy about making connections and sometimes you might have to set up a fixed IP on your Pi and address it directly. I havn't found a fool proof way to get round this. 90% of systems just connect, 10% spend forever attempting to connect then report failure... 

If using the .local naming method, always make sure you have referenced the targets name correctly in your cross platform settings. if you have, try to use its IP address instead, because sometimes when you switch things off, you might lose the link between  the .local name and the ip address it saved when you set it up.

If you connected correctly beforehand, go to Debug->Options>Crossplatform, and try verifying your connection and make sure you are defaulting to your correct target. If it fails to verify, remove it, and reinstall it as a target.

It may then connect but you will have to do a rebuild 1 time to re-establish the connection between your PC and Pi.


Exception Unhandled, segmentation fault
Now usually these are very specific to bad pointers which will be mostly down to your code,  but there's one very common one, if it occurs in the Xwindow.cpp file when you try to get Rootwindow, it means you system was unable to open your default window. 
Two main causes for that, 
1, if you initially fired your target up while not connected to a monitor, it will have no display and therefore will have no pointer..
2, more common, you somehow don't have export DISPLAY=:0.0 as your pre-launch command in the debugging ->Pre-launch command setting of your (raspberry) properties.
.

For Pi we use the aarch64 libs but remember that Linux PC's still have all the same basic content in their libs, and most of thos lib names are common

My Pi and other 64bit arm systems point to these library dirs.
/usr/lib
/usr/lib/aarch64-linux-gnu 
/usr/local/lib


But a PC running debian will store its  hardware libs in a different locations, not aarch libs

So I use these library paths for my i5 mini PC running debian
/usr/lib 
/usr/lib/i386-linux-gnu 
/usr/local/lib

So you still reference all the standard libs, installed by you or by linux but machine specific content is located in i386 in my case..(I can't 100% be sure your's won't be x64 or something)

Just find out what your bins  are in your usr/lib dir and that will be the dir you send your systems to.

A most recent version of VS2022 seems to have a reported flaw in its ability to open up a terminal when debugging code on a target system

https://developercommunity.visualstudio....n/10905070

This basically means that when you run your code on the Pi you won't get any of the printf, or other console output comments being displayed on your VS terminal or debug output.. This is quite a pain, especially for me at the moment as I am testing a lot of Pi3 updates and need those printf's to be sure code is working.

But I'm hoping I can roll it back to a working version and wait for MS to report a proper fix.

If you have just installed VS2022, ermm not much we can do until MS fix it.

If you have the code from the first edition, downloaded before the update, then you should be aware that it will not work on the Pi4 or Pi5. And quite probably not on Pi3 even with older Rasbpian OS.

Too many updates to other things have totally depricated the code. I can't get it to build on several of my older Pi3's either.. I have now removed this old content from the Website, I just can't support it any more.

Of course this is an issue, you can't download or even enter the code snippets from the original edition and I was very upset that people contacted me with news that their code no longer worked.

But... there's now a solution.

The new version of Raspberry OS, Bookworm, will allow us to get a new dualboot version of the download code  up and running on a Pi3. the code layout will be a little different but the main code intentions (and some of the deliberate errors) will still be usable.

I am actively working on updating all the Pi3 code and adding it to the Downloadable content, it should all be in place before the summer holidays.

As far as the 1st edition printed code is concerned, consider it depricated, you will find the new download code has much of the same content but order is changed and some filenames altered, as well as the bits that no longer work (mainly DispmanX and BCM utils) have been removed and replaced with more generic X11/EGL content.

I am producing some website content to explain the changes.

You may be seeing this error when you log in.

Authorization code mismatch. Are you accessing this function correctly? Please go back and try again.

Apparently its a known issue, and should get fixed in later mybb updates, it shouldn't impact your usage of the forums. the main issue seems to be it won't remember your log in if you leave the forums. I could fix it, but it means tinkering a lot with different template files and thats never wise, so I'm going to leave it for now.

The mail system is now working, so if you register I will get an email to come and activate you, and you will get a mail informing you you have been activated.

Also when we have more members you cn also mail or send personal messages.


Wasn't able to do that before with the old forum, I'd done something wrong when I set it up, so qute pleased about that.

Hello?

The Pi3 situation is, that none of the original pi3 code will work now, even on some Pi3's. Driver updates and other things over the last few years have rendered the various test projects unusable, even on Buster OS on Pi3.

Its always due to the use of BCM libs to create Dispmanx displays, these were very specific to the Pi3, and the Pi4 didn't support them at all so that code depricated unlike the opengles2.0 and EGL drivers, which have probably updated...but no longer work with BCM.

So, as noted in the website the Pi3 content needs to be updated 1st.

I'm currently working on that, its not massive work, but it is a bit of a time drain so Im doing 1 or 2 a week. 

The main thing is to make sure your Pi3 is running Bookworm (or later) and I set up the new dual book framework as an openGLES2.0 build to X11, not DispmanX

Removing all use of the BCM libs basically gets OpenGLES2.0 set up and the demo's themseles dont need much more twiddling.


for now Hello Triangle and Photo frame are in place/

I will work on Invaders and Kamakazi next.

4th times the charm..

Sorry I lost the old forums, and seem to still be having the odd issue where new ones get trashed, it may be due to a hosting issue, but sign up and lets try to recover