[golang-dev] go.mobile gles 2.0 and unsafe.Pointer

On Thursday, August 14, 2014 12:04:57 PM UTC-5, Bryan Turley wrote:

This is meant as constructive criticism, and to begin a discussion.
You may need a copy of
http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf

follow this.

OpenGL is unsafe.
It is not easy to remove the unsafety.
My only real concern with the gles2 bindings up for codereview in
go.mobile are functions like

func VertexAttribPointerFloat32(dst Attrib, size int, normalized bool,
stride int, data []float32)

where data was void* on the c side. (section 2.8)

void VertexAttribPointer( uint index, int size, enum type, boolean
normalized, sizei stride, const void *data);
index is dst and type is inferred in the go version

In the []<basic type> case stride should always be 0 and could just not

there.

This will work, unless you use an ARRAY_BUFFER in which case data is a
pointer sized offset stored in a void*.
You want to use an array buffer for speed and simplicity. (section

It also won't work in the case where you actually need to use the

parameter.

type Vec4 struct {
X, Y, Z, W float32
}
type TexCoord struct { // really a vec in glsl
S, T uint16
}
type MyVertexAttribs struct {
Vec4
TexCoord
}

vertArray := make([]MyVertexAttribs, 1024)

With this slice, stride is the size of MyVertexAttribs and you would

two VertexAttribPointer calls.
without an ARRAY_BUFFER
One with data = unsafe.Pointer(&vertArray[0].X) size = 4, type =
GL_FLOAT
One with data = unsafe.Pointer(&vertArray[0].S) size = 2, type =
GL_UNSIGNED_SHORT
data upload is done with glDrawArrays() or glDrawElements() from your
"squirreled away" pointer
with an ARRAY_BUFFER
data = uintptr offset from the element 0. (not a pointer)
other parameters remain the same.
data upload is done with BufferData/BufferSubData instead of this

BufferData/BufferSubData are just odd gpu aware memcpy()
no squirreled pointers involved in this method, which is another

to do it this way with go ;)

You may also put multiple vertex arrays (with different definitions and
strides) into a single vertex buffer object.
You can have structs and flat arrays in teh same buffer as well.
In that case you would write a simple allocator and have biased offsets
for each one.
Having multiple vertex arrays in a single vertex buffer object means

calls to opengl and more speed.

You may also do this with the ELEMENT_ARRAY_BUFFER (index buffer).
You may have byte indices and uint16 indices in the same buffer making
[]byte and/or []uint16 not exactly correct.
Add []uin32 to that mix with GLES 3.0

You may also store both ELEMENT_ARRAY_BUFFER and ARRAY_BUFFER data in a
single buffer object, though this may be slower on older hardware.
In which case you would be mixing structs with arrays.
(end of page 25 in section 2.9.2)

So you could make a BufferData/BufferSubData for each basic type, but

are you going to do it with arbitrary structs without using

(well I do it indirectly with reflection but there are still
unsafe.Pointers involved)
Each basic type would mean (u)int{8,16,32}, float32, fixed, boolean

9 versions each of BufferData, BufferSubData, VertexAttribPointer

adding packed arrays (the struct case))
This adds needless complexity to an api that is already overflowing

needless complexity.


Oddly there are only two buffer types in gles2.0 without using common
extensions.
I had no idea GLES 2.0 was this slimmed down, I almost died laughing

I saw figure 2.1.
Compare figure 2.1 (page 13) with the cover from
http://www.opengl.org/registry/doc/glspec43.core.20130214.pdf
to understand why.
The cover of gl4.3's pdf is probably very close (or identical) to

with AEP though.