1
Support / Re: raspberry pi, orange pi, etc
« 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:
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Support / Re: raspberry pi, orange pi, etc
« 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!
3
Support / Re: raspberry pi, orange pi, etc
« 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
6
I'm getting, I think, to a crucial place. I believe that it's one of the following three variables. If you have any insight about what might be wrong that around line 544 in CompiledInstance the rendering block never clears the if (!useDL || (listID == 0 && !buffersCreated)) test (and, thus, never renders most objects) I would appreciate it. The following is the state of most every object in this forest scene.
Code: [Select]
if (useDL || (listID != 0 && buffersCreated))
System.Console.WriteLine("Not rendering "+obj.getName() +" because useDL: "+useDL +", listID: "+listID +", buffersCreated: "+buffersCreated);
Quote
Not rendering grassB628_jPCT438 because useDL: True, listID: 0, buffersCreated: True
7
I put a WriteLine on the following block inside CompiledInstance.render() and for every model, including the ones that didn't render, I get "...about to render."
Code: [Select]
if (!wireFrame) {
if (vertexAlpha) {
// Actually, this doesn't matter but anyway...
cols[3] = 1;
}
System.Console.WriteLine("CompiledInstance.render(): "+obj.getName() +" about to render.");
8
Update: the line thing (running my game by calling mono before the .exe) sometimes crashes the application and still fails to give you numbers. Here's where I am: I can compile(true) my main character. The Skybox, too, but it becomes semi-transparent. Nearly everything else disappears when compiled. Maybe the Skybox transparency is a hint, but I don't think so because the disappearing objects also don't show up as wireframes. It's as if jpct is either translating them far out of view or otherwise clipping them.
9
See, that's why people should talk to each other. I could have been stuck on this forever if you hadn't mentioned line numbers. By making the debug call "debug:embedded" I got the line numbers in. The problem had been that my Lights class was not initializing the distanceOverride array. Compiled objects are still not rendering, though, so off to find that issue (now aided by the line numbers).
10
Actually, I knew that. I also now know that the -debug option is not supported on Windows (or at least not Windows x64) for whatever reason. And every solution to line-number printing I find fails (one of them always prints line 0, another doesn't even compile on Mono). Fun.
12
The NullPointerException only says, "Object reference not set to an instance of an object." Very useful, so I printed both the stack and the following messages:
Quote
NullReference: at Object3D.render(Boolean software, Single mx, Single my, Single scalex, Single scaley, Single divx, Single divy, Boolean mayOptimize, Int32 tc, FrameBuffer buffer)
at WorldProcessor.processInternal(FrameBuffer buffer, List`1 objectList, Portals portals, Camera camera, Boolean software, Single mx, Single my, Boolean mayOptimize, Boolean hasToSort, Int32 start, Int32 end, Single camScaleX, Single camScaleY, Boolean gl)
at WorldProcessor.process(FrameBuffer buffer, List`1 objectList, Portals portals, Camera camera, Boolean software, Single mx, Single my, Boolean mayOptimize, Boolean hasToSort, Int32 start, Int32 end, Single camScaleX, Single camScaleY, Boolean gl)
at World.renderScene(FrameBuffer buffer)
Object3D.render(): compiled. Is visList null? False
Object3D.render(): compiled. Is visList null? False
[ 8/4/2021 3:25:24 AM ] - WARNING: World.renderScene(): There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of BR3D objects on a thread different from the rendering thread! Is camera null? False Is visList? False
13
On occasions whose particularities I've yet to identify, I can't get rid of the following message.
Also, only the Skybox renders when compiled...
Quote
WARNING: World.renderScene(): There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of BR3D objects on a thread different from the rendering thread! Is camera null? False Is visList? False
Also, only the Skybox renders when compiled...