hawk shaders

08-09-2018

<feos> zeromus: can you briefly tell what prevents retroarch shaders support? the way they do it currently, there are preset files and then actual shaders loaded by them. it's been working for them, why won't it work for us?
<feos> for us, shaders add a huge benefit because we can dump avi of any tas with them
<feos> I remember you said they're not following their own specs https://docs.libretro.com/specs/shader/
<feos> is that really true?
<zeromus> feos, we DO support retroarch shaders, and we DO support preset files. yes, theyre not following their own specs.
<zeromus> however, we DO NOT support all the features of the specs
<zeromus> feos, the "theyre not compatible with their own specs" i believe is mitigated if you use a newer technique for handling the shader porting. they stopped using CGC I think. youre supposed to process their files as HLSL directly, and additionally have a totally separate GLSL archive, I think. right? I cant remember
<feos> they have CG and HLSL shaders, and presets for each, everything in its own folder. and a couple more... formats?
<zeromus> also, I will not work on shader support so that you can dump avis with them. that's absurd. shade in postprocessing.
<zeromus> i am embarassed that the bizhawk shader support is so crusty though
<zeromus> however thats not a task i'm willing to undertake right now. i have too much other stuff going on
<feos> on postprocessing it's terrible to set up
<feos> requires handing avis to retroarch's ffmpeg core
<zeromus> one thing you could do though would be to change the code to not use cgc, and to throw errors when loading hlsl or glsl when the wrong display method is picked.
<zeromus> then you would have a hope of more shaders magically working
<zeromus> but i bet they still dont follow their own specs
<zeromus> so you have to fork their shaders repository, fix them one by one, and send them PRs.
<zeromus> the only reason they dont follow their own specs is because their parser and processor is too lenient. its not really on purpose
<zeromus> also their specs are shit
<zeromus> and you can quote me on that
<feos> hmm, so they manually convert CG ones https://github.com/libretro/glsl-shaders/tree/master/pal
<feos> "This repo is for glsl shaders converted by hand from libretro's common-shaders repo, since some don't play nicely with the cg2glsl script. "
<zeromus> when does cg2glsl run?
<feos> no idea
<zeromus> i think last time i gave up working on shaders, i asked that question and never got a coherent answer
<zeromus> maybe their buildbot runs cg2glsl on the hlsl shaders, and then patches the results with these
<zeromus> that would mean you cant just check out the repository and get what the retroarch user gets
<feos> yeah
<zeromus> 1. please confirm that by downloading both shader sets in retroarch and analyzing them
<zeromus> or by asking
<zeromus> 2. if so, i suggest we commit all those shaders combined into one repository. basically commit their build output
<zeromus> well. im not sure how we want to present this to users.
<zeromus> i dont really want to tell people to install retroarch and download the shaders there and then use them from bizhawk
<zeromus> its possible we could build the shaders actually using their cg2glsl and merge the stuff JUST AS THEY DO
<zeromus> but someone needs to ask them HOW DO THEY DO
<zeromus> ok, how about that
<zeromus> find out HOW DO THEY DO and if it's suitable for build scripting, i'll script it in our build process
<zeromus> then we could package all the shaders (even though a bunch of them won't work) and at least have it automated.
<zeromus> by the way, we lack some of the features required for some of the shaders to work. a few features arent hard. some of the features are really hard. neither of those I have any intention of working on right now
<feos> I think if we only want glsl, we can just only use the glsl repo
<zeromus> that will be missing some shaders
<feos> then we need to support CG?
<zeromus> because they do not deliver the contents of their glsl repo
<zeromus> oh my god
<zeromus> i will write the entire thing again
<zeromus> i think they must automate running cg2glsl on the contents of their CG repo, then overwrite the results with the contents of the glsl repo, which is shaders which have been fixed since cg2glsl messes them up
<zeromus> the result is what they deliver to users
<zeromus> therefore if we deliver the contents of the glsl repo, we are not delivering what they deliver to their users
<feos> so the main question is, where they grab glsl shaders for shipping with RA?
<zeromus> yes
<feos> my take is that cg2glsl is ran on CG shaders, and then fixed by hand, and then committed to glsl-shaders
<zeromus> nope
<zeromus> look for bicubic in the glsl-shaders top level
<zeromus> its missing
<zeromus> they must be merged
<zeromus> you need to go ask them to be sure
<feos> I definitely will
<feos> this has been bugging me for years
<zeromus> one other thing i wasnt clear about: we need to STOP running cgc manually. we should pass the .cg to directx directly. (will any of them work in d3d9?) and error if the user is running d3d display method and chooses glsl shaders.
<feos> and with some computer cores, raw emulator output just doesn't represent the quirks of the device, so we'll need them shaders to make it better (optionally)
<zeromus> also FYI, technology for transpiling shaders has improved since retroarch set that up
<zeromus> https://github.com/aras-p/hlsl2glslfork this for instance, or one of the things the "status" section links to.
<zeromus> i believe, I would try this before committing to using separate glsl/hlsl repositories. but the advantage to separate glsl/hlsl repositories is it's easier to blame things on retroarch since we haven't improvised our own solution
<zeromus> also ask them why they have separate extensions .cgp and .glslp
<zeromus> ok im done with this, i have work to do