SDL3 version of t30dpy added

[Bill E]

I went ahead and made an SDL3 version. It's a little faster, but the big improvement over SDL2 is the rendering and especially the scaling, much nicer. At install time if you say to install dependencies, it will see if SDL3 is available for your system and if so install it.

When t30dpy is built, it checks for SDL3 and if installed builds the SDL3 version, otherwise it builds the SDL2 version.

They are functionally the same except the vsync flag and config are ignored for SDL3, it's not needed and in fact causes problems.

I've spent a lot of time on the accuracy of the reproduction, consulting datasheets, maintenance manuals, and outside experts. I think this is as close as you can get given the limitations of LCD raster-base displays. Both versions have the identical phosphor simulation.

Here's an interesting bit. P7sim is a real CPU hog on most platforms, EXCEPT the pi4. Why? It's because SDL2 which it uses is rather old and it uses GL under the covers which was optimized for the kinds of gpus at the time. The pi4 gpu just happens to align perfectly with the GL driver, so it performs quite well on that particular platform. Amusing. Regardless, t30dpy is much nicer looking imho. :)

It's checked in, and remember, it will work with the regular pidp1 branch also.

https://github.com/wjenh/pidp1-mods.git

Bill

[Bill E]

I tracked down why p7sim performs so poorly on most platforms but is fine on the pi4. It's kind of interesting. It's as I mentioned, P7sim and P7simES use custom GL shaders. SDL2 is GL centric. It turns out that the Broadcom GPU in the pi4 was specifically designed for GL rendering, so there is a perfect match. On other platforms, that isn't the case and SDL2  and the video drivers have to do a lot of work at the CPU level to get the 'old' GL operations to match up with other GPUs. For modern os releases that use new GPU flows (because most people play video games and the flows are now tailored for modern ones, and not in the way GL wants) the problem is severe. This is why I avoided GL. SDL3 handles this situation much better, it knows how to create its own shaders and renderers appropriate for the actual GPU  to some extent as long as you use the SDL methods. It can expose the GPU, but then you have custom code that isn't necessarily portable. So, the tradeoff is being locked into an architecture for maximum performance or trading some performance for more portability, classic.

Bill