Mikal's Forum Posts

  • Cool, clean UI, looking forward to seeing more.

  • Cool art, is that second image animated? To the embers/sparks cascade down around the PC, would be nice to see that.

  • Normal Map & Sprite Bake Studio (Unity 3D Model Animation -> Sprites. Added a Normal Map Shader pass to Sprite Bake Studio to generate Sprite Normal Maps.)

    Tech for lighting a Bambi forest fire like scene.

  • Added the option for the hard Spotlight effect to all three lights in version 1.4 (latest versions with examples on the addon repo.)

  • Hack the NormalMap effect to get a hard edge, so it looks like a spotlight effect, based on some fun stuff from jmw327 (@jmw327) on Twitter that was shared in the Construct Discord. Andre' also made a really cool version.

  • Hack the effect to get a hard edge, so it looks like a spotlight effect, based on some fun stuff from jmw327 (@jmw327) on Twitter that was shared in the Construct Discord. Andre' also made a really cool version.

    Here's the _hack_ to the effect.fx if you want to play with it: 

    	//Determine distance (used for attenuation) BEFORE we normalize our LightDir
	float D = length(LightDir);

	//Hard limit for NormalMap, beyond this distance, go dark
	D = (D < dLimit) ? D : 1000.0;

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Really cool. Can something like this be achieved with this effect?

    https://twitter.com/jmw327/status/1058881134849863682

    It may be able to get close. You'll really need to carefully create the normal maps (in terms of anticipated light direction) for each plane of the building to make it work (and the building would need to be made of multiple sprites and normal maps.) Not a trivial amount of artist work.

  • macube mOOnpunk tatogame Try again, it wasn't properly 'published' before.

  • Please post any website issues to the website issue tracker.

    Done.

  • Fun stuff, I remember this game, it's so satisfying to carve out rooms. One of the most interesting things is emergent behavior of your monsters vs the incoming "PCs" - what are you thinking in terms of AI, etc.? It feels like you can actually go stronger here then the original - if C3 had access to some the latest ML/DNN tech, etc. hmmm...

  • Ashley - I submitted a new addon, but it's not showing up in the addon repo general listing (it's an effect.) I can directly link to it, but it's not part of the general or effect list.

    Here's the direct link:

    construct.net/en/make-games/addons/194/normalmapextended

  • Working further on the C3 runtime example, I have a new version which looks to work well across platforms (iOS, MacOS, Windows) and uses the Viewport* and Platform.DevicePixelRatio expressions, but does not use the confusing (and to be deprecated) Window* expressions. I updated the link above with the new C3 runtime example.

    Updated for C2, C3 runtimes and added to addon repo

    construct.net/en/make-games/addons/194/normalmapextended

  • Good news - Ashley commented in the bug report that the C3 runtime will be updated to have the same behavior as the C2 runtime for WindowHeight and WindowWidth (though they will be deprecated.) There will also be some new system expressions which should be used for C3 runtime, when these are available, I will update the examples.

  • Examples for version 1.3 (done with beta Construct r123-2, uses Platform plugin from C3 Runtime.)

    C3 Runtime Example:

    NormalMapTestC3Runtime.c3p

    C2 Runtime:

    High DPI breaks it (likely due to canvas vs WindowHeight mismatch.) Update - corrected this in the example by using LayerToCanvasX(0,ViewportRight(0),0) Instead of using WindowWidth. Also helped with zoomed in Viewports.

    NormalMapTestC2Runtime.c3p

    Unfortunately, right now this is Work In Progress, the current implementation is too fragile, windows x,y parameters must be changed based on runtime, OS, DPI settings, etc. looking for ways to make it more robust, suggestions welcome. With the above change, the C2 runtime version looks reasonably robust now (works on MacOS, Windows and iOS through remote preview). Still an issue with the C3 runtime version example because of the different behavior of WindowHeight/WindowWidth (which requires a code change between OSes.)

    A quick description of the problems seen, in case it sparks some ideas:

    C3 w/ C2 Runtime / MacOS / Windows:

    Window Width WindowHeight matches System Canvas Size dimensions listed in C3 Debug inspector

    WW, WH changes dynamically as preview window is manually scaled via mouse

    C3 w/ C3 Runtime / MacOS:

    WindowWidth, WindowHeight are fixed at Layout / Viewport sizes

    Does not vary, does not match System Canvas Size dimensions listed in C3 Debug inspector.

    Canvas size in debug inspector also does not match: LayoutToCanvasX(0, WindowWidth, 0), LayoutToCanvasY(0, 0, WindowHeight). The Canvas size in the inspector is 2X the LTCX/Y.

    C3 w/ C3 Runtime / Windows:

    WindowWidth, WindowHeight are fixed at Layout / Viewport sizes

    Does not vary, does not match System Canvas Size dimensions listed in C3 Debug inspector.

    Canvas size in debug inspector DOES match: LayoutToCanvasX(0, WindowWidth, 0), LayoutToCanvasY(0, 0, WindowHeight).

    The reason this matters is I’m using a normal map effect and I need to pass in parameters to the shader for the location of the light on the layout (x,y) which I need to translate with LayerToCanvas and to scale the effect properly also, also need to pass in the overall canvas/window height and width.

    There may be others way to do this (open to suggestions), but I am wondering why there is variability between C2 runtime, C3 runtime and OSes for WindowWidth/WindowHeight.

    Bug Report

  • Updated for C3 runtime based on discussion with Ashley:

    It looks like the effect depends on running in screen space to get the texture co-ordinates to work as expected (which makes sense for a reflection shader). Previously the C2 runtime always did a pre-draw step for anything marked as background blending, and the first bounce moves from object space to screen space as it draws to an intermediate surface. The C3 runtime has an optimisation where it can skip the pre-draw stage for unrotated background blending effects, which improves performance but in this case causes the effect to render in object space since it hasn't had a pre-draw step yet, which given the way the shader is written results in the wrong texture co-ordinate calculations.

    If you set "must-predraw": true in addon.json it restores the previous behavior and works as expected again in the C3 runtime, so that's your workaround. This is a compatibility difference between the runtimes, but given it's due to an optimisation for the C3 runtime that we want to keep, the solution is to alter the effect instead.