Mikal's Forum Posts

  • 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.

  • Testing Sprite Baking Studio w/ 3D models (art pipeline from Unity & Unity 3D models to 2d images that can be brought in as images for sprite animations in C3.)

    Can also add dynamic shadows w/ transparency which may help it feel more integrated into the scene.

    The tree 'Z' effect is very simple, depending on current 'Y' coord of player vs the 'Y' coord of the base of the tree, place the tree on a 'foreground' (in front of player) or 'middleground' (in back of player, but in front of background.)

    Also added pathfinding behavior (once reach dest, sets the path to the current mouse cursor x,y, so basically chases around the cursor) also added a polygon cut out in the shape of the foreground hill and also add a rectangle solid as a keep out at the base of the tree.

    Lapine Tales Devlog

  • Testing Sprite Baking Studio w/ 3D models (art pipeline from Unity & Unity 3D models to 2d images that can be brought in as images for sprite animations in C3.)

    Lapine Tales Devlog

  • Cool crazy stuff!

  • Got a bit distracted with some good Unity / AR dev work, but now looking at this again and reading about writing (the cool Vandameer book about writing - the author of Annihilation.) As I was doing on Unity, I got interested by the Adventurer Creator add on which looks like a really nice engine/development tool, but in the end, it's probably more heavyweight than what I need and I'm also interested in doing the engine development, so I'm working on the C3 version again. Adventure Creator did give me some inspiration to try 2.5D ('3D characters in 2D maps with Z like Grim Fandango.)

    Unity did bring up a nice path for doing an art pipeline based on capturing 3d models w/ animation and creating 2D sprites. I did a couple quick tests and I 'll think I'll go with it.

    Basically, download Unity, buy the Sprite Baking Studio asset, some 3D model assets and it's pretty nicely automated to generate a bunch of sprite sheets using different camera angles.

    Here's a quick example (not really integrated into the background and the movement timing is off but gives some idea of the animation/sprite generation quality.)

  • mumu64 - I mainly worked on designing the development systems for some of the game consoles and then jumped into leading one version of the 'next gen' game console designs, good times...

  • Sounds good, I will watch for the full version. (I worked at Sega in the past, so Virtua Cop is running on a development version of the Saturn - the disc door sensor is flakey, so we have to keep a paperweight on it so it works, of course, that paperweight happens to be an old Xbox :) ) We also use the Saturn to play 8 player Bomber Man, the best version of Bomber Man ever made.

  • Congrats on the release it looks like you already have some good reviews on Steam.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Very nice! We still have the old light guns, Virtua Cop disc and Sega Saturn in our lab at work - this definitely scratched an itch! The sight on the enemies with the countdown triangles was spot on.

    I started out shooting 'offscreen' to reload, whoops.

    Next up House of the Dead?

  • Looks, great! Love the lighting in the water and how the 'reflection' goes away when the lamps are destroyed. Is there some other way to delinate what is hackable or not? For example a symbol (animated?) or color instead of the 'Hack' text tag? Or is there some stylistic reason you would rather have a text tag? I do see the prompt '>', so perhaps you are trying to show this is a old school DOS shell or something (which does seem good and thematic.)