Main Menu

Recent posts

#21
OpenGL / Re: 3d texture sampling as bla...
Last post by sephjfox - May 29, 2024, 02:18:14
Hello all  ;D  I have found the solution to my problem. Hopefully it will help someone else in their journey.

These are the changes I made to get it working. Essentially I declare the array slightly differently and specify a different datatype:

// Java
int t3dim = 64;
int[] tex3d_r = new int[t3dim*t3dim*t3dim*4];
int r,g,b,a,color;
for(int i=0;i<(t3dim*t3dim*t3dim);i++) {
    r = (int)(Mati.fRand_static()*255.0f);
    g = (int)(Mati.fRand_static()*255.0f);
    b = (int)(Mati.fRand_static()*255.0f);
    a = (int)(Mati.fRand_static()*255.0f);
    color = (a << 24) | (r << 16) | (g << 8) | b;
    tex3d_r[i]=color;
}

glTexImage3D(GL_TEXTURE_3D, 0, GL30.GL_RGBA, t3dim , t3dim , t3dim , 0, GL30.GL_RGBA, GL_UNSIGNED_BYTE, tex3d_r);

And the debug shader where I can browse the layers of the 3d texture by altering dbg_val1 between 0 and 1:

// GLSL
if(volumeMode>0) {
    pixel = texture(volumeMap, vec3(uvs_vs0.xy,dbg_val1));
    return;
}



Enjoy, and happy coding  :)
#23
Area 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. 
#24
OpenGL / How i can do shader things on ...
Last post by DispenserWater92 - May 15, 2024, 13:54:33
context: 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?
#25
MemoryStack 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).
#26
Quote 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.
#27
Quote 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 :o

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?
#28
Hey 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 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.
#29
As 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.
#30
Whole thing looks like this:
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!