Not sure what the screen recorder does. Maybe the built-in video encoder can encode screen content directly? No idea...getPixels() is as slow as OpenGL ES. Plus the conversion into jPCT-AE internal format, which requires some byte flipping.

This is an impressive piece of work. I've no idea how to control my plane and I crashed it into the ground, but it's cool nonetheless.

Yeah, I think AeroShark333 is right about this. I couldn't find the corresponding thread (if there is any), but I dimly remember that I did something in that regard. Check the max value in TextureInfo and the log output. Somewhere, there should be an output about texture units...

Is this using jPCT or jPCT-AE?

Nah, not my cup of tea, I'm afraid.

I don't really think so. You could do it, but it would mainly be hacking around some of the concepts in jPCT that exists because it's meant to be a 3d engine for displaying existing content, not for creating new one. For an editor, I would go more low level because you constantly have to update your vertex buffers and such.

I don't think that jPCT-AE is very well suited for this kind of application. It's made to render more or less static assets fast, not so much for updating them constantly. Also, it doesn't supports lines properly (mainly because GLES is limited in that regard).

It depends, I guess. You can run software and hardware renderer in parallel if you are using distinct worlds and objects. You can also make the software renderer use all available cores. If that's faster or not highly depend on the application and if it's worth the hasle...I'm really not sure.

Yes, that should work. Would it be faster...faster than what?

It is possible to use the renderers in parallel to a degree. IIRC, it will hinder the GL renderers performance slightly and combining the results of both will most likely eat up all the benefits that doing so might have. I don't think, that it's worth it.

This is sick... I'm already bad at solving the 3D cube, this one is even more confusing...but pretty cool nonetheless! I like the tiles shifting around.

A little remark about the german translation: "Speisekarte" for "Menu" is correct only in the context of a restaurant. The correct translation in this context would be "Menü".

Yes, looks like it. Not sure, how well LWJGL works on the Raspi though. It should run, because there is support for Linux ARM32/64 and I found some threads about it.

In that case, Vulkan or not, it should be possible to run jPCT...BUT...that would require to port jPCT to LWJGL3 and I don't think that this is worth the effort.

Have you ever looked at Vulkan? I'm all for low level coding if needed. I'm still coding some stuff in assembly language. But Vulkan...I can't be bothered, to be honest. You have to do really complicated calls to do basic things and I fail to see why this is supposed to be an advantage...yeah, performance and such. But to be honest, I rather think that the better performance comes from the fact that the old APIs and their supporting drivers got bloated over the years, not because going low level is the only way to go. After all, you are still going to wrap the low level calls of Vulkan in some higher level calls, so why not design them higher level it the first place?
Anyway, that's actually not the point. It's not that there is no support for OpenGL ES on the Raspi, because there is. There's no binding to Java for it. And there's none for Vulkan either, so it wouldn't help anyway...

Yes, sure...the software renderer will work just as it is on a Pie.

No, not as it is. While you can run a JVM on these devices, I don't think (correct me, if I'm wrong please) that there is an OpenGL (ES) binding for Java available on these devices. Without that, it can't be ported.