Hello Egon,
i have a strange idea. can we use 1 opengl renderer and multiple software renderers at the same time in 1 process?
software renderers don't use gpu but only cpu. nowadays all cpus have multiple cores. if we use most cores for rendering (for example render-to-texture) it should be great, right?
if so, the software renderer can be a great tool.

Thanks Egon!!!

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ü".

Hello everybody.
My new game on jpct-ae -
https://play.google.com/store/apps/details?id=my.SerdyukovAleksey.KubicRubic

Quote from: AGP on January 19, 2023, 06:42:26 PM
Not to keep hitting the same notes, but Raspberry PI does use Vulkan... (https://www.raspberrypi.com/news/vulkan-update-version-1-1-conformance-for-raspberry-pi-4/)

If jpct would use the Vulkan renderer I would write a glb importer both for Java and for my C# port. It gives me more pleasure to program for jpct than it does for an engine like Godot (as much as I like Godot). Makes me feel like I'm actually needed. lol

Do you know what? I wrote one anyway. My glb importer only uses the org.json jar. It can read all the built-in textures and set them to the model. Limitations: it will set the normal maps as diffuse and it's not reading any kind of animations. But I'm pretty happy with it. ChatGPT did help a lot, but darn does it take a lot of coaxing to get consistent help from it.

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.

Oh, and here's something I didn't know: lwjgl now has Vulkan bindings: https://www.lwjgl.org/.

You might be right about the bloating of the drivers, but I don't think that that's all it is. There's a whole lot of 3d tricks that no one could have predicted when OpenGL was conceived. I have neither looked at Vulkan nor read this book (https://github.com/lwjglgamedev/vulkanbook). But the fact that the book exists must mean there are Java wrappers. And even if it were just that the drivers got bloated, well, the drivers got bloated!

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...

Not to keep hitting the same notes, but Raspberry PI does use Vulkan... (https://www.raspberrypi.com/news/vulkan-update-version-1-1-conformance-for-raspberry-pi-4/)

If jpct would use the Vulkan renderer I would write a glb importer both for Java and for my C# port. It gives me more pleasure to program for jpct than it does for an engine like Godot (as much as I like Godot). Makes me feel like I'm actually needed. lol