61
Support / Re: raspberry pi, orange pi, etc
« Last post by AGP on January 25, 2023, 11:20:20 pm »Oh, and here's something I didn't know: lwjgl now has Vulkan bindings: https://www.lwjgl.org/.
News:
Recent Posts
62
Support / Re: raspberry pi, orange pi, etc
« Last post by AGP on January 25, 2023, 11:11:51 pm »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!
63
Support / Re: raspberry pi, orange pi, etc
« Last post by EgonOlsen on January 22, 2023, 12:18:45 am »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...
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...
64
Support / Re: raspberry pi, orange pi, etc
« Last post by 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
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
65
Support / Re: Disable cameraLookAt
« Last post by AeroShark333 on January 13, 2023, 07:19:15 pm »I'd temporarily store/clone the RotationMatrix of the camera on the moment you enable the freecam. This means you'll have the last known camera rotation matrix which was used when the camera used #lookAt(...). Then instead of doing #lookAt(distantDummy), you do #setRotationMatrix(temporaryMatrix)
66
Support / Disable cameraLookAt
« Last post by Ackastar on January 13, 2023, 04:21:30 pm »Essentially I have a camera looking at and following a vehicle as it moves around in 3d space and sometimes I'd like to disable the lookat and start a freecam.
i.e turn of the cameraLookAt temporarily to be able to move around by translating the cameras position, maintaining its rotation.
I've so far tried to create a distant point to replace cameraLookAt(vehicle) with cameraLookAt(distantDummy) but im not quite satisfied with the solution.
Has anyone done anthing similar?
Thanks
i.e turn of the cameraLookAt temporarily to be able to move around by translating the cameras position, maintaining its rotation.
I've so far tried to create a distant point to replace cameraLookAt(vehicle) with cameraLookAt(distantDummy) but im not quite satisfied with the solution.
Has anyone done anthing similar?
Thanks
67
Support / Re: raspberry pi, orange pi, etc
« Last post by EgonOlsen on December 04, 2022, 10:54:26 pm »Yes, sure...the software renderer will work just as it is on a Pie.
68
Support / Re: raspberry pi, orange pi, etc
« Last post by MichaelJPCT on December 04, 2022, 10:02:40 pm »what about the software renderer of jpct? although slow, it is useful in some cases.
69
Support / Re: raspberry pi, orange pi, etc
« Last post by AeroShark333 on December 04, 2022, 03:00:18 pm »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
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
70
Support / Re: raspberry pi, orange pi, etc
« Last post by EgonOlsen on December 04, 2022, 09:04:11 am »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.