On Tue, 1 May 2018, Ryan Joseph wrote:
On May 1, 2018, at 4:37 PM, Michael Van Canneyt <mich...@freepascal.org> wrote:
What's wrong with the above code ?
It obviously works well enough, otherwise they wouldn't have made the API so.
The float32 array is a Javascript type that encapsulates a memory buffer.
I assu
It’s difficult to work with. With OpenGL what you have is a record with all the
fields that are the data for vertex (positions, colors, normals etc…) and you
tell OpenGL at what offset and stride the data starts. If you use to just array
literals like that it would be very messy.
void vertexAttribPointer(GLuint index, GLint size, GLenum type,
GLboolean normalized, GLsizei stride, GLintptr
offset);
That’s what I would expect not using WebGL before. Getting that down to typed
arrays using wrapper functions would be a mess though. Ouch. No idea how that’s
supposed to look in WebGL.
// array of TVertex
[
// vertex 1
[
[0, 0], // position (vec2f)
[255, 255, 255], // color (vec4b)
[0, 1], // texture coord (vec2f)
],
// vertex 2
[
[0, 0], // position (vec2f)
[255, 255, 255], // color (vec4b)
[0, 1], // texture coord (vec2f)
],
// vertex 3
[
[0, 0], // position (vec2f)
[255, 255, 255], // color (vec4b)
[0, 1], // texture coord (vec2f)
]
]
type
TVertex = record
pos: TVec2f;
color: TVec4b;
texCoord: TVec2f;
end;
verts: array[0..2] of TVertex;
The parser could break down records into those arrays but it would be
complicated I suspect.
I don't think we'll introduce language tricks for such things.
The WebGL people made do with what Javascript offers.
Likewise, we make do with what pascal and Javascript offer...
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
