Animmaniac's Forum Posts

  • heinz

    Someone asked me if they could convert the effect to C3 sometime ago and I gave them permission.

    I believe it can be found here: https://www.construct.net/gb/forum/construct-3/plugin-sdk-10/plugin-converter-123855/page-4#forumPost890274

    Give it a try and see if it works.

  • Animmaniac - any chance you could make a c3 compatible version of this?

    thanks so much

    intend at some point, but right now I'm involved with some other things that are taking priority in my life. I have a bunch of other shaders that I would like to adapt to C3, some that I never released before, but I don't have an ETA at the moment.

    I also intend to reupload the files to some other service, but like zenox98 said you can download from totoe's link for the time being.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm not sure if you are aware, but the 'every tick' condition is redundant and have no effect in there.

    Like brushfe, I would use a compare variable on the Tilemap to pick it and that seems to work fine.

    I would expect the system's pick by comparison to work though, but strangely it doesn't. I manage to make it work by replacing the 'every tick' with a 'for each Tilemap' (which I think shouldn't be necessary). Maybe it's worth reporting as a bug.

  • If you want them to have equal chance of appearing try:

    choose(1,7)[/code:3r4r5n6b]
  • You can still use Dropbox - it's just a slightly different method (sharing).

    For the files yes, but I still want to provide live demos and embed preview images on webpages. As far as I know Dropbox doesn't support direct linking anymore.

  • I'll try to find some time to fix it. I first need a new hosting service to replace Dropbox.

  • lemondemon

    If you are still interested here's a zip containing my old CC effects: prr-CC-effects-A01.zip

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Also people are very sensitive to jank/juddering/uneven movement. If the logic is running at a different rate to the rendering, the motion becomes uneven. For example logic at 45 Hz with rendering at 60 Hz means every rendered frame shows alternating step distances, e.g. 10px, 15px, 10px, 15px... given how sensitive people are to this (particularly when scrolling), I think the only solution would be to go for an integer multiple/divisor of the framerate to guarantee every rendered step moves the same distance. E.g. logic at 2x, 3x, or 1/2, 1/3.

    ...and then if you only run logic at an integer multiple/divisor, there is no solution - you can't choose a logic rate that covers all these display rates with smooth motion.

    I think you may be missing or misinterpreting the part about interpolation/extrapolation. The idea is that the logic should run at a constant rate, while the rendering is a separate process that interpolates or extrapolates the logic steps to match any framerate the display uses. The render and the logic don't even need to be in sync, they could be different threads running in parallel on different cpu cores.

    To use your example, if interpolation was used the result would be a smooth movement with no jank whatsoever:

    *The gray balls represent the logic steps which are the real positions of the simulated object, while the red balls are the interpolated positions used just for rendering (they have no influence on the simulation).

    With this method it's possible to render at any display rate without affecting the simulation:

    As you can see with 120fps you just need to do more samplings to the logic steps while the simulation remains unaffected. Everything would behave the same regardless of framerate, just like when testing. There would be no unexpected behavior like tunneling on untested framerates since the simulation is always the same. And like variable timestep, CPU usage is matched to the framerate and can even be smaller since it doesn't need to step the logic at every rendered frame. This means it can use less battery, make phones cooller, and significantly increase the headroom to do interesting stuff with the CPU.

    What I don't really get about this is if you only step the game at 30 Hz, there is nothing new to draw in between logic frames.

    ...I think some devs propose a "lite" step in between which just advances motion without doing anything else, but this worsens tunnelling problems (new scenario: object actually seen colliding, but no collision registered!), and could still use a bunch of CPU e.g. if it's a large physics game.

    This is were the debate about interpolation vs extrapolation comes in. With interpolation you get a very smooth result, but it comes at the cost of rendering with up to 1 logic step of delay. Since you need to know the next logic step to do a proper interpolation with the previous step, you delay the render until the next step is available. This adds a bit of latency to input vs feedback. For a logic step of 30fps the latency is about 33ms, for 45fps 22ms, for 60fps 16ms (it actually looks like this on a timeline). But it should be fine for most games since according to Wikipedia the average input latency for games is 133ms, 67ms for quick action games. If a game needs a faster input response one can just increase the rate of the logic step.

    The other option is extrapolation, which is basically using the past steps to try to guess the future. It doesn't have the downside of latency but it adds a bit of imprecision to the perceived movement. For instance, a fast moving object may seem to overlap another solid for a fraction of a second before moving to it's true just-touching position. Or an object that changes direction constantly may drift a bit from it's real position on the simulation. However this has no influence on tunneling since it only affects the display position not the game simulation. What collides in preview should also collide in any framerate. It may cause the perception of some objects colliding but not registering though (when passing close on a curved motion).

    A third option is combining the two to get an average of the benefits and compromises of both. Like you could delay only half logic step, using extrapolation for the first half step (while the future logic step is not available) and interpolation for the other half step (after the new logic step is available). This would result in half latency with a bit of drifting. It's even possible to transform this into a slider that goes from full interpolation to full extrapolation with proportional steps in between.

    The thing is, depending on the game one solution may be preferred to the other. In my view interpolation is superior, but having an option to switch between the two is feasible.

    And don't forget on weak systems fixed-step games go in to slo-mo instead of stepping further to compensate.

    That's true, but speaking as a developer I prefer the game to go on a slo-mo in too weak systems than objects going through walls or jumping different heights. Although if my game was failing to run at a decent speed on my target devices I would probably adjust the logic step rate to accommodate those weaker systems and avoid any slo-mo.

    If desired it's also possible to still use an integer dt in those cases to step the logic only once. Like if the logic needs to step 2 times in a render frame, you set dt to 2 and step once. The result would be much more stable than a dt that varies every frame with complex fractions.

    However I would still prefer the game to step twice the logic instead of using dt, simply because it makes things more deterministic and easier to deal with. After all most games are limited by rendering and not by logic, so stepping the logic more than once in a slow frame should not add too much overhead.

    For example even with fixed steps, you can never assume your platform behavior will land at Y = 100, because floating point errors (literally occurring in the CPU circuitry) mean it will probably land at something more like Y = 99.9999999978.

    The main advantage of a fixed step is that the behavior will always land at the same height regardless of framerate given the same input conditions, while with a variable time step you can't ensure that. It's less about the math being 100% correct and more about the movements being predictable. The same maximum jump height you get when previewing at 60fps, you will get at any framerate. And with new displays increasing their refresh rate there's a chance the drift (when using variable timestep) will tend to get worse, as exemplified in the previous link I posted.

    So I still find this may be a better solution than the current variable timestep. It adds a bit of overhead due to the interpolation but overcompensates by not having to execute the logic at every rendered frame and by being able to run the renderer in parallel. And as a bonus solves other problems like unpredictable tunneling, nondeterminism, and the difficulty of begginers in dealing with dt.

  • There's a great resource on motion integrators here. A lot of the jump height drift can be improved by using time-corrected Verlet or a RK4 integrator for behaviors (see first link), instead of Euler based solutions. However I would like to point out that even those doesn't solve the problem completely.

    The thing is, although all these fancy integrators support different framerates they are not designed to handle dt fluctuations at every frame. Their formulas are expected to use a constant dt throughout the simulation. In practice C2 uses a variable timestep which introduce small fluctuations to dt at every frame, that in turn induces small errors that accumulate and can get big over time.

    To fully solve this and ensure that the jump height is the same all the time it's necessary to use a deterministic approach, AKA using a fixed timestep for the simulation. That's the solution most engines use nowadays in combination with interpolation or extrapolation for the rendering part to handle variable framerates. There are some great resources about this in the links below. The second one has a great example of how small errors turn big when using variable timesteps.

    http://gafferongames.com/game-physics/fix-your-timestep/

    http://www.koonsolo.com/news/dewitters-gameloop/

    Now it's probably not practical to implement this last solution in C2, but I would love to see it for C3. Besides solving the varying jump height problem it also eliminates the missed collisions due to small framerates (AKA tunneling), it removes the randomness of each play session which helps enormously in making a replay function or in games where the physics must behave exactly the same every time, it allows to set a smaller frame rate for the simulation (like 30 fps) freeing more cpu budget (specially good for mobiles), and it makes things easier for beginners since it's not mandatory to add dt in events that deal with time. It can also be backwards compatible by automatically setting the value of dt to compensate for the moving rate of objects, in case the new fixed timestep is different than 60.

  • You do not have permission to view this post

  • Here's a demo of the algorithm I suggested: Fuzzy Match Demo

    And here's the capx: Fuzzy Match capx

    *To test it just type in the editboxes and it will calculate the similarity between the two strings, giving a match if it's over 80%.

    I included some other heuristics that you can test to see what fits better your use case. To combine them I just used a simple average and got very decent results.

    In my auto-complete demo I have also used the number of matched characters, but in this demo I only included the strings' length similarity. However if you also want to implement it you only need to do the same it's done in the pairs comparison, just feed individual letters to the arrays instead of pairs.