Hello! I’m new here so pls forgive me if this question was already asked.
How should I make dynamically changing textures?
(My codes are in Java if something isn’t the same like in C)
Now if the color of my texture has been changed I siply make a new texture:
private ByteBuffer pixels = //here I change the color;
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
My problem is it’s working, but my performace is really dropped from stabile 60 fps to 4-7 fps.
Probably this isn’t the right method to do it. Or is it but I’m doing somthig wrong?
You can use glTexSubImage2D to replace a portion of an existing texture. If the portion that has changed is small, that may be faster than changing the entire texture.
Also, copying the data to a pixel buffer object then binding that to GL_PIXEL_UNPACK_BUFFER before the glTex(Sub)Image2D call (the pointer parameter then becomes an offset into the buffer) may be faster than reading directly from application memory. If you’re making frequent changes, using a different buffer object each time may be faster than re-using the buffer. In both cases, the idea is to minimise the risk of pipeline stalls (where the CPU has to wait for the GPU to finish what it’s doing or vice versa).
It also depends heavily on how you use your ByteBuffer. Individual puts are rather slow, especially for off-JVM memory. You achieve the best ByteBuffer performance by working on a primitive float array and then using a bulk put to upload the entire array at once. I dont know whether you use LWJGL or JOGL for this sort of thing but LWJGL3 might perhaps give you even more efficient memory manipulation techniques. I recommend asking in their official forums.
Other than that you might also want to try to simply render to a texture instead of manipulating the raw pixel data on the CPU. It does require FBO support and is a little bit more work code-wise but it could be substantially faster because you dont have to move from JVM memory to off-JVM memory to GPU memory in 2 steps.