Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More sg_vertex_format types #286

Open
gingerBill opened this issue Apr 24, 2020 · 3 comments
Open

More sg_vertex_format types #286

gingerBill opened this issue Apr 24, 2020 · 3 comments
Assignees

Comments

@gingerBill
Copy link

At the moment, there are no 1-element integer vertex formats, only 2+.

Requested types:

SG_VERTEXFORMAT_BYTE
SG_VERTEXFORMAT_UBYTE
SG_VERTEXFORMAT_SHORT
SG_VERTEXFORMAT_USHORT
SG_VERTEXFORMAT_INT
SG_VERTEXFORMAT_UINT

SG_VERTEXFORMAT_BYTEN
SG_VERTEXFORMAT_UBYTEN
SG_VERTEXFORMAT_SHORTN
SG_VERTEXFORMAT_USHORTN
SG_VERTEXFORMAT_INTN
SG_VERTEXFORMAT_UINTN
@floooh
Copy link
Owner

floooh commented Apr 24, 2020

Several of those type will very likely cause performance problems on various backends and drivers (e.g. any type where the size isn't a multiple of 4 bytes). This is an old post of mine, but I doubt that GL drivers can even fix this type of problem: https://floooh.github.io/2013/01/23/a-radeon-fix-and-more.html

And for the "4-byte-multiple" sizes, a similar problem as with the uniform types exists, I seem to remember similar compatibility problems as with integer uniform types on WebGL and GLES2 which then resulted in the very "conservative" selection of vertex formats in sokol_gfx.h, but I'd need to do new tests to confirm this.

So, basically out of your list, only those would remain:

SG_VERTEXFORMAT_INT
SG_VERTEXFORMAT_UINT
SG_VERTEXFORMAT_INTN
SG_VERTEXFORMAT_UINTN

(the other possible combinations for (U)BYTE and (U)SHORT which result in multiple-of-4 sizes are already supported)

@floooh floooh self-assigned this Apr 24, 2020
@gingerBill
Copy link
Author

I know the smaller types will be slow for numerous reasons, but I was wanting to reduce the size of my vertices by only storing enough data as required. If I have to use 4 bytes per integer rather than 1 or 2 bytes, then that's the compromise I will have to take for using sokol_gfx.h.

@floooh
Copy link
Owner

floooh commented Apr 24, 2020

To be more precise, I think/guess it's not so much the size of the datatype, but the stride that's important (again, I might remember wrong, but an "odd" stride which isn't am multiple of four might have problems on other backend APIs too). And if this is true you wouldn't be able to save memory.

What I'm trying to do usually is to pack several things into the the same vertex component (for instance one could pack four "unrelated" 8-bit values into a single UBYTE4 vertex component.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants