Custom GLSL/HLSL shaders in BYOND would be EXTREMELY useful for amazing visual effects. This would likely be difficult to implement in a good way, but the pros would be great.
But wait, wouldn't this be a security issue?
These don't even run on the CPU, they run on the GPU, for obvious reasons.
Of course, nothing is foolproof and perfect, so the optimal choice would be an easily accessible setting to enable/disable said shaders, with a prompt.
But why?
It is completely unreasonable to expect every single visual effect possible to be implemented as a filter() effect. As such, this would allow skilled developers to create their own such things.
ID:2542016
 Feb 4 2020, 3:19 pm
|
|||||||
| |||||||
Lummox JR wrote:
I believe there's already another feature request for this that has been marked not feasible. Ah, sorry, didn't find it. The main issue is 1) I'd have to make some major changes to the rendering pipeline to make this work, and 2) games would have to supply both HLSL and GLSL versions of the shader since eventually I'd prefer to migrate to OpenGL and the webclient already relies on WebGL. Completely understandable | |
I'm sure people would be fine with the second point if the option was there.
(Irony: We started with OpenGL from bitblt and went DirectX instead, live and learn.) | |
Also there are translators/converters for GLSL->HLSL, in terms of the "game makers would need to rewrite code twice" problem.
| |
If there's a very simple easy-to-include GLSL to HLSL translator, I'm way more open to considering the changes.
| |
Let the developer worry about it? Engine doesn't have to hand-hold everything, if they're smart enough to be using custom shaders, they're probably smart enough to handle the language of it too.
Yes, it would make it so when GL is implemented they don't need to switch their shaders, but I really doubt it'd be a major project to switch from one to the other. Especially if you've already written it as a GLSL and translated it to HLSL yourself. Just recommend everyone do that instead of writing in straight HLSL and let them do the translation, Google literally has thousands of translators. | |
An OpenGL rewrite? Great! no more installing june 2010 directx sdk.
| |
Lummox JR wrote:
If there's a very simple easy-to-include GLSL to HLSL translator, I'm way more open to considering the changes. SPIRV-Cross and various related tools can convert between HLSL, GLSL, SPIR-V, and whatever else you may need. They probably do have a hefty binary size increase all things considered though. I would probably advise you to not try to actually make a GL renderer though unless you're actually intending to port DS to Linux/macOS in some far forsaken future. Direct3D is a much better API than OpenGL and especially on Windows you will have significantly less driver, integration, performance and compatibility nightmares to deal with. | |
Lummox JR wrote:
I'd have to make some major changes to the rendering pipeline to make this work I heard from the tgstation discord that you were planning a renderer rewrite for 516. If so, how much more difficult would it be to make support for user-provided shaders feasible as part of this rewrite? | |
In principle I don't have a problem with custom shaders. The main issue is 1) I'd have to make some major changes to the rendering pipeline to make this work, and 2) games would have to supply both HLSL and GLSL versions of the shader since eventually I'd prefer to migrate to OpenGL and the webclient already relies on WebGL.