FAQ

On Thursday, August 14, 2014 6:17:49 PM UTC-5, Dave Cheney wrote:
I don't think you offended anyone. But that didn't make your original post
easier to parse.

I suggest that you summarise your question and try again.
  Ah, ok.

go.mobile gles2.0 does this
func VertexAttribPointerFloat32(dst Attrib, size int, normalized bool,
stride int, data []float32)

for this c function
void VertexAttribPointer( uint index, int size, enum type, boolean
normalized, sizei stride, const void *data);

I think it there should be two go versions instead of 7 go versions.
One where data is an unsafe.Pointer. (for actual pointers)
And one where data is a uintptr. (for pointer sized offsets)
Or just the uintptr version since the unsafe.Pointer version is probably
not really safe with moving gc.

Out of the 3 funcs that work like this it would cut 21 funcs down to 6.
The rest of the text explains how those funcs are used and why they need to
be unsafe.Pointer and uintptr and not slices of basic types.


On 15 Aug 2014 09:15, "Bryan Turley" <bryan...@gmail.com <javascript:>>
wrote:
6hours and no response, hopefully I haven't offended anyone.
Also I made a small mistake I will correct below.
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 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
No int32/uint32 vert attribs in gles2.0... which is odd because you can
have a 16.16 fixed point vertex attrib (which is stored in an int32...)
So 7 versions not 9 (ignoring extensions).
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+...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout.
--
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

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 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