Windows Live Shader Editor

Greetings Fellow Devs,
Today, I present a tool that will greatly improve the shader development workflow - a tool that was painstakingly put together through trial and error / constant testing with hypotheses because GMS2 is closed-source.

Live Shader Editor is a C++ extension that allows you to compile shader code instantly at runtime - directly from the built-in editor!

As you would expect, this greatly increases shader development productivity as it allows you to discover all sorts of new things by testing code you probably wouldn't have under normal compile time constraints.
 
Last edited:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I'm very curious about the implementation details of this as I've been looking into this myself (one of the projects loads user-defined HLSL9 shaders), but it seemed that as of GMS2 PSSetShader/VSSetShader are called immediately before drawing the batch, therefore the only way to override a shader is by hooking the D3D function

Edit: see DM
 
Last edited:
Oh yeah, forgot to mention. It's exclusively windows and does not support mac (building a mac version would require a complete re-write from the ground up as mac uses opengl whereas windows uses directx). Currently, you can only save glsl es shaders at runtime.

There are also other things I intend to explore such as graphics draw optimization, gl_VertexID (which is not accessible by default), or compiling shaders from strings so you can protect the source code from being immediately accessible.
 
When you say "instantly", what do you mean exactly? Because some shaders can take a long time to compile. Does it short circuit things somehow?
By "instant", I refer to how it allows you to bypass the additional compile time normally associated with play-testing and narrow it down to just the bare directx d3dcompile function for the fragment and vertex shader like it should be. That alone already serves as a huge time saver.

But additionally, under normal circumstances in which I have tested, d3dcompile takes no time at all - the compiler finishes as you press the save-key. If your shader is highly complex it could take longer. In my case with a complex shader (i.e. thousands of raymarching iterations with more raymarching loops within each iteration along with complex noise algorithms that abuse the mix operation in addition to several texture-lookups per iteration) - basically code you would not expect to run on commercial hardware within the public domain - the longest I ever saw my dll take to compile was 1 second.

In regards to "short circuiting", I instruct the d3dcompiler to skip the optimization phase as it is not needed during iterative debugging. I suspect Gms2 is using the highest level of optimization even during playtesting - in which the compiler can take significantly longer but produces the most efficient code.
 

Yal

🐧 *penguin noises*
GMC Elder
This looks amazing! Considering how there's very little documentation on the shader language in GM, and it's tedious to recompile your game every time you're trying to trial-and-error together the effect you want, this seems like it could speed up the process a ton.
 

squircle

Member
This is really cool. I learned shader stuff with other software when I realized how crucial live reloading was to learning and testing shaders. I wish I had this when I was just starting! I'm still not very good though, and this will really help beginners who need live reloading to experiment and correct mistakes quickly without resorting to other software. Of course, it'll be useful for everyone else as well. I know I would love it. Good job Tyler, really, this is super cool, please keep up the fantastic work. I can't wait to see what other awesome stuff you will bring to the community!

Sadly, I do have to mention it, because it disappointed me, and I'm sorry to make my first post on here about some drama: Regardless of your opinion of YellowAfterLife or his status in the community (I purchase and use several of his assets and I appreciate his presence in the community, a genuine thank you to YellowAfterLife for being helpful and making GM easier and better to use for years now), fact of the matter is that creating a brand new asset that everyone has been waiting years for, posting your progress on the forums, and then no less than 24 hours later having a (somewhat) duplicate asset come up must feel really bad. I hope you are feeling okay about this, Tyler. You seemed excited about this Live Shader Editing you were working on, as seen in your signature and other parts of the forum. I'm sorry if your feelings or motivation were hurt by this, especially since this is the first project you've posted (I think?). I hope this won't discourage you from continuing work on your extension and other extensions in the future.


To keep discussion on topic, and I'm sorry for going off topic in the first place, I have a few questions for you Tyler. I am a newbie when it comes to this kind of stuff, so I hope you don't mind if they are painfully obvious answers. I'm eagerly awaiting this extension's release so I'd love to know some details!

1. What happens when there is an error in the shader? Does it default to a last successfully compiled version of that shader, or maybe the game crashes?
2. Are there any memory issues? Like what if I keep editing the same shader for a very long time, will RAM increase?
3. Is there any performance impact at all compared to just editing these shaders manually? Like, when I am done editing shaders will I want to remove the extension and any related code from my project?
4. Does this work with vertex shaders as well?

Good luck Tyler, I am looking forward to the full release.
 
Last edited:
This is really cool. I learned shader stuff with other software when I realized how crucial live reloading was to learning and testing shaders. I wish I had this when I was just starting! I'm still not very good though, and this will really help beginners who need live reloading to experiment and correct mistakes quickly without resorting to other software. Of course, it'll be useful for everyone else as well. I know I would love it. Good job Tyler, really, this is super cool, please keep up the fantastic work. I can't wait to see what other awesome stuff you will bring to the community!

I have a few questions for you Tyler. I am a newbie when it comes to this kind of stuff, so I hope you don't mind if they are painfully obvious answers. I'm eagerly awaiting this extension's release so I'd love to know some details!

1. What happens when there is an error in the shader? Does it default to a last successfully compiled version of that shader, or maybe the game crashes?
2. Are there any memory issues? Like what if I keep editing the same shader for a very long time, will RAM increase?
3. Is there any performance impact at all compared to just editing these shaders manually? Like, when I am done editing shaders will I want to remove the extension and any related code from my project?
4. Does this work with vertex shaders as well?

Good luck Tyler, I am looking forward to the full release.
Thanks for the heads up!

1. Defaults to the last successfully compiled version of that shader (and also gives an optional popup message about the compile error. You can also send the message to the console instead).

2. None that I have observed. You can save for an unlimited amount of times and there is no memory leak. If you are worried that the debug overlay will go crazy as you test you can rest assured the dll barely costs anything at all (I normally observe real_fps in the same range as an empty project!) and only spikes up when you save for a split second.

3. There is a performance impact, but only during testing. D3DCompiled shaders have 5 levels of optimization with the lower levels being suited to debugging and testing because they cost less time and the higher levels used for making the code as optimized as possible but requiring more time. My dll defaults to skip the optimization phase altogether - which reduces compile time to no time at all - though I also provide an option for the user to set the optimization level to what they wish. I suspect gms2 is using the highest level which is why it can sometimes be very slow to work with. Additionally, I have not been able to observe any noticeable fps difference within the 5 different levels unless the shader is extremely complex (see my response above).

4. Absolutely! You can even use it with vertex buffers with custom formats - which I thoroughly tested because the way gm stores the attributes and uniforms in the final shader can be quite tricky.
 
Last edited:

kburkhart84

Firehammer Games
@Tyler D. Anderson Were you able to make some progress on this? I'm interested in making a visual node shader editor for GMS2 and am looking for ways to get shader previewing to work, and this seems like I could use it to get what I want. If it isn't fully finished would you be willing to share what you have so far?
 
Top