FAQ
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 to
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 be
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 2.9)

It also won't work in the case where you actually need to use the stride
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 use
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 func.
   BufferData/BufferSubData are just odd gpu aware memcpy()
   no squirreled pointers involved in this method, which is another reason
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 less
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 how
are you going to do it with arbitrary structs without using unsafe.Pointer?
(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 (without
adding packed arrays (the struct case))
This adds needless complexity to an api that is already overflowing with
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 when 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 gles3.1
with AEP though.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 7 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedAug 14, '14 at 5:04p
activeAug 15, '14 at 12:41p
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase