- Welcome to LWJGL Forum.
Lightweight Java Game Library
Recent posts
#1
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by cpope9141 - Today at 01:48:13Combo Breaker Promo Video: https://youtu.be/F-Bfgg-1WN8?si=TEQKuDmTTqnWjGLS
#2
Lightweight Java Gaming Library / Re: Indie Fighting Game using ...
Last post by cpope9141 - Today at 01:44:13Area Zero will be in the Indie Developer area at Combo Breaker May 24-26: https://combobreaker.org/indie-devs-2024/
The May release (v0.13.0) is also available for download: https://ephemeraltechnicalarts.com/area-zero
0.13.0 (5/20/2024)
1. Iterate on Parking Garage (Day) art.
2. Grapple damage adjusted for Niven and Richard.
3. Character attributes exaggerated:
a. Richard's recovery rate reduced, while Violet and B.P.V.'s are increased.
b. B.P.V.'s guard capacity reduced from 950 to 900 (can be increased by taunting).
c. Richard's default walk velocities reduced (can be increased by taunting).
4. Preparing assets for Michael and Christopher debut.
0.12.5 (5/11/2024)
1. Improvements to stages (art) and fixes popping issue with foreground elements.
2. Allow super attack to cancel getting up (get up tutorial updated).
3. Add recovery to Violet's airborne projectile.
4. Adjustments to Richard's attacks:
a. Regular air lariat no longer launches, but keeps opponent grounded and staggered.
b. +2 frames of recovery added to EX running stomp.
c. Super attack total damage reduced from 570 to 510. Yes, it was OP.
5. Matches no longer starts with full super meter.
6. Updated tutorials, clarifying wording in objectives.
7. Polish throw animations and responses.
8. Polish various attack and response animations.
9. Reduce Richard's dashing/run velocities.
10.Increased damage to Victor's teleport attack.
11.Title screen revised.
12.Damage scaling introduced:
a. Violet and BPV's scaling begins on hit 17 of a combo
b. Victor and Niven's scaling begins on hit 11 of a combo.
c. Richard's scaling begins on hit 9 of a combo.
13.Red parry now requires that you tap either forward or down, depending on whether the incoming attack is
hitting high or low respectively.
0.12.0 (4/21/2024)
1. Improvements to Richard's animations
2. New stage added: Hemlock Road.
0.11.5 (4/14/2024)
1. Improved Niven attack and response animations.
2. Iteration on color palettes.
3. Updated move lists to show separate buttons for special (Sp) and super (Su).
4. Improved Richard special and super attack animations.
4. Adjustments to Richard:
a. A.HK no longer wall bounces the opponent.
b. Overreach now hits once; The EX version still hits twice, but with adjusted frame data.
0.11.0 (4/4/2024)
1. Collision, hit and hurt boxes adjusted for all characters.
2. Restored Parry. Now the player has the option to do a "red" parry (i.e. parry out of block stun)
3. Implemented armored special attack system. Now any special attack can be armored for the cost
of one additional (blue) meter.
4. Tutorial modes updated with objective for parry and armored specials.
5. In Training mode, dummy can be set to do super or special attack (grounded only for now).
6. Added new color palettes for all characters.
The May release (v0.13.0) is also available for download: https://ephemeraltechnicalarts.com/area-zero
0.13.0 (5/20/2024)
1. Iterate on Parking Garage (Day) art.
2. Grapple damage adjusted for Niven and Richard.
3. Character attributes exaggerated:
a. Richard's recovery rate reduced, while Violet and B.P.V.'s are increased.
b. B.P.V.'s guard capacity reduced from 950 to 900 (can be increased by taunting).
c. Richard's default walk velocities reduced (can be increased by taunting).
4. Preparing assets for Michael and Christopher debut.
0.12.5 (5/11/2024)
1. Improvements to stages (art) and fixes popping issue with foreground elements.
2. Allow super attack to cancel getting up (get up tutorial updated).
3. Add recovery to Violet's airborne projectile.
4. Adjustments to Richard's attacks:
a. Regular air lariat no longer launches, but keeps opponent grounded and staggered.
b. +2 frames of recovery added to EX running stomp.
c. Super attack total damage reduced from 570 to 510. Yes, it was OP.
5. Matches no longer starts with full super meter.
6. Updated tutorials, clarifying wording in objectives.
7. Polish throw animations and responses.
8. Polish various attack and response animations.
9. Reduce Richard's dashing/run velocities.
10.Increased damage to Victor's teleport attack.
11.Title screen revised.
12.Damage scaling introduced:
a. Violet and BPV's scaling begins on hit 17 of a combo
b. Victor and Niven's scaling begins on hit 11 of a combo.
c. Richard's scaling begins on hit 9 of a combo.
13.Red parry now requires that you tap either forward or down, depending on whether the incoming attack is
hitting high or low respectively.
0.12.0 (4/21/2024)
1. Improvements to Richard's animations
2. New stage added: Hemlock Road.
0.11.5 (4/14/2024)
1. Improved Niven attack and response animations.
2. Iteration on color palettes.
3. Updated move lists to show separate buttons for special (Sp) and super (Su).
4. Improved Richard special and super attack animations.
4. Adjustments to Richard:
a. A.HK no longer wall bounces the opponent.
b. Overreach now hits once; The EX version still hits twice, but with adjusted frame data.
0.11.0 (4/4/2024)
1. Collision, hit and hurt boxes adjusted for all characters.
2. Restored Parry. Now the player has the option to do a "red" parry (i.e. parry out of block stun)
3. Implemented armored special attack system. Now any special attack can be armored for the cost
of one additional (blue) meter.
4. Tutorial modes updated with objective for parry and armored specials.
5. In Training mode, dummy can be set to do super or special attack (grounded only for now).
6. Added new color palettes for all characters.
#3
OpenGL / How i can do shader things on ...
Last post by DispenserWater92 - May 15, 2024, 13:54:33context: i have a video on background that i wanna to apply shaders on (in another thread)
but im getting that error "No context is current or a function that is not available in the current context was called. The JVM will abort execution."
how can i fix errors?
but im getting that error "No context is current or a function that is not available in the current context was called. The JVM will abort execution."
how can i fix errors?
#4
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by spasi - May 13, 2024, 10:56:59MemoryStack is indeed very useful, but keep in mind that its default size is fairly small and usually not appropriate for vertex/index data (mentioned in the OP).
#5
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by kappa - May 13, 2024, 10:04:53Quote from: bonenaut7 on May 13, 2024, 02:11:24That's interesting, i was using MemoryStack only in try-with-resources blocks, but in example i provided in #1 post it looks like that's... unnecessary? There is callback when vertex buffer is built, BGFXMemory is no more required to stay and memory could be freed(and it happens exactly when at least a frame with some delay passed), is this callback bad in some way?Allocating native memory (especially in a game loop) is slow (regardless of language). The advantage with the above MemoryStack method is that you just allocate a chunk of memory at initialisation and then reuse it continuously in the game loop.
#6
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by bonenaut7 - May 13, 2024, 02:11:24Quote from: spasi on May 12, 2024, 09:39:10The Java-side buffer object that wraps a native pointer is reclaimed as usual by the GC, when there are no longer any references pointing to it.Oh, got it, thanks!
I will try also debugging my app, I didn't knew about debugging features at all
Quote from: kappa on May 12, 2024, 05:47:35One potential solution for frame data which changes every frame (e.g. immediate mode 2d graphics made up of many small allocations) is to use LWJGL's MemoryStack, just push all your data in there and pop (release) it after 2 frames. e.g. Use 3 MemoryStack's (one for current frame data and two holding data for the previous two frames) and just cycle through the MemoryStack's.
That's interesting, i was using MemoryStack only in try-with-resources blocks, but in example i provided in #1 post it looks like that's... unnecessary? There is callback when vertex buffer is built, BGFXMemory is no more required to stay and memory could be freed(and it happens exactly when at least a frame with some delay passed), is this callback bad in some way?
#7
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by spasi - May 12, 2024, 09:39:10Hey bonenaut7,
There is no easy way to find out whether a pointer has been freed or not. LWJGL does not track this information in its default state (it's too expensive) and indeed nothing happens to buffer wrapper objects when a pointer is freed. Note that this is no different than pure C code, the developer is responsible for tracking pointer lifetimes accurately and avoiding use-after-free bugs. The Java-side buffer object that wraps a native pointer is reclaimed as usual by the GC, when there are no longer any references pointing to it.
LWJGL provides
There is no easy way to find out whether a pointer has been freed or not. LWJGL does not track this information in its default state (it's too expensive) and indeed nothing happens to buffer wrapper objects when a pointer is freed. Note that this is no different than pure C code, the developer is responsible for tracking pointer lifetimes accurately and avoiding use-after-free bugs. The Java-side buffer object that wraps a native pointer is reclaimed as usual by the GC, when there are no longer any references pointing to it.
LWJGL provides
Configuration.DEBUG_MEMORY_ALLOCATOR.set(true); (or -Dorg.lwjgl.util.DebugAllocator=true) which enables tracking and memory leak reporting for any native allocation that goes through MemoryUtil's memory allocator (see Configuration.MEMORY_ALLOCATOR). As I mentioned, this tracking may introduce a lot of overhead, depending on the application (a stacktrace is captured on every allocation, which can optionally be disabled with Configuration.DEBUG_MEMORY_ALLOCATOR_FAST). But it can accurately report memory leaks and you can also use it to print memory usage statistics at runtime. #8
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by kappa - May 12, 2024, 05:47:35As per the BGFX docs, Data passed (to BGFX) must be available for at least 2 bgfx_frame calls.
So just free memory manually after 2 frame calls of not needing it rather than tracking when BGFX has freed it. This can be a bit cumbersome for data which changes every frame.
One potential solution for frame data which changes every frame (e.g. immediate mode 2d graphics made up of many small allocations) is to use LWJGL's MemoryStack, just push all your data in there and pop (release) it after 2 frames. e.g. Use 3 MemoryStack's (one for current frame data and two holding data for the previous two frames) and just cycle through the MemoryStack's.
If you are not familiar with LWJGL's MemoryStack, there is a good write up here on how to use them.
So just free memory manually after 2 frame calls of not needing it rather than tracking when BGFX has freed it. This can be a bit cumbersome for data which changes every frame.
One potential solution for frame data which changes every frame (e.g. immediate mode 2d graphics made up of many small allocations) is to use LWJGL's MemoryStack, just push all your data in there and pop (release) it after 2 frames. e.g. Use 3 MemoryStack's (one for current frame data and two holding data for the previous two frames) and just cycle through the MemoryStack's.
If you are not familiar with LWJGL's MemoryStack, there is a good write up here on how to use them.
#9
Lightweight Java Gaming Library / Re: BGFX Bindings / How to kno...
Last post by bonenaut7 - May 12, 2024, 02:27:27Whole thing looks like this:
So will be in this situation buffer cleared by GC, and how can i check is it freed or not except for using Unsafe in case if there's any other possibilities?
Will be glad for any help, thanks!
short vertexLayout = /* pre-made vertex layout with only 3-unit position attribute */;
ByteBuffer vertexData = MemoryUtil.memAlloc(Float.BYTES * 3);
/* filling vertexData with [1, 2, 3] */
vertexData.flip();
BGFXReleaseFunctionCallbackI callback = (_ptr, _userData) -> {
System.out.println("callback called");
MemoryUtil.nmemFree(_ptr);
};
BGFXMemory memoryRef = bgfx_make_ref_release(vertexData, callback, 0);
short vertexBuffer = bgfx_create_vertex_buffer(memoryRef, vertexLayout, BGFX_BUFFER_NONE);
bgfx_frame(false);
Thread.sleep(250L); // Because vertex buffer is not created immidiately at bgfx_frame(...)
// Here we can see on console "callback called" from callback, so MemoryUtil.nmemFree(vertexData.address) is called
// I'm compared what's came to the _ptr in callback as a parameter and which address buffer had, they're was equal
// Here we can do anything with buffer because it's address field is untouched
// But memory is freed and i don't know vertexBuffer will be cleared by GC or not (that's question too)
// And how do i check is it freed or not? except for using Unsafe by myself for checking and setting address to zero
So will be in this situation buffer cleared by GC, and how can i check is it freed or not except for using Unsafe in case if there's any other possibilities?
Will be glad for any help, thanks!
#10
Lightweight Java Gaming Library / BGFX Bindings / How to know is...
Last post by bonenaut7 - May 12, 2024, 02:15:44Hello! I'm learning how to use bgfx now and currently stumbled upon vertex buffer creation process.
BGFX has by default some function called
How i can find out buffer i'm used to create
BGFX has by default some function called
bgfx_make_ref_release that i can use to get BGFXMemory and i have problem with this. When i'm using this method, memory reference should be destroyed after some time (at least a single BGFX.bgfx_frame call, and a few milliseconds to process commands), so after waiting, native(i guess) side calls BGFXReleaseFunctionCallbackI#invoke method, where i should by logic use something like MemoryUtil.nmemFree(_ptr) (took this from examples) to free this reference, which points on the ByteBuffer and it's Buffer#address that i used to create this reference. But there's a thing, i don't know is it freed or not, because MemoryUtil#nmemFree nor MemoryUtil#memFree are setting anything to a buffer (for example Buffer#address field to 0).How i can find out buffer i'm used to create
BGFXMemory is freed or not? I'm noticed that even after buffer's memory address being freed, i still can use that buffer and this whole thing kinda scares me