MonoGame shaders from a complete beginner's state?

[Watercolor_Games]

I'd like to get into some pixel shaders in my game. Don't really care about vertex shaders. Just pixel shaders. However, I'm having a pretty hard time getting started.

So, assuming one does NOT have any experience with HLSL or any other shader lang, let alone experience with the C# part of shaders in MonoGame, how does one get started?

Ideally, I'd like to get myself to a state where I can do things like blurring, blooms, audio visualization, glows/drop shadows, and possibly even things like Aero glass transparency effects in-game. Any advice would be appreciated

[willmotil]

If you search around the forum you will see lots of posts about shaders.

Here's were i started.
If you look to the bottom first you'll see a simple shader and game1 to go with it.

Custom vertex data and effect problem

ill try that oh wait, wouldn't that mess up the non spritebatch rendertarget draw? Would i have to switch cameras between the rendertarget draw and the spritebatch ? Though i suppose its kinda non sequitur if i can do it all with the first call now. Re: It works on dx for both. Well with a little fov aspect ratio rigging i can get the non-rt call to look the same as the rt call (though its not close to properly mimicing it i just sort of spliced it in like that.) bout to test Gl now. Edit A…

[Watercolor_Games]

Thing is, I'm only doing 2D. No 3D, no cameras etc. So I don't want to have to worry about vertex shaders and things like that. Just want to do pixel shaders and learn how to effectively write HLSL.

To be quite honest I'd like to see if I could find something like ShaderToy but for MonoGame. Something that'll read in some HLSL source code, compile using the pipeline tool, and render in realtime on a preview image or something.

Said software probably exists for Windows, but what about Linux? I downright refuse to use Windows. A tool like this would greatly help me learn honestly...I don't learn by reading tutorials and only reading tutorials. I prefer to learn the features of the language, the syntax, etc then visually see how the code I write affects the output.

[Jjagg]

The big issue here is that MG's shader building toolchain uses a proprietary DX compiler, so you can't build effects on Linux/Mac natively (there is a pipeline extension that sends your effect to a remote Windows server that builds it for you, though it probably expects an old MGFX version).
There are a lot of projects that try to solve the issue of translating HLSL to GLSL in some way, but as of now none are production-ready AFAIK.

I've been meaning to write a tool like this for my GLFX branch, which supports a GLSL/Effect hybrid natively (so works on Linux/Mac). I haven't gotten to it yet though You'll want to use this branch if you plan on doing custom shaders on Linux.

For people coming across this thread, looking for a shader editing tool, you can try MGShaderEditor by @procfxgen.

[Watercolor_Games]

Okay...that's good to know. Are there any ways I can achieve blurs/glows/etc without writing a shader then? I am a little concerned about framerates.

[Jjagg]

You can achieve some effects with what's built in and by playing around with blend state, but for fancy stuff you'll need custom shaders. You're right that performance will take a hit if you have a bunch of RenderTargets that you draw to each other Custom shaders is definitely better and in my opinion easier to control (but maybe that's because I don't know how to work with blend states very well).

[Watercolor_Games]

See, there's no getting around the use of RenderTargets with my game. My game's set in a fictional Unix-like GUI-based operating system, and each window (even the desktop) is its own RenderTarget so I can do things like move windows around without having to repaint them.

I also get the added advantage of only having to paint if something changes. Still haven't figured out only painting the "damaged" area so if something needs painting, the entire window paints.

But I'd prefer not to render more RenderTargets than I need to. So if there's any way of getting shaders working on Linux (without having to use development builds of MG) that'd be handy. Please keep me posted if anything comes up

[Jjagg]

Will do. The GLFX branch I have is mostly experimental. It likely won't make it into a release build, or at least not anytime soon. But if another solution comes up, I'll definitely make a big celebration post here

[BitBull]

There is an excellent beginner's introduction to shader programming here - I found this invaluable.

There's an O'Reilly book called 'HLSL and Pixel Shaders for XAML Developers' which has some decent introductory stuff in it. Though it doesn't go into much depth overall it covers all the 'bread and butter' style effects and is pretty cheap.

I provide some sample code for shaders that draw geometric shapes here.

I am in the same boat as you having only recently started delving into the HLSL rabbit-hole and purely for 2D stuff. I develop on a Mac but run a VM of Windows under VMWare Fusion for the shader compilation. Workflow is fine this way. In that O'Reilly book it mentions and editor called Shazam which seems good for 'live' shader development. haven't tried it yet. Windows only of course.

I am finding HLSL invaluable though, I couldn't do many of the things I want to do in my game without custom shaders. This 'ray gun' effect is all custom shaders...

[luizpestana]

I know it is an old post, but has anyone tested this? https://github.com/Microsoft/ShaderConductor

[AcidFaucent]

It's shader feature support is incredibly narrow. That's quite obvious when you look at that graph and see that DX11 requires routing through SPIRV-Cross which is legend for how ridiculously awful it is.

There's a reason that Destiny / Frostbite / etc use fragment patching instead of exposing raw shaders. Which is an entire video in preproduction for a series on metaprogramming/code-generation that I'm doing (the sub-subject is C++ shippable game-engine in 30 days as that's an easy "game engines are hard and take forever and tools and stuff" strawman to burn down with metaprogramming and code-generation).

http://advances.realtimerendering.com/destiny/gdc_2017/index.html

[Jjagg]

DX11 requires routing through SPIRV-Cross which is legend for how ridiculously awful it is

Can you provide some source or explanation for this? I haven't heard bad things about SPIRV-Cross before.