- Welcome to LWJGL Forum.
Lightweight Java Game Library
Recent posts
#31
Lightweight Java Gaming Library / Re: Is it correct to be explic...
Last post by Richtea - November 22, 2023, 19:23:47Ha, and in that version there is a memory bug fix https://github.com/LWJGL/lwjgl3/commit/9a997a2143e565b83a9bf760e57fcb141856c413 changing the create to a calloc.
So that all makes sense then, I've just been looking at an old version of that demo. Thanks!
So that all makes sense then, I've just been looking at an old version of that demo. Thanks!
#32
Lightweight Java Gaming Library / Re: Is it correct to be explic...
Last post by spasi - November 22, 2023, 12:44:21I was referring to the same demo that was contributed to LWJGL, here: https://github.com/LWJGL/lwjgl3/blob/master/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java. It's slightly different, not sure which version is more recent.
#33
Lightweight Java Gaming Library / Re: Is it correct to be explic...
Last post by Richtea - November 22, 2023, 12:39:29QuoteYes, that is correct. Memory allocated with .create(), that delegates to BufferUtils -> ByteBuffer.allocateDirect, should not be freed explicitly.
Thanks, I'm glad my understanding is correct
QuoteNote that the LWJGL demo uses calloc for swapchainImageBuffer.
Does it? I was looking at https://github.com/knokko/lwjgl3/blob/origin/fix-xr-gl-sample/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java#L452 where it seems to be created. Is that the right demo I'm looking at? (Its so hard with github repos to know which is the official one)
#34
Lightweight Java Gaming Library / Re: Is it correct to be explic...
Last post by spasi - November 22, 2023, 10:09:17Hey Richtea,
Yes, that is correct. Memory allocated with .create(), that delegates to BufferUtils -> ByteBuffer.allocateDirect, should not be freed explicitly. Note that the LWJGL demo uses calloc for swapchainImageBuffer.
For memory allocation troubleshooting, you may run the application with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugAllocator=true. It will report issues like freeing of GC-managed memory, double-freeing, memory leaks on process exit.
Yes, that is correct. Memory allocated with .create(), that delegates to BufferUtils -> ByteBuffer.allocateDirect, should not be freed explicitly. Note that the LWJGL demo uses calloc for swapchainImageBuffer.
For memory allocation troubleshooting, you may run the application with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugAllocator=true. It will report issues like freeing of GC-managed memory, double-freeing, memory leaks on process exit.
#35
Lightweight Java Gaming Library / Is it correct to be explicitly...
Last post by Richtea - November 21, 2023, 21:45:15In my own application I'm using LWJGL to bind to OpenXR. I originally following this example to create my application
https://github.com/knokko/lwjgl3/blob/origin/fix-xr-gl-sample/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java
My application works well on my machine, and well on an end users machine except that it hard crashes on exit
I've historically got those sorts of things when I've explicitly called free() on objects created like `XrSessionActionSetsAttachInfo.create();`. I never call free on these objects and (hopefully correctly?) believe that these are automatically freed by LWJGL.
Which brings me to the application exiting and the example. The only frees I have in my example are on application shutdown and I include them because the HelloOpenXRGL example does
I think the first 3 frees are correct (as the memory was originally allocated with `calloc`)
But the swap chain images are created with a `create`
Would I be correct in saying if it's created with a `create` it is managed memory and shouldn't be manually freed?
https://github.com/knokko/lwjgl3/blob/origin/fix-xr-gl-sample/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java
My application works well on my machine, and well on an end users machine except that it hard crashes on exit
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f36a18dacc0, pid=94325, tid=94345
#
# JRE version: OpenJDK Runtime Environment (17.0.7+7) (build 17.0.7+7-Debian-1deb11u1)
# Java VM: OpenJDK 64-Bit Server VM (17.0.7+7-Debian-1deb11u1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0xa3cc0]
I've historically got those sorts of things when I've explicitly called free() on objects created like `XrSessionActionSetsAttachInfo.create();`. I never call free on these objects and (hopefully correctly?) believe that these are automatically freed by LWJGL.
Which brings me to the application exiting and the example. The only frees I have in my example are on application shutdown and I include them because the HelloOpenXRGL example does
helloOpenXR.eventDataBuffer.free();
helloOpenXR.views.free();
helloOpenXR.viewConfigs.free();
for (Swapchain swapchain : helloOpenXR.swapchains) {
xrDestroySwapchain(swapchain.handle);
swapchain.images.free();
}
I think the first 3 frees are correct (as the memory was originally allocated with `calloc`)
But the swap chain images are created with a `create`
XrSwapchainImageOpenGLKHR.Buffer swapchainImageBuffer = XrUtils.fill(
XrSwapchainImageOpenGLKHR.create(imageCount),
XrSwapchainImageOpenGLKHR.TYPE,
KHROpenGLEnable.XR_TYPE_SWAPCHAIN_IMAGE_OPENGL_KHR
);
Would I be correct in saying if it's created with a `create` it is managed memory and shouldn't be manually freed?
#36
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by cpope9141 - November 20, 2023, 18:48:42Quote from: Adro on November 03, 2023, 17:02:04
I encourage you to publish it on TIGsource Playtesting forum if you haven't already done it, so that you receive more feedback. I see you have a webpage. I can confirm you I now admire your work.
Thanks for the heads up! I posted in the forum requesting feedback.
#37
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by cpope9141 - November 20, 2023, 18:32:12The November release of Area Zero (v.0.6.0) is now available for download from www.ephemeraltechnicalarts.com!
Release Notes:
0.6.0 (11/19/2023)
- Niven given unique sound assets
- Iteration on art assets for Richard and Niven
- Added announcer sound assets for Richard and Niven on character select screen
- Fixed bug where a knockout with Richard's super could leave opponent suspended in air.
- Rework menus to detect raw controller inputs (A/B, cross/circle, etc.) so if controller binding changes,
menu input handling is unaffected.
- Controller layout changed:
- 6 buttons (LP, MP, HP, LK, MK, HK) reduced to 4 buttons (LP, HP, LK, HK) with command normals
(i.e. direction plus button).
- Special attacks are now activated with a single button (referred to from here on as S), reduced from (HP + HK).
- EX Special attacks are now activated by (S + HP).
- Super attacks are now activated by (S + HP + LP).
- Sweep attacks, and their response actions have been removed for now.
- Controller binding menu now accessed through pause menu in either versus or training mode.
- Controller binding edits disallowed when keyboard is the input device
(i.e. can only change button binding of controllers).
Release Notes:
0.6.0 (11/19/2023)
- Niven given unique sound assets
- Iteration on art assets for Richard and Niven
- Added announcer sound assets for Richard and Niven on character select screen
- Fixed bug where a knockout with Richard's super could leave opponent suspended in air.
- Rework menus to detect raw controller inputs (A/B, cross/circle, etc.) so if controller binding changes,
menu input handling is unaffected.
- Controller layout changed:
- 6 buttons (LP, MP, HP, LK, MK, HK) reduced to 4 buttons (LP, HP, LK, HK) with command normals
(i.e. direction plus button).
- Special attacks are now activated with a single button (referred to from here on as S), reduced from (HP + HK).
- EX Special attacks are now activated by (S + HP).
- Super attacks are now activated by (S + HP + LP).
- Sweep attacks, and their response actions have been removed for now.
- Controller binding menu now accessed through pause menu in either versus or training mode.
- Controller binding edits disallowed when keyboard is the input device
(i.e. can only change button binding of controllers).
#38
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by cpope9141 - November 20, 2023, 18:30:01Quote from: Adro on November 03, 2023, 17:02:04
Don't worry too much at first with the distribution. In fact, I think it its well distributed. I didn't expect an extractor, but it makes the game easy to begin (is it also made with Launch4j?). Maybe there's another work-around: an installer. I've never achieved nor the former nor the latter. I cannot give you any advise because me (and I think many others) have faced similar distribution problems. In my case, what I usually do is to pack libraries and natives on JAR building. Then with Launch4j I pack it into an EXE file and then on the same folder I put every other resources. I couldn't find a way to also pack the JRE with Launch4j. I've seen you packed the JDK. Couldn't it be sufficient with the JRE? I think this is a contiuum problem for almost every people that works with Java and even more if we are working with natives... By the way, since you talked about Mac, the distribution problem gets even bigger on the window system from GLFW. That's another pending task for almost everyone that works with LWJGL.
Thank you for taking the time to download the game and provide in depth feedback! I am grateful.
For distribution, I am using Launch4j to create a wrapper, then 7-Zip SFX Maker to extract and run. The EXE is not signed, which will probably frighten away potential players with false positive virus threats.
I plan to continue development over the next year to see how far I can take it. Thank you again for playing!
#39
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by Adro - November 03, 2023, 17:02:04Hi CPOPE9141!
Your game looked great to me from the pictures. Once I've played it, I can confirm it's so good: the art, controls, animations, sound. You could improve some of the animated frames, but other than that, I can say this is one of the most impressive game projects on LWJGL I've known.
See, almost everyone is trying to do 3D stuff and from-scratch-renderers without focusing too much on the game itself. I don't personally think that is a bad idea. On the contrary, it's beautiful. However, people seem to loose the real focus: the fun of a game and all the feelings it can give you. I think your game precisely combines these two aspects so great. I mean, this is done from scratch, only with the aid of the LWJGL libraries. This must required from you a lot of time, and that is great because you learned a lot. One could think this is another experimental project, and while that possibly true, that is the essence of the indie game development: to create whatever is in your mind. However, that doesn't mean everyone must focus on the renderer part for instance, because that could be discouraging. But the fact you did it in that way, it automatically gives it more value, because it reflects passion on it. I say this precisely because there are some people saying "ah ok you did this with no engine. Then you've lost a lot of time".
At first I couldn't play it. "Couldn't create Vulkan instance". Clearly that computer didn't support Vulkan (it has 8 years of existence haha). Finally, I managed to play it. It achieves that good fighting vibes, like the ones from Street Fighter. I also value the fact that the animated models give it the feel of depth, kind of what isometric games do.
Don't worry too much at first with the distribution. In fact, I think it its well distributed. I didn't expect an extractor, but it makes the game easy to begin (is it also made with Launch4j?). Maybe there's another work-around: an installer. I've never achieved nor the former nor the latter. I cannot give you any advise because me (and I think many others) have faced similar distribution problems. In my case, what I usually do is to pack libraries and natives on JAR building. Then with Launch4j I pack it into an EXE file and then on the same folder I put every other resources. I couldn't find a way to also pack the JRE with Launch4j. I've seen you packed the JDK. Couldn't it be sufficient with the JRE? I think this is a contiuum problem for almost every people that works with Java and even more if we are working with natives... By the way, since you talked about Mac, the distribution problem gets even bigger on the window system from GLFW. That's another pending task for almost everyone that works with LWJGL.
In sum, your game is a(n) (impressive) game, not only some graphics testing. It is complex, since it uses Vulkan and I understood no library was used for physics other than JOML. At the same time it's simplified in a smooth and fun gameplay, that is, it combines those two areas usually hard to master: the technical/graphics/sound (engine) part and the game itself, to the extent it is even original on the former given the animated graphics.
I encourage you to publish it on TIGsource Playtesting forum if you haven't already done it, so that you receive more feedback. I see you have a webpage. I can confirm you I now admire your work.
Your game looked great to me from the pictures. Once I've played it, I can confirm it's so good: the art, controls, animations, sound. You could improve some of the animated frames, but other than that, I can say this is one of the most impressive game projects on LWJGL I've known.
See, almost everyone is trying to do 3D stuff and from-scratch-renderers without focusing too much on the game itself. I don't personally think that is a bad idea. On the contrary, it's beautiful. However, people seem to loose the real focus: the fun of a game and all the feelings it can give you. I think your game precisely combines these two aspects so great. I mean, this is done from scratch, only with the aid of the LWJGL libraries. This must required from you a lot of time, and that is great because you learned a lot. One could think this is another experimental project, and while that possibly true, that is the essence of the indie game development: to create whatever is in your mind. However, that doesn't mean everyone must focus on the renderer part for instance, because that could be discouraging. But the fact you did it in that way, it automatically gives it more value, because it reflects passion on it. I say this precisely because there are some people saying "ah ok you did this with no engine. Then you've lost a lot of time".
At first I couldn't play it. "Couldn't create Vulkan instance". Clearly that computer didn't support Vulkan (it has 8 years of existence haha). Finally, I managed to play it. It achieves that good fighting vibes, like the ones from Street Fighter. I also value the fact that the animated models give it the feel of depth, kind of what isometric games do.
Don't worry too much at first with the distribution. In fact, I think it its well distributed. I didn't expect an extractor, but it makes the game easy to begin (is it also made with Launch4j?). Maybe there's another work-around: an installer. I've never achieved nor the former nor the latter. I cannot give you any advise because me (and I think many others) have faced similar distribution problems. In my case, what I usually do is to pack libraries and natives on JAR building. Then with Launch4j I pack it into an EXE file and then on the same folder I put every other resources. I couldn't find a way to also pack the JRE with Launch4j. I've seen you packed the JDK. Couldn't it be sufficient with the JRE? I think this is a contiuum problem for almost every people that works with Java and even more if we are working with natives... By the way, since you talked about Mac, the distribution problem gets even bigger on the window system from GLFW. That's another pending task for almost everyone that works with LWJGL.
In sum, your game is a(n) (impressive) game, not only some graphics testing. It is complex, since it uses Vulkan and I understood no library was used for physics other than JOML. At the same time it's simplified in a smooth and fun gameplay, that is, it combines those two areas usually hard to master: the technical/graphics/sound (engine) part and the game itself, to the extent it is even original on the former given the animated graphics.
I encourage you to publish it on TIGsource Playtesting forum if you haven't already done it, so that you receive more feedback. I see you have a webpage. I can confirm you I now admire your work.
#40
Vulkan / Re: Logical device creation pr...
Last post by GhCa - November 03, 2023, 00:31:06Well, I have resolved it. 
The reason is that I use FloatBuffer.allocate() to create a FloatBuffer, but this method only can create HeapBuffer based on JVM.
On jdk8, MemoryUtil.memAddress(Buffer) will return 0(nullptr) with a non-direct buffer which can be caught by Check() and throw a NullPointerException, but on jdk11 or later, it will return a address based on JVM which will be recognized as a wild pointer when transfer to JNI, then the wild pointer causes a fatal error in native.
The reason is that I use FloatBuffer.allocate() to create a FloatBuffer, but this method only can create HeapBuffer based on JVM.
On jdk8, MemoryUtil.memAddress(Buffer) will return 0(nullptr) with a non-direct buffer which can be caught by Check() and throw a NullPointerException, but on jdk11 or later, it will return a address based on JVM which will be recognized as a wild pointer when transfer to JNI, then the wild pointer causes a fatal error in native.