Vertex buffers currently need you to specify every vertex individually. this can create a lot of redundant data, even for simple quads. it also makes manual primitive drawing code much harder to read
Describe the solution you'd like
vertex_index(i) and draw_vertex_index(i)
example:
// A simple quad
draw_primitive_begin(pr_trianglelist)
draw_vertex(-1, -1)
draw_vertex(+1, -1)
draw_vertex(+1, +1)
draw_vertex(-1, +1)
// order isn't important, but makes more sense readability wise to
// write the vertices then the indicies
draw_vertex_index(
0, 1, 2, // triangle 1
0, 2, 3 // triangle 2
)
draw_primitive_end()
this would also make model formats such as .obj easier to handle (as the format creates faces out of indices into a pool of vertices)
Describe alternatives you've considered
manual index buffers/arrays. It's pretty clunky however (as the vertex data has to be written manually with a regular buffer and then written to a vertex buffer) and doesn't alleviate the redundant data issues an index buffer would help with.
Quads can be drawn using pr_trianglestrip, however this obviously means all quads must be connected to each other.
Is your feature request related to a problem?
Vertex buffers currently need you to specify every vertex individually. this can create a lot of redundant data, even for simple quads. it also makes manual primitive drawing code much harder to read
Describe the solution you'd like
vertex_index(i)
anddraw_vertex_index(i)
example:
this would also make model formats such as
.obj
easier to handle (as the format creates faces out of indices into a pool of vertices)Describe alternatives you've considered
manual index buffers/arrays. It's pretty clunky however (as the vertex data has to be written manually with a regular buffer and then written to a vertex buffer) and doesn't alleviate the redundant data issues an index buffer would help with.
Quads can be drawn using
pr_trianglestrip
, however this obviously means all quads must be connected to each other.Additional context
No response