Recent posts

#1
OpenGL / imageLoad() not giving the exp...
Last post by Graph3r - July 05, 2024, 01:35:10
I made a compute shader that would use the depth buffer texture as a input for post processing, the imageLoad() returns a vec4, but the image only has one channel. I first tried to just write imageLoad(depthImage, gid).r but nothing happened, I tried going through r, g, b and a channels too, but it wouldn't work either. When using a vertex and fragment shader to render the depth texture as a quad, it worked and displayed the depth as a grayscale. Why doesn't the imageLoad do anything, here is parts of the code if it helps:
// Setup
depthTexture = glGenTextures();
glBindTexture(GL_TEXTURE_2D, depthTexture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT32F, width, height, 0, GL_DEPTH_COMPONENT, GL_FLOAT, (FloatBuffer) null);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, depthTexture, 0);
computeProgram = ShaderProgram.fromFiles("src\\game\\test.compute", "offscreenrenderer", 0);
quad = new FullscreenQuad();
computeProgram.use();
glBindImageTexture(0, renderedTexture, 0, false, 0, GL_READ_ONLY, GL_RGBA32F);
glBindImageTexture(1, depthTexture, 0, false, 0, GL_READ_ONLY, GL_R32F);
glBindImageTexture(2, processedTexture, 0, false, 0, GL_WRITE_ONLY, GL_RGBA32F);
computeProgram.unuse();

// Methods in the code for starting the rendering and for doing the post processing:
public void start() {
    glBindFramebuffer(GL_FRAMEBUFFER, frameBuffer);
    //glBindRenderbuffer(GL_RENDERBUFFER, depthBuffer);
    glViewport(0, 0, width, height);
}

public void runPostProcess() {
    computeProgram.use();
    glDispatchCompute((int) Math.ceil(width / 16.0), (int) Math.ceil(height / 16.0), 1);
    glMemoryBarrier(GL_SHADER_IMAGE_ACCESS_BARRIER_BIT);
    computeProgram.unuse();

    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    glClear(GL_COLOR_BUFFER_BIT);
    quad.setTexture(processedTexture);
    quad.render();
}
Simple debugging in the compute shader:
#version 430
layout(local_size_x = 16, local_size_y = 16) in;

layout(binding = 0, rgba32f) uniform image2D inputImage; // Works
layout(binding = 1, r32f) uniform image2D depthImage; // Doesn't work
layout(binding = 2, rgba32f) uniform image2D outputImage; // Works

void main() {
    ivec2 pos = ivec2(gl_GlobalInvocationID.xy);
    imageStore(outputImage, pos, imageLoad(depthImage, pos));
}
#2
OpenGL / OpenGl ARB_base_instance exten...
Last post by Graou - June 20, 2024, 09:37:27
Hi,
I would have liked to use the services of the ARB_base_instance extension but there are some symptoms which make me believe that it is not supported.
I was able to see this directly in runtime or by querying the list of supported extensions.
Is it a desire specific to LWJGL to ignore this extension, an implementation still to be done or a potential problem on the side of my environment?
The LWJGL versions I tested are 3.3.2 to 3.3.3+5 and the OpenGl version is 4.1 ATI-4.14.1.
#3
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  :)
#5
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. 
#6
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?
#7
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).
#8
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.
#9
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?
#10
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.