skymen's Forum Posts

  • 1.0.0 just released

    This comes with a MASSIVE changelog and covers everything I said I wanted to do a few months ago.

    Functions and loop bodies

    - Function graphs: subgraphs with a typed input/output, callable from any other graph. They compile to real shader functions.

    - Loop body graphs: a subgraph with optional arguments and accumulators and an auto-injected Index input, wrapped in a for loop by the caller node.

    - Generic subgraphs: a subgraph port can be generic and they get resolved at codegen, so one function can compile to multiple functions with different types based on what calls it.

    - Turn Into Function: select a group of nodes and convert them into a function in place, wires and all.

    - New tabs bar to show opened graphs.

    - Variables are graph-local, so a function stays self-contained.

    - View Code follows the active tab and shows the compiled function or loop.

    Constants

    - Constants are named values, emitted as `const` declarations and shared by every graph.

    - Loop bodies in WebGL1 need a constant loop count, so when possible the count resolves at codegen and uses it directly instead of going through a variable.

    - A loop whose count cannot be resolves during code gen runs to a constant cap and breaks early on WebGL 1. The cap is settable per loop body in the info section and defaults to 64. On WebGL2 and WebGPU dynamic loops are supported so this is ignored.

    Preview

    - Multiple preview windows, each with its own settings.

    - Pop out a preview into its own browser window.

    - 3D model support, 3D rotation, and object offset.

    - Render resolution and fullscreen quality settings.

    - Background modes, and a reproduction mode for rotated spritesheet frames (Construct packs some frames sideways, which turns any texture-UV-to-layout mapping 90 degrees.)

    - Preview settings are now saved with the project.

    Shader targets

    - Choose which of WebGL 1, WebGL 2 and WebGPU a project supports. Disabled targets are skipped by codegen and left out of the exported addon.

    Command line

    New csg CLI tool that runs part of the app headlessly for automation

    - create, validate, lint, arrange, codegen, export, comment, preview, run, repl, diff, paramid, api.

    - csg validate asks whether the shader compiles; csg lint asks whether the graph is readable afterwards (checks for dead nodes, auto-named variables, unrouted fan-out, crossing wires)

    - csg preview returns a PNG preview of the current graph by running the preview headlessly

    - csg api --list is generated from the API manifest, so a new API method is reachable from the CLI with no CLI code written.

    Layout and comments

    - Rewritten auto-layout engine that should work a bit better with some cases, notably when multiple set variable nodes are used from the same node.

    - Comments are now layouted, They act as a big node and anything inside of the comment gets layouted properly to stay within it and nicely packed.

    Nodes

    - New: FBM 3D, SDF Gradient Color, Aspect Correct, Oscillate, Src Origin Size Px, Get/From Layout Pos (rotation-safe).

    - Improved FBM, Rotate Around Point, Math, Texture Front/Back (edge sampling modes), Swizzle (manual entry), and the Epsilon/Pi/Tau constants.

    - Manual entry for port types, and a button on each node that opens its manual page.

    Uniforms and project settings

    - Each uniform carries a stable id, so renaming it no longer changes the exported addon's parameter id.

    - Deleting a uniform first deprecates it for parameters that must stay in a published addon.

    Editing

    - Selecting a Get Variable/Set Variable node now shows a dotted wire to the linked nodes

    - Changing a variable name in Set Variable now updates all the linked Get Variable nodes

    - Double-click a comment body to edit it and comment text is always rendered.

    - Better copy/paste, including across subgraphs.

    - Undo/redo works across graphs and was made a bit more reliable.

    - Moving the camera moves attached HTML elements with it.

    - Keyboard shortcuts are now properly blocked while a dialog is open.

    - Loading a file that uses unknown node types reports what was dropped instead of just deleting the nodes.

    Housekeeping

    - The MCP bridge was removed; the CLI replaces it.

    - Add Uniform, Add Custom Node, Add Function etc buttons were all moved to the bottom of their respective lists in the side bar

    Try it now at

    skymen.github.io/construct-shader-graph

  • Thanks for the report Zizaco

    This should now be fixed :)

  • Oh? Oops I will look into it

  • I just added support for it as well as an example

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I mean it's a different way to work with this, but it's far from a bad idea. This means you can put your assets wherever you want without having to think about layer order as a final thing and you can make the decision for how layers are structured at runtime.

    I did that for one of my game and it made level design super easy specifically because I didn't need to set up any complex layer system at edittime and I could just create everything on layout start and be sure that everything would be set up correctly.

    Although I do agree that batch edits would be a good idea too don't get me wrong. But being able to fully create layers at runtime including the effect stack and all its properties mean you can make a function that creates a layer template for anything, including with template elements on it.

  • in theory if you follow a good naming convention, only layers that need to be synced would share a name, and so you could say "for every layout that has a layer named X and a layer named Y, move layer X to a given position relative to layer Y"

    Same would go for renaming, removing, adding or editing.

    This would be kind of a pain to set up the first time for existing projects where the naming convention wasnt made with this feature in mind, but for everything else in the future you could in theory do it that way.

    I also agree that layer templates sound like the best way to design the feature in an ideal world, but I would rather have a simple batch edit feature than an over engineered half broken new layer system that takes 4 years to get right.

  • Ashley and Diego litterally just said 3 times that layer templates and UI work takes a lot of time and means it probably wont be done any time soon if that's what is needed.

    In theory having the batch edits is good enough cause you can select what layouts to target by having good naming conventions in the layer names.

    I think that batch edit is a fine way of doing it, and in general I am all for having more batch editing of that kind in the engine. Alternatively (or I suppose as an alternative), having the option to just make the changes at runtime means we can just generate all the layers on startup which is also a good option and completely eliminates the problem.

  • One quick suggestion:

    Why not allow us to add layer effects at runtime? This would be a lot easier, I've done engine hacks in the past that let me do it, and it would completely skip the whole problem if we can just setup all the layers at runtime manually.

    Right now what makes this impossible is:

    - we cant change what effects are on a layer at runtime (i mean add/remove from dynamic/static layer, not just enable/disable effects)

    - a few of the layer params (namely 3D params) are still impossible to change at runtime

    This IMO would actually be the simplest smallest possible version of that feature because then you could just write a few events that handle it at runtime based on layer name for litterally anything you might need, and then we can create the sprites on them either using recreate from layout or using templates.

  • I started working on a new feature: Sub Graphs (also called Sub Routines)

    This feature is still VERY EARLY and EXPERIMENTAL but I have decided to deploy it through an experimental branch so I could start gathering feedback.

    skymen.github.io/construct-shader-graph/experimental

    Let me know what you think :)

    Known bugs:

    - Code generation is broken with sub graphs

    - Type propagation doesn't work reliably

    A lot (or maybe even all) of the code for that feature can be discarded or completely redesigned at any point. This is only my first stab at the feature.

  • GDevelop's native AI integration is likely much more efficient and therefore has a smaller carbon footprint on average.

    In my testing, it really straight up doesnt work, and burns through tokens super quickly.

    I don't think C3 having AI assistance for event sheets is worth it. Maybe an AI for searching through a project or for writing JS/TS but to be honest I'd rather AI tools stay out of C3 completely. I can think of a few hundred features I'd rather see work for before AI agents given how small the Scirra team is.

    You might personally dislike it for all the right reasons, but AI appeals to the same market no-code tools do - people looking for an easy solution when making a game, without learning any hard programming stuff.

    That's true but in this case why not use Godot or Unity? AI will work better there, integration already exists and the engine is free AND more capable than C3 when it comes to 3D. I just don't think a tool having AI for the purpose of making already simplified code even simpler really makes any sense.

  • Gdevelop has added AI before spritesheets.

    I think a lot of people tend to ignore or forget about that fact.

  • discord.gg/jfR3nMFjxJ

    Opened a discord server about this family of tools.

  • Sure that's a good idea.

    Here is the server link: discord.gg/jfR3nMFjxJ

  • Hi bro, I found an easy bug.I referenced it first, and then set the variable. Although this may be my problem, it's better to avoid this situation.

    Hi, yeah this is a limitation you can only set a variable once. It's more like a named wire teleport than a proper variable.

    If you need to change the value of a variable, use other variables, or compute the variable in a way that gives it its final value directly.

    Also, I was thinking of removing the localisation system. It's a bit cumbersome and properly supporting localisation would require reworking a lot of the UI and none of the docs are localised.

    In the current state, do you find the chinese localisation worth keeping or not? I dont speak chinese so I genuinely can't tell if its any good.

  • Haha thanks, but no the tool is not made in Construct, I built it in vanilla Javascript