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

Consider not tying formats so heavily to DXGI/D3D #2

Open
john-h-k opened this issue Jun 22, 2020 · 2 comments
Open

Consider not tying formats so heavily to DXGI/D3D #2

john-h-k opened this issue Jun 22, 2020 · 2 comments

Comments

@john-h-k
Copy link

Currently the formats seem to be directly tied to the DXGI_FORMAT enum from dxgi.h. Is this a conscious design decision or will it change? Ideally, I am planning to use this library for texture loading for both DirectX and Vulkan, and so a more platform agnostic system would be more useful, as well as allowing support for formats that aren't supported by DXGI_FORMAT (such as double precision pixels)

@JimBobSquarePants
Copy link
Member

Pixel formats are extensible but I agree, if we can add some well known formats supported by Vulkan etc then that would be useful.

@brianpopow
Copy link
Contributor

I have added support for decoding ktx textures along with support for more pixel formats (still its not exhaustive, there are just too many in opengl).

@john-h-k could you be more specific in which pixel formats you be interested in?

Also some compressions are not yet supported, like astc and etc. Any help in that regard would be very much appreciated.

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

No branches or pull requests

3 participants