Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

I have found the problem. I was creating a FloatBuffer every time I needed a Matrix4f. GC had to remove all created FoatBuffers and that was the reason of spikes.

A much better alternative is to use a debug context and GLUtil.setupDebugMessageCallback().

If you still need GLUtil.getErrorString, you can copy/paste the code from here.

I just updated to LWJGL 3.1.2 and GLUtil.getErrorString(errorCode) doesn't seem to exist anymore. What's the new way to do this?

Previous code (Kotlin):

Code: [Select]

val errorCode = GL11.glGetError()
if (errorCode != GL11.GL_NO_ERROR) {
throw Exception("GL ERROR: " + GLUtil.getErrorString(errorCode) + " code: $errorCode")
}


Brilliant, I was not able to observe the bug in that latest version.

Thanks spasi. Im always impressed by the way you have a nack for fixing code.

Sorry for the delay, 3.1.3 #5 is now available with a, hopefully, fixed jemalloc build. Could you please give it a try?

are you manually calling System.gc() in your code?

No. I do nothing what is related to GC. The spike frequency increases when I load more models into 3d space, since more frequently GC is called. And it does not matter how much memory GC has to clean, even if it is few megabytes, the FPS decrease spike still happens.

are you manually calling System.gc() in your code?

https://github.com/bcbradle/glfw

https://github.com/bcbradle/gl

https://github.com/bcbradle/gl-examples

Someday soon I hope to make video games in clojure; a big thankyou to all the people who have worked on lwjgl for making that possible!

You should try to migrate away from BufferedImage though. It uses a considerable amount of Memory, and is quite slower than the STB library included with LWJGL3

Perhaps you are generating too much garbage?
Hard to say without knowing what you do.

But spikes appear even heap is practically empty? It does not look like this is the case. Also you can see in plots that heap memory is not that full.