glNamedBufferDataEXT with size parameter

[Kai]

Hi,

why isn't there any glNamedBufferDataEXT(int buffer, long size, int usage) in EXTDirectStateAccess?
There is an equivalent function in ARBVertexBufferObject.

It is very convenient to have this function to pre-allocate storage which can then be mapped via "glMapNamedBufferEXT".

I sure could use the "non-direct state access" version instead, but then I would have to bind the buffer first, which is what this extension is trying to avoid.

[spasi]

There is, check glNamedBufferDataEXT(int buffer, ByteBuffer data, int usage). There are versions for other buffer types as well.

[Kai]

There is, check glNamedBufferDataEXT(int buffer, ByteBuffer data, int usage). There are versions for other buffer types as well.

Thanks for your reply!

I certainly know about this function, but that is not what I was intended to do.
Given that I have not yet a buffer in client memory (CPU RAM) I want to initially allocate a given amount of space in a VBO in VRAM so that I can later use a mapped version of this VRAM buffer to insert the VBO data. The benefits of this is not to have any data in client memory but only in VRAM.

So what I need is an equivalent direct-state-access function for the already existing function ARBVertexBufferObject.glBufferDataARB(int target, size, int usage).

[Kai]

I implemented the requested method in my local lwjgl working copy by annotating the method

void glNamedBufferDataEXT(@GLuint int buffer, @AutoSize("data") @GLsizeiptr long size,

	                          @Const

	                          @GLbyte

	                          @GLshort

	                          @GLint

	                          @GLfloat

	                          @GLdouble Buffer data, @GLenum int usage);

in the EXT_direct_state_acces template with @GenerateAutos, as it is already the case in the equivalent method in ARB_buffer_object.

That does the job just fine for me.

[spasi]

OK, I see what you mean now. I committed the change, thanks.

[Kai]

I used the new method in linux where everything works fine, but now I happen to have it supported on windows, too, and as you might know, Windows is kind of a synonyme for "problems" :-).

Would you (spasi or any other lwjgl-member) be so kind to build a windows native library including the changes, since the changes to the java template does also reflect on the natives being generated?
I have tried it using the ant script, but the msvc compiler always crashes (without an error message).
Then, I tried to build a MSVC project using VS2008. Compilation and linking succeeded, but somehow, the native behaves very strangely. For instance, for AWTGLCanvas the paintGL method never gets invoked, etc...

It would be very nice, if you could supply me (and everyone else) with a new windows native.

Thanks in advance!

[Matzon]

attached - from r3173 - unofficial windows binary

not sure when we'll do the next release