Hello Guest

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Bug Reports / RFE / Re: [BUG] glfwDestroyWindow EXCEPTION_ACCESS_VIOLATION
« Last post by jakethesnake on August 20, 2019, 14:00:00 »
It would be difficult to make a minimized example since I can't recreate the original bug as well.

I tried running the java agent and it didn't print anything for me except for all the available extensions. Instead it created JVM crash upon exiting the app!

Code: [Select]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.system.dyncall.DynCallback.ndcbGetUserData(J)J+0
j  org.lwjgl.system.dyncall.DynCallback.dcbGetUserData(J)J+12
j  org.lwjgl.system.Callback.free(J)V+1
j  org.lwjgl.system.Callback.free()V+4
j  org.lwjglx.debug.glfw.GLFW.glfwTerminate()V+42
j  org.lwjglx.debug.$Proxy$35.glfwTerminate26()V+10
j  snake2d.GraphicContext.dis()V+45
j  snake2d.CORE.dispose()V+98
j  snake2d.CORE.start(Lsnake2d/CORE_STATE$Constructor;)V+574
j  launcher.Launcher.start()Z+36
j  main.Syx.main([Ljava/lang/String;)V+86
v  ~StubRoutines::call_stub

Something fishy is going on with the callbacks, mock my words!

After init I've got the following callbacks setup in this order:

Code: [Select]
GLFWErrorCallback.createPrint(System.err).set();
Code: [Select]
glCallback = GlDebugger.setupDebugMessageCallback();
Code: [Select]
callbackKey = new GLFWKeyCallback() {

@Override
public void invoke(long window, int key, int scancode, int action, int mods) {
if (key >= 0 && key < keymap.length && keymap[key] != null){
if (key == KEYCODE.PRINT_SCREEN.CODE){
if (action == 1)
w.takeScreenShot();
return;
}
keys[keysI] = key;
keys[keysI+1] = action;
keysI += 2;
}

}
};

GLFW.glfwSetKeyCallback(w.getWindow(), callbackKey);

charCallback = new GLFWCharCallback() {
@Override
public void invoke(long window, int codepoint) {

chars[charsI] = (char) codepoint;
charsI ++;

}
};

glfwSetCharCallback(w.getWindow(), charCallback);
Code: [Select]
callbackMouse = new GLFWMouseButtonCallback() {
@Override
public void invoke(long window, int button, int action, int mods) {

if (button > 2){
return;
}
if (MButt.ALL.get(button).isDown = action == GLFW.GLFW_PRESS){

long nanoOld = MButt.ALL.get(button).nanoNow;
MButt.ALL.get(button).nanoNow = Input.nanoNow;

if (Input.nanoNow - nanoOld < 250000000 && clickCurrent < clickMax){
clicks[clickCurrent++] = MButt.ALL.get(button + 3);
}
if (clickCurrent < clickMax)
clicks[clickCurrent++] = MButt.ALL.get(button);
}

}
};
glfwSetMouseButtonCallback(window, callbackMouse);

sCallback = new GLFWScrollCallback() {

@Override
public void invoke(long window, double xoffset, double yoffset) {
MButt.wheelDy = (float) yoffset;
if (clickCurrent < clickMax)
clicks[clickCurrent] = MButt.WHEEL_SPIN;

}
};
glfwSetScrollCallback(window, sCallback);

I then dispose the context in this order:

Code: [Select]
glfwSetErrorCallback(null).free();

glCallback.free();
GL.setCapabilities(null);
Callbacks.glfwFreeCallbacks(window);
glfwDestroyWindow(window);
glfwTerminate();

if I remove Callbacks.glfwFreeCallbacks(window) and dispose the keyboard/mouse callbacks manually by: callback.close() the crash vanishes.

Any ideas?
22
OpenGL / Re: Difference of glBufferData between C++ and Java?
« Last post by darkyellow on August 20, 2019, 13:01:23 »
You are seeing differences between the two because they are solutions to two different ways of storing data in vertex buffers, one stores two sets of data in one buffer (c++) and the other has multiple buffers for each vertex buffer type (java). There is no reason why you couldn't code up the c++ solution in java nor the Java solution in c++.

Here is a useful post on java-gaming.org which shows many ways to draw vertex data

http://www.java-gaming.org/topics/introduction-to-vertex-arrays-and-vertex-buffer-objects-opengl/24272/view.html

23
Bug Reports / RFE / Re: [BUG] glfwDestroyWindow EXCEPTION_ACCESS_VIOLATION
« Last post by spasi on August 20, 2019, 09:38:15 »
The code glfwSetErrorCallback(null).free() is shortcut for:

Code: [Select]
GLFWErrorCallback previousErrorCallback = glfwSetErrorCallback(null);
previousErrorCallback.free();

If no error callback was set, you'd get an NPE here, not a crash. If you're getting a crash, it likely means you have already freed the error callback.

The glfwDestroyWindow crash also sounds like a double-free bug. But there's no way to tell without source access and decompilation can only get you so far (also time-consuming and painful). The best approach is to prepare an MCVE for us to have a look at. You'll probably figure out the problem before you post it though.

Btw, when debugging GLFW/OpenGL applications, it's always a good idea to use LWJGLX/debug. It will report any obvious errors in your code.
24
Bug Reports / RFE / Re: [BUG] glfwDestroyWindow EXCEPTION_ACCESS_VIOLATION
« Last post by jakethesnake on August 20, 2019, 06:26:14 »
I did some experiments after looking at the "getting started example". I added glfwSetErrorCallback(null).free(); in my disposal method and I got a hard JVM crash on this call. Removing all callback.close() calls prior to this (keyboard, mouse) fixed that crash. I don't know if this is related.

I'd really appreciate some help with this, even if it's just thoughts. I'm clueless on where to look. I've tried running all logic in the same thread and it makes no difference to me. OpenAl couldn't possibly mess things up? That's supposed to be thread safe from the docs.

I'll try packaging the get started guide and have the bug-reporter run that, see if it could be a lwjgl problem.
25
OpenGL / Difference of glBufferData between C++ and Java?
« Last post by j9263178 on August 20, 2019, 04:09:11 »
In order to make a 2D RPG game using LWGJL,I am learning OpenGL from the book :
「OpenGL Programming Guide: The Official Guide to Learning OpenGL」
This book use C++ code as Examples , here are some context from the book about  glBufferData :


Suppose you have an array containing some vertex data, another containing some color information,
 and yet another containing texture coordinates or some other data.
You’d like to pack the data back to back into one big buffer object so that OpenGL can use it.
The arrays may or may not be contiguous in memory, so you can’t use glBufferData() to upload all of it in one go.
Further, if you use glBufferData() to upload, say, the vertex data first,
then the buffer will be sized to exactly match the vertex data and there won’t be room for the color or texture coordinate information.
That’s where glBufferSubData() comes in.


then they showed me an examples about making use of glBufferData and glBufferSubData, the following are the part that I think is important

glGenBuffers(1, &buffer);
glBindBuffer(GL_ARRAY_BUFFER, buffer);
glBufferData(GL_ARRAY_BUFFER,sizeof(positions) + sizeof(colors),NULL,GL_STATIC_DRAW);
glBufferSubData(GL_ARRAY_BUFFER, 0,sizeof(positions),  positions);
glBufferSubData(GL_ARRAY_BUFFER,sizeof(positions), sizeof(colors), colors);

and I notice the parameters are a little bit of different to that in Java,
please take look at part my code of VBO (which actually comes from a youtube tutorial) :


v_id=glGenBuffers();   //for vertices
glBindBuffer(GL_ARRAY_BUFFER, v_id);
glBufferData(GL_ARRAY_BUFFER, createBuffer(vertices), .GL_STATIC_DRAW);
t_id=glGenBuffers();   //for textures
glBindBuffer(GL15.GL_ARRAY_BUFFER, t_id);
glBufferData(GL15.GL_ARRAY_BUFFER, createBuffer(tex_coords), GL_STATIC_DRAW);       
glBindBuffer(GL15.GL_ARRAY_BUFFER, 0);

So in Java we didn't give the size and offset and just simply bind a new buffer object ,
 it seems like the 「size problem」didn't appear here as the book mentioned ,
and I don't see the benefits of using glBufferSubData,
Are these two different situation  or  just different approaches to deal with drawing  vertices,texture,color...etc. ?
I am so confused.
26
Bug Reports / RFE / [BUG] glfwDestroyWindow EXCEPTION_ACCESS_VIOLATION
« Last post by jakethesnake on August 18, 2019, 18:52:09 »
Hello again!

I'm having a strange problem with my distributed app on a certain setup.

I can't reproduce it and have only had one report of the issue.

It's a hard JVM crash, and I'm no expert at reading these logs, but from what I gather glfwDestroyWindow is causing it.

I've read all of the threads regarding such issues http://forum.lwjgl.org/index.php?topic=5566.0 and multi-threading seems to be a viable culprit and I'm not ruling that out, it just seems unlikely.

The app initializes and renders normally. It is only when the user exits that the app crashes, every time.

Attached is the error log + LWJGL output. I don't know if they are of any help.
The app is here: https://songsofsyx.itch.io/songs-of-syx

I'm not calling glfwDestroyWindow twice, I know that.
I'm 99% certain I'm not doing opengl calls from any other than the main thread. 


Code: [Select]
public static abstract class GlJob{
protected abstract void doJob();

public final void perform() {
if (Thread.currentThread() == glThread && !swapping)
doJob();
else{
glJob = this;
while(glJob != null) //the glThread busy polls this variable and nulls it when complete.
sleep(1);
}
}

}


Code: [Select]
void dis() {

glfwSetErrorCallback(null).free();
if (renderer != null)
renderer.dis();
GlHelper.checkErrors();
gl.dispose();
glfwDestroyWindow(window);
glfwTerminate();


Printer.ln(GraphicContext.class + " was sucessfully destroyed");
}
27
I am trying to load a png file with stbi_load_from_memory, it returns bytebuffer that is not null but failure_reason is corrupt jpeg. What I am doing wrong? This is my code:
Code: [Select]
STBImage.stbi_set_flip_vertically_on_load(true);
byte[] encoded = file.readAllBytes();
ByteBuffer encodedBuffer = BufferUtils.createByteBuffer(encoded.length);
encodedBuffer.put(encoded);
encodedBuffer.flip();
ByteBuffer byteBuffer = STBImage.stbi_load_from_memory(encodedBuffer, width, height, bpp, 4);
file.readAllBytes() is correct I tested it.

It happens when loading from file stbi_load too.
28
OpenGL / Re: Attaching Keylistener to GLCanvas does not work
« Last post by Orly on August 17, 2019, 08:42:41 »
Found out the problem. When I call Display.update(), I must add the false argument -> Display.update(false), so that it doesn't trigger the lwjgl's Keyboard and Mouse classes (or something like that). basically, if you don't use false, lwjgl steals the input from the keylistener to give it to the Keyboard and Mouse class
29
OpenGL / Re: Attaching Keylistener to GLCanvas does not work
« Last post by Orly on August 15, 2019, 12:06:27 »
Now you seem to be mixing JOGL and LWJGL together. Can you please show the import statements of this code snippet?
Done, I just edited the post

Meanwhile, I also tryed switching from GLCanvas to a normal java Canvas, but it's still not working
30
OpenGL / Re: Attaching Keylistener to GLCanvas does not work
« Last post by KaiHH on August 14, 2019, 20:34:31 »
Now you seem to be mixing JOGL and LWJGL together. Can you please show the import statements of this code snippet?
Pages: 1 2 [3] 4 5 ... 10