Mikal's Forum Posts

  • This is an interesting problem.

    The main issue here is that depending on frame rate, dt and bullet speed, you will trigger the overlap condition at different X locations on each wall. If you look very carefully (or look carefully and increase bullet speed), you will see that sometimes the squares overlap the walls by different amounts before they change diection, then they will start at different locations and change the spacing.

    To make it look more consistent, one idea is to detect how much the overlap is and set the block back to where it 'should' be when it reflects back in the other direction.

    Try this and let me know how it works in your testing. The formulas can be simplified, but I left them as is, so it would be easier to see what the calculations are doing.

    It does start to fail if you increase the bullet speed to be so high that in one frame two squares would overlap the wall, if you need to deal with that case, you will need to do more work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Using your Spine project on a Moto G6 and remote preview:

    1 Spine Object: 60 fps

    2 Spine Objects: 40 fps

    3 Spine Objects: 30 fps

    On iPhone XR:

    30 Spine Objects: 60 fps (and starts to slowly fall off after that.)

    In the plugin, we are updating a texture for each Spine object on each draw call. Some mobile GPUs may have low performance on texture updates.

  • Heh, no this is a SDV day scene on a sprite with a WIP LinearLight effect applied w/ a gradient.

    If you do a simplified farming game, please let us know how it goes.

    — if you are still looking for this effect, let me know, I have something you could try out.

  • Are your 'lines' separate sprites or are you using Drawing Canvas?

  • How about this? A good look depends a lot on the gradient image you apply.

  • I am not the plugin's original author, I am mostly helping out with the webgl rendering side and fixing bugs. So, generally, I will not be doing work to add a lot more ACEs. I think the original author has moved on from using this plugin themselves, so I think it will likely stay with a minimal number of ACEs to support playing animations.

    That being said if you have a few critical ACEs required, you can make a request up on the github website in the issue list:

    github.com/gritsenko/c3_spine_plugin/issues

    Also, since this is all done in JS, you can also use JS script in events to access the Spine API directly in C3.

  • Here's a formula for linear light from this page: deepskycolors.com/archive/2010/04/21/formulas-for-Photoshop-blending-modes.html

    (Blend > 0.5) * (Target + 2*(Blend-0.5)) +

    (Blend <= 0.5) * (Target + 2*Blend - 1)

    I am not exactly sure how to use it though, I imagine you are blending a source image with the background. I think you would have to apply the above to each color component separately?

    I am over on the Construct Community Discord and have ported/developed effects before if you want to discuss creating an effect or see if that would even work for your purposes.

    discord.gg/kBrCTWV

  • On my project, I fixed the Android APK issue. It seems that for some reason, the initialization process for the Spine plugin takes longer on apk than when done with the web version.

    The longer initialization exposed a bug in the plugin which caused multiple initializations. I fixed this bug in the plugin and now in my simple apk, the Spine character renders properly.

    Please try out the new version of the plugin: 1.4.5

    It's available here:

    gritsenko.github.io/c3_spine_plugin

    Please let us know your results.

  • I am debugging another simple project on Android, it looks like there's some looping on initialization. I will report back what I can debug around this issue.

    I am using USB and Mac to do the debug, it's very helpful to enable this. See the post above about how to do this.

    Also, I wanted to check that my other comment about the bug in your project with the wrong animation name helped fix your 'restart layout' problem on the PC.

  • Ashley I think I'm going to assume that for distortion effects (or effects where we adjust the texture sampling coordinates), I will always enable must-predraw so I can get consistent behavior with srcOriginStart, srcOriginEnd, and relative impact and 'direction' of pixelSize, regardless if only one effect is used or more than one effect is used (or opacity is used.)

    I think there also may be cases where I can also use the normlization technique (n= (vTex-srcOriginStart)/(srcOriginEnd-srcOriginStart)) and then I can use clamp(newN, 0.0,1.0) and perhaps then it won't matter if must-predraw is used.

  • I see one error in your project, you have a Spine character with an incorrect animation-name at the bottom of your layout. When I removed that, restart layout worked.

    Zoom out in the C3 editor you will see at the bottom, it has an animation name of 'Tutorial2toidle'.

    The error shows up in the Chrome developer console (press F12). Please learn how to use the developer console, it is very useful for debugging errors.

  • When you have an error restarting the layout, open up the developer console (F12 on PC) and post any errors you see.

    One quick idea to try, add a 'wait 0.1 seconds' after the skeleton is loaded before enabling animations. I have seen a 'race' condition where one skeleton is loaded, but others are not loaded yet and using their animations cause an error.

  • The buggy versions that do not follow the spec actually make it possible to use clamp(uv, srcOriginStart, srcOriginEnd) in the C3 predraw case.

    The versions that follow the WebGL spec do not work with the C3 predraw case where srcOriginStart.y > srcOriginEnd.y. The webgl spec is: min(max(x, minVal), maxVal).

    So, if the bugs were fixed to match the OpenGL spec, then clamp(uv, srcOriginStart, srcOriginEnd) could not be used with C3 in the predraw case on any platform.

    I think to handle the variable C3 behavior between predraw and no predraw, clamp and platform variance, for effect distortions where vTex is changed, I will use must predraw and also my own definition of clamp.

  • Ashley

    I think I have found out the reason I was having an issue with using clamp(uv, srcOriginStart, srcOriginEnd) when a predraw was being done with an effect (e.g. <100% opacity or an effect stack.) In this case srcOriginEnd.y was less than srcOriginStart.y. The clamp still worked fine on MacOS Chrome, however, it worked differently on iOS. It looks like it's because the glsl clamp function is being implemented differently on different platforms (OS/browser/GPU/driver.)

    Here's an example and discussion:

    shadertoy.com/view/Ms33R4

    I get different results in iOS/Safari/iPhone and MacOS/Chrome/Radeon.

    So, for cross-platform and predraw / non-predraw compatibility, I will probably use this method: 

     #define clampX(x,a,b) min(max(x,min(a,b)),max(a,b))

    From the discussion on shadertoy (from my experience, iOS also does the OpenGL spec version.)

    It seems like it's implemented in a few different ways (guessed based on how you described them):

    #define clamp(x,a,b) min(max(x,a),b) //OpenGL spec (3 gradients, 2nd black)

    #define clamp(x,a,b) max(min(x,b),a) //Linux (2 white bars in the middle)

    #define clamp(x,a,b) min(max(x,min(a,b)),max(a,b)) //Windows (4 gradients)

  • This effect applies lighting and specular without using an additional normalmap, the normalmap is generated from the object's image. Control over light power, specular color, location, etc.

    Ported from a shadertoy effect, details in Documentation.

    construct.net/en/make-games/addons/350/normalmapprocedural