I've been toying around with the idea of writing a 3D game in Go. And I've
been working through the following OpenGL tutorial for C++, porting
everything to to work in a golang.org/x/mobile/app.


It's been great fun. And I have to say that performance is better and more
consistent than I feared it might be. But honestly I do not like the
package golang.org/x/mobile/exp/f32 and I'm about ready to rewrite it
myself. But given the big warning in its doc comments I was wondering what
people internally were doing or had planned in regards to reworking the
package internals?

The f32 package has some erroneous computational bugs which I don't need to
go into (they are open issues on github). What concerns me most about the
f32 package is that some design decisions it contains seem to be
detrimental to performance. Performance is something I think I need to
conserve in a 3D mobile app. Here are a couple (backwards incompatible)
ideas I have to improve the package design and make it work smoothly with
OpenGL (that's the point, right?).

- First, and most incompatible, I think the matrix types should be flat
arrays that use column-major order (because that's how users have to
serialize things into OpenGL). Currently the user transposes matrices
explicitly for serialization. It is a pain and is potentially worsened
without a Transpose function in f32. But, in general it just wastes CPU
cycles. If Mat4 was defined as [16]float32 in column-major then
serialization to []byte would be trivial.

- Second I think the serialization function, Bytes, is pretty bad. I've
noticed it does crafty things for speed, but it always allocates a slice.
To serialize MVP matrices on each frame you could argue the allocation cost
is minimal. But, going through the OpenGL tutorial has shown me, when you
load a model you need to serialize multiple large slices of f32.Vec3 values
(or Vec2, which isn't actually defined by f32). So a typical application
will allocate boatloads of unnecessary byte slices when it initializes by
calling f32.Bytes() for each f32.Vec3 element in the vertex slice. In a
more specialized case, when an application actually requires models to be
dynamically loaded at runtime they will inject tons of garbage pointers
into the runtime for every model reload. I think f32.Bytes should be
replaced with one or two functions more analogous to the builtin functions
copy() and append(), which take a destination as their first argument.
Something like hex.Encode() would be nice and close to backwards
compatible. This would make serialization of matrices in the render loop
essentially free of allocations.

Do these suggestions make sense and sound good? If you all don't think I'm
crazy I can open an issue and start the proposal process.

The way things are it makes no sense to me why all the linear algebra
functions aren't implemented in the package golang.org/x/image/math/f32,
which uses a row-major order (though also chose to use a flat array, FWIW).

- Bryan

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 17 | next ›
Discussion Overview
groupgolang-dev @
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p



site design / logo © 2021 Grokbase