Slashdot Mirror

← Back to Stories (view on slashdot.org)

Developer of 'Banished' Develops His Own Shading Language

Posted by timothy on from the copious-free-time dept.

jones_supa writes Luke Hodorowicz, the hard-working developer behind the townbuilding strategy computer game Banished, has
designed a novel GPU shading language and written a compiler for it. The language has been christened 'Shining Rock Shading Language' (SRSL) and it outputs the program in several other shading languages. The first goal for the language was to treat the vertex, fragment and geometry shader as a single program. The language sees the graphics pipeline as a stream of data, followed by some code, which outputs a stream of data, and then more code runs, and another stream of data is output. Body text of the shaders is very C-like and should be understood easily coming from other shading languages. SRSL has all the intrinsic functions you would expect from HLSL or GLSL. All types are HLSL-style. Loops and conditionals are available, but switch statements and global variables are seen redundant and not implemented. Luke's blog post tells more about the details of the language, complemented with examples.

31 comments

  1. It's the CSS and JS situation again. by Anonymous Coward · · Score: 1

    Shader languages are just like CSS and JS. They're all quite crappy, but can't really be fixed by the community, so lots of people end up writing "transpilers" to try to work around some of these many problems. That's why we have Sass and LESS and CoffeeScript and TypeScript and now this new shader language. Maybe they fix some problems, but their presence introduces a different set of problems. The right thing to do would be to push for the underlying technologies to be fixed.

    1. Re:It's the CSS and JS situation again. by Anonymous Coward · · Score: 0

      In which way are shading languages "crappy"? Shaders mostly seem like quite clean C-like programs to me.

    2. Re:It's the CSS and JS situation again. by dhasenan · · Score: 0

      You have to write your shaders twice if you want to support Direct3D and OpenGL. That's the biggest problem. A transpiler from GLSL to HLSL or vice versa would solve this, of course.

      Direct3D shaders have a bytecode format that is at least somewhat documented (https://msdn.microsoft.com/en-us/library/windows/hardware/ff552891%28v=vs.85%29.aspx), so you could in theory write a compiler from GLSL to D3D shader codes. This might be easier than writing a transpiler in general, though obviously if you're more familiar with GLSL and HLSL you'd find it easier to compile to shader languages than to a bytecode you are unfamiliar with.

    3. Re:It's the CSS and JS situation again. by Anonymous Coward · · Score: 1

      You have to write your shaders twice if you want to support Direct3D and OpenGL.

      Considering that you have to write your renderer twice as well if you want to support both Direct3D and OpenGL it is no big deal. If rewriting shader scare you, avoid rewriting your renderer as well and use only OpenGL. OpenGL is portable and available on more platforms, including windows, mac and linux.

      With all the new graphic API (Vulkan, Metal, etc) coming out writing multiple renderer backend and the appropriate shader do not scare real programmers.

    4. Re:It's the CSS and JS situation again. by Anonymous Coward · · Score: 1

      It isn't even remotely like that.

      CSS and JS have very little issues with incompatibility, besides input related stuff, and oddly enough, CSS access from JS. (holy shit that whole set of commands is awful, fix that shit already, it has been a decade for crying out loud)
      SASS, LESS, CoffeeScript and TypeScript (less so this) are mainly created to make it easier to work with CSS and JS.
      Some have support to export to other languages. But mainly they are designed to enhance and speed up development considerably. (like adding easy inheritance to CSS, and variables, which are less an issue now, but still sort of lacking)
      The -script versions in particular fix small issues with incompatible browser implementations. Admittedly more so for older browsers because W3Cs terribly shitty specs with an abusive level of optional rules for processing script. (and some not even defined in the slightest, like the aforementioned CSS accessors)

      This SRSL is entirely designed to export to other languages so you don't need to write multiple shaders.
      This will be a pretty huge thing in the coming years since game development is heating up at the moment with multiple distribution platforms and hardware.

      Any methods to simplify cross-platform development is always a good thing.
      This doesn't look at that brilliant, but it is pretty good.
      One major issue I can see is the inability to target lesser hardware easily.
      You could write some stuff to help with that, like being able to tag certain bits of your code in a way similar to CSS rules.
      So if your lesser hardware never had some feature, you don't add its name to the target list.
      And to go even further, you can then add a catch-all set of rules that have only simple effects.

    5. Re:It's the CSS and JS situation again. by Anonymous Coward · · Score: 0

      You have to write your shaders twice if you want to support Direct3D and OpenGL.

      Simple solution drop Direct3D support.

    6. Re:It's the CSS and JS situation again. by dhasenan · · Score: 2

      For my purposes, I use third-party engines that already can render to OpenGL and Direct3D. It is trivial for me to support both -- unless I have shaders, in which case I have to write my shaders twice. I don't mind doing that for a small number of shaders. I do mind doing that for five dozen shaders.

      In the case of SRSL, I think the idea was partly just because he could, and partly because he found himself modifying shaders moderately frequently.

  2. SPIR-V makes this more interesting by CajunArson · · Score: 1

    The good news is that with new standardized intermediate representations like SPIR-V in Vulkan, this shading language can compile down to the same IR that GLSL/HLSL/etc. use so there's more flexibility on the programming language side while maintaining compatibility with the graphics API.

    --
    AntiFA: An abbreviation for Anti First Amendment.
    1. Re:SPIR-V makes this more interesting by Arkh89 · · Score: 1

      The nightmare is that you might have to do the compiler job and generate an optimized SPIR-V IR from your language.

  3. So when is the extended version coming out? by Anonymous Coward · · Score: 0

    SRSL-E?

    1. Re:So when is the extended version coming out? by Ksevio · · Score: 4, Funny

      SRSL-E?

      The developer wrote in his blog that he wants to add a "Y" to the end but can't think of something for it to stand for.

    2. Re:So when is the extended version coming out? by fyodorjung · · Score: 1

      SRSL, yo.

  4. Kind of Pointless by goruka · · Score: 1

    The biggest problem when going from a platform to the next is not so much having to rewrite the language (pretty much everything runs GLES2 and will run GLES3, and that means GLSL, -except consoles-), but the fact that you will use completely different techniques depending on the underlying hardware and features. Having a single shader language does not prevent you from having to rewrite stuff many times.

  5. Why? by Nemyst · · Score: 1

    I have to ask... why? Looking at the few samples, it looks like some kind of hybrid between Microsoft's Effect framework (which used "techniques" to sandwich multiple shaders at different levels together) and Nvidia's Cg language (which output HLSL and GLSL from a common, sorta kinda average of the two languages). Considering how close GLSL and HLSL are already, I just don't see the point of writing anything more than a thin wrapper and a few headers that work as a shim/compatibility layer.

    1. Re:Why? by Anonymous Coward · · Score: 1

      Keep reading the guy's blog for the why... he started from nothing and wrote the game engine, the game logic, and designed all the graphics and sound himself. I think he did it because he wanted to.

    2. Re:Why? by Anonymous Coward · · Score: 3, Insightful

      Why not? (and, some of his reasons are described in his blog entry.)

      I think this is newsworthy because this developer single-handedly wrote it, after (nearly) single-handedly writing an entire game. This level of motivation and productivity is something special. I'd rather celebrate it (or at least give it a tip o' the hat), instead of deriding it.

    3. Re:Why? by friesofdoom · · Score: 1

      So would people be interested in my feature rich game engine that I've spend the last 10 years single handily developing on my own with not external help? I need to figure out how to get some publicity on that... but being a programmer, I suck at all these marketing things...

    4. Re: Why? by hackwrench · · Score: 1

      Submit a story to Slashdot, an ask Slashdot if nothing else.

  6. This will solve everything by GrumpySteen · · Score: 1

    Relevant XKCD

  7. This just in! Software developer develops software by Anonymous Coward · · Score: 1

    This is getting silly!.

  8. Wolfenstein by jones_supa · · Score: 3, Informative

    I once scooted through the source code of Return to Castle Wolfenstein, and it also seemed to have some kind of intermediate "mini-language" for shaders. It wasn't a language really, but it allowed artists to execute various effects with different parameters (like "winterfog 22 3.0 3.0 1"), which were then converted to real shaders on the fly. What is also surprising that I would have expected such an old game using fixed functionality instead of shaders.

    1. Re:Wolfenstein by Anonymous Coward · · Score: 0

      The Quake 3 / id Tech 3 engine called them shaders, but IIRC they were mostly instructions on how to configure advanced fixed-function hardware's texture samplers, combiners and so on.

      Similar features and similar problems can be seen in modern engines' graphical node-based shader editors.

    2. Re:Wolfenstein by Anonymous Coward · · Score: 0

      The shaders in the id Tech 3 engine are one of the things that make it so flexible. I can STILL make maps for it that look near as good as any modern game with creative use of shaders.

    3. Re:Wolfenstein by locopuyo · · Score: 1

      Isn't this why they created "Shader 2.0", etc. support to direct X and GPUs? To improve speed and so every game developer didn't have to create their own.

      --
      The Official Site of 1337 Pwnage
    4. Re:Wolfenstein by Anonymous Coward · · Score: 0

      id Tech 3 shaders could also do such things as normal mapping, phong shading, specularity, reflections/cameras, dynamic model placement/sizing, light bloom, dot product, tessellation, surface offset and vertex deformation. They were proper shaders.

  9. As Bender would say... by Dave+Emami · · Score: 2

    I'll write my own shading language! With blackjack! And hookers!

    --

    "The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
  10. Banished, never really finished... by damaki · · Score: 0

    Now, if only he could fix the bugs in Banished, that would be even nicer feature than creating a one man shader language...

    --
    Stupidity is the root of all evil.
    1. Re:Banished, never really finished... by Anonymous Coward · · Score: 0

      I didn't run into any bugs when it first came out. But then, I also didn't have any fun, either. It reminded me of why I stopped playing that genre.

  11. On redundancy by wonkey_monkey · · Score: 0

    global variables are seen redundant

    As is the word "as," apparently.

    --
    systemd is Roko's Basilisk.
  12. screw that what i want to know is by Virtucon · · Score: 0

    why my towns start starving? i keep building farms, gathering and hunting lodges yet starvation. fix that first!

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
    1. Re:screw that what i want to know is by Anonymous Coward · · Score: 0

      i guess you're doing it wrong? i didn't have any problem keeping my town going.

      you just have to manage your expansion. if the population grows faster than the food supply, people will start to go hungry.