This is the script to perform changes proposed in T51219
I'm ok adding GWN_ to enum values and Gwn_ to data types.
Also ok shortening these words:
allocate --> alloc
primitive --> prim
Less ok shortening these:
vertex --> vert
attrib --> attr
Totally ok using abbreviations for variable names, just not for type names.
Prefer MAX_VBO_CT = N, for valid range 0 to N-1.
really should be MAX_VERTEX_ATTRIB_CT since it's 16 and valid values are 0 to 15
Original names are more accurate! These describe the conversion between VBO values and shader input values. Improved docs would help here, better than renaming.
Yes to these abbreviations.
I'm ok using the more common name of "index buffer".
was copying OpenGL primitive types, but as long as we're abbreviating... how about
Using MAX_ as a prefix means not using GWN_ as a prefix. Its also significant that the maximum is associated with Batch and not some other part of the API.
Even with docs, using a generic prefix here will result in a very long name:
NORMALIZE_INT_TO_FLOAT becomes GWN_FETCH_NORMALIZE_INT_TO_FLOAT.
Would GWN_FETCH_I32_TO_F32_NORMALIZE be acceptable?
In that case shouldn't the API be renamed, eg: GWN_elemlist_build -> GWN_indexbuffer_build?
Rename conventions based on feedback from @Mike Erwin (merwin)
- attr -> attrib
- vert -> vertex
note that I still prefer the shorter abbreviations, since (vert/verts) -> (vertex/vertices), just more verbose without really helping readability.
The names are getting quite long, which I wanted to avoid, eg:
.GWN_vertbuffer_attr_fill_stride (or GWN_vbo_attr_fill_stride) becomes GWN_vertexbuffer_attrib_fill_stride.
Overall I like the idea of adding consistence to the API. But I think we are shortening things more than we really need. See some inline comments.
That said I'm not passionate either way.
Same here, why use FMT instead of FORMAT?
I personally don't see the benefit of shortening for the sake of it. I would use:
At least for macros if not also for the function names.
Typo, it should be