Empty texture creation

[Zengar]

Hi,

 I need to create some empty textures. That is, pass last parameter to glTextImage* as zero pointer. Is it even possible?  It is very annoying, having to create all that temporary buffers noone needs.

 Optional question: Also, what is the fastest way to convert java string with a shader source to a byte buffer?

 Thanks!

[Matzon]

Why dont you just create 1 buffer and reuse it ?
many people create a 256 byte "scratch" buffer and then position and limit or slice it accordingly.


as for the shader stuff:
byte[] bytes = sharderstring.getBytes();
ByteBuffer b = BufferUtils.createByteBuffer(bytes.length);
b.put(bytes).flip();

[Zengar]

Thanks a lot!

Well, I would like to elliminate the useless copy... Also, additional 5 Mb do make a difference. Could you probably consider adding such feature to the next library release? Something like EmptyBuffer etc. Or a new function entry without data pointer.

[elias]

You can pass in a null buffer just fine. Remember to cast the null buffer to something ("(ByteBuffer)null") to tell javac which overloaded version of glTexImage you want.

 - elias

[elias]

Btw, the upcoming version of LWJGL adds support for non-direct buffers, so you can be more liberal with the buffer allocation (at least for init code).

 - elias

[Fool Running]

Btw, the upcoming version of LWJGL adds support for non-direct buffers, so you can be more liberal with the buffer allocation (at least for init code).

Really? What's the reason for that? It seems like so much effort has gone into forcing direct buffers, I'm curious why the sudden change? Won't that cause a performance hit? (I thought that was the reason for the direct buffers in the first place)

[elias]

Btw, the upcoming version of LWJGL adds support for non-direct buffers, so you can be more liberal with the buffer allocation (at least for init code).

Really? What's the reason for that? It seems like so much effort has gone into forcing direct buffers, I'm curious why the sudden change? Won't that cause a performance hit? (I thought that was the reason for the direct buffers in the first place)

You're half way right. We've advocated direct buffers, and still do - they're faster than non-direct buffers. Non-direct buffer support is implemented as a slower fallback. The support should not affect the performance of direct buffers, since we already check isDirect() for sanity checking - the difference is that instead of throwing an exception, we fall back to a different code path.

  - elias

[Fool Running]

Ah, OK. Thanks for clearing that up