raspberry pi, orange pi, etc

[MichaelJPCT]

does jpct work on these devices?
there devices are marketed as computers for students. if jpct works on them, more students would get to know jpct. 

[EgonOlsen]

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.

[AeroShark333]

Afaik, you can even run Android on a Raspberry Pi which has proper OpenGLES support. In that case jPCT-AE could be used.
But then again, I would argue that you can make jPCT work on a Linux distro too (Raspbian or such). I would believe that there should be some sort of OpenGL support available as for how popular the Raspberry Pi is. It might not work as seamlessly as on Windows but I wouldn't know for sure until someone tried

[MichaelJPCT]

what about the software renderer of jpct? although slow, it is useful in some cases.

[EgonOlsen]

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

[AGP]

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

[EgonOlsen]

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

[AGP]

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!

[AGP]

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

[EgonOlsen]

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.

[AGP]

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.