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

why separate from dx ? #9

Open
akva2 opened this issue Nov 3, 2016 · 4 comments
Open

why separate from dx ? #9

akva2 opened this issue Nov 3, 2016 · 4 comments

Comments

@akva2
Copy link
Contributor

akva2 commented Nov 3, 2016

any reason for this to be separate from the windows version? is it the list of shaders, are the shaders different or what's the deal?

@popcornmix
Copy link
Owner

Yes, list of shaders are different. Only a small percentage of shaders designed for desktop use are usable on arm platforms.
Also arm platforms generally can't maintain a decent framerate at full (e.g. 1080p) resolution, so we render to a smaller texture and scale that up.
GL and GLES are already sufficiently different that we need a number of ifdefs - I wonder if adding dx to the mix would have much common code at all. It probably could be refactored to separate the rendering code from the control code, with separate back-ends for dx/gl/gles, but that is not a trivial change.
And we still have the issue that kodi can't distinguish a GL from a GLES implementation of an add-on so they can't live in the same repo.

@akva2
Copy link
Contributor Author

akva2 commented Nov 3, 2016

reason i ask is that i did https://github.com/notspiff/screensaver.shadertoy/tree/add_gl_gles which is a copy-pasty draft for gl(es) before i realized this one exists.

it's not so much about code sharing as it is about having a single upstream in my mind. thus,
the repo issue is orthogonal as such.

i guess i will add gl-only support to the dx one, and then we'll have "desktop" and "embedded" versions.

@popcornmix
Copy link
Owner

Your code does seems to be based on this repo's code (measure_performance and determine_bits_precision were originally written by me). Perhaps you picked it from a repo based on this one? I'll try and test it when I get a chance.

Supporting shadertoy's recent multipass rendering would be a nice thing to support if you are working on this - it makes shaders much more powerful (without needing much more powerful hardware).

@notspiff
Copy link
Contributor

notspiff commented Nov 3, 2016

(sorry for being schizo, so many devices);

sure, it's your code from visualization.shadertoy that i copy-pasted and modified. where we do have one common upstream (dx code in separate file, gl/gles a nasty ifdef spaghetti).

i wasn't trying to push my version, just to give some fuel to my fire; the multiple upstreams cause confusion (and in this case partially duplicated work). the version here is better i'm sure.

popcornmix pushed a commit that referenced this issue Apr 5, 2020
Change to new C++ based addon interface style
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