FAQ

On Thursday, August 14, 2014 6:24:14 PM UTC-5, David Crawshaw wrote:
Definitely not, I very much appreciate the review of someone who has
spent a lot of time with GL. I just tried to quickly switch contexts
this morning and got stuck: calling JNI's AttachCurrentThread from a
cgo function is causing a segfault, and go-inside-google generates
plenty of bugs and email.

I'll try to respond later tonight or early tomorrow.

Alright, no worries.
On Thu, Aug 14, 2014 at 7:15 PM, 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 | 6 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