Empty texture creation

Started by Zengar, April 19, 2007, 08:38:54

Previous topic - Next topic

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

QuoteBtw, 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)
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

elias

Quote from: Fool Running on April 19, 2007, 18:33:33
QuoteBtw, 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 :)
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D