@Zombeaver I went to test that compiled version on my work laptop, and it’s saying it is missing the “libopenal-1.dll” file
Did you use the dlls from 1.9.13? My existing ones from 1.9.10 didn’t work, I had to use the ones from the latest buildbot.
Yes, fresh copy of the nightly version installed into a new directory, then added your .exe and the .dlls into that directory .
I was able to run the 1.9.10 version from Gouvernator previously, but I don’t see that libopenal-1.dll file in my directory with that version.
Okay, looks like maybe openal support isn’t built normally anymore. I originally pulled the dlls from within MSYS2 itself, I guess that one isn’t included from the Retroarch buildbot. I’ll setup MSYS2 on my work PC and build it again and attach the dlls.
Okay, take two. This is 1.9.13 + all dlls (in case there are any other non-default dependencies) and the shader pack with the folder structure.
OK, it does now open RA, but the only shader that does not give me the “failed to apply shader preset” error out of the handful I’ve tested is the “decker.cgp”. It’s even giving me errors on the base RA ones. I’m still investigating, it may be operator error since I’ve been using slang shaders the past year or so
They’re working fine here. They don’t work if you don’t have dedicated video hardware a.k.a. if you’re on integrated Intel video most of them won’t work. You said you were on a work laptop so I’m assuming that’s the issue.
Basically it comes down to how many calculations your video hardware is capable of making. The NTSC passes, in particular, are fairly demanding on this front and those are used in most of the presets. If your hardware isn’t capable of the necessary number of calculations, it’ll just fail to load. Decker doesn’t use the NTSC passes and would likely be the only one to work in that case. C64 Punk (which is essentially just a joke made by accident during experimentation) might also work as it’s a .glslp not .cgp; it basically degrades the video to look similar to a C64 game Most dedicated cards shouldn’t have any issues with them - they were originally made while on a GTX 780, for example, which is about 8 years old at this point.
That likely is the case, yes. My work laptop does just have integrated graphics card. I will try em at home this evening then on my gaming laptop.
EDIT: @Zombeaver everything works great on my home laptop with a 1050 in it. Thank you for helping me figure out that issue.
Yeah, Cg gives a crummier profile to non-Nvidia hardware (at least in RetroArch; I don’t know if it was like that everywhere), which is one of the main reasons I was less-than-bummed when we had to phase it out (and why I haven’t worked to phase it back in, now that the MSYS package is apparently fixed).
Yeah, I can understand that. I realize it’s probably a pretty niche thing but it’s one that I still use. If it could be added back into the standard buildbot releases that’d be great (I would certainly appreciate it, and I’m sure at least a few others would as well), but in lieu of that at least I can be self-sufficient in the meantime now haha
Sorry y’all, one more correction on the shader pack. I have a couple separate instances of Retroarch for various projects, and sometimes I work on these while working on them, and while I did copy over all the presets themselves, I noticed last night that a couple of the custom individual shader passes I’d made had been left out. This would have only affected a couple presets but any relevant ones would fail to load since the passes would be missing.
Zomb’s Shaders 11/10/21: https://drive.google.com/file/d/1YqSlnhRRL-QGHL5zlrC3poZVHxhkJB2v/view?usp=drivesdk
Here’s 1.9.13+cg+openal with the overlay “ninjafix” released today.
Well everyone, just passing through to share the link to the new home of the CyberLab Mega Bezel Death To Pixels Shader Preset Pack.
Here’s 1.9.14 + CG + OpenAL support. The only .dlls included with this one are cg.dll, cgD3D9.dll, cgGL.dll, and libopenal-1.dll as I think this is all that’s needed on top of the standard stuff, but if anyone gets a missing dll error let me know.
First of all, thank you for the link. I’m getting an error when opening RA, it is related to openal’s dll.
All your other builds worked fine.
I’m not sure what to tell you there. That dll is included with what was uploaded (and to my knowledge should be identical to the one that was in the previous ones). I can’t read your error so I don’t know what it’s saying the problem is. Everything’s working normally here.
The procedure entry point “__emutls_v._ZSt11_once_call” could not be located in the dynamic link library “libopenal-1.dll”
The dll is byte for byte identical to the one that was included with 1.9.13 so like I said, not sure what to tell you there. If it worked there it should work here. If it worked before you could always use the dlls from the previous version, the upload is still there.