Ashley's Forum Posts

  • Should be fixed in the next build.

  • Maybe it's crashing because it's a long console log message? It looks like your own console log messages, maybe try turning them all off.

  • Typically in terms of images, low-pass means blur, and high-pass means sharpen. There are some built-in blur effects and there may be other third party blur/sharpen effects.

  • Well if your own testing doesn't show up any problems, it sounds like something on their side only.

    FWIW, IE9 only has <1% global market share these days - a lot of people could justify dropping it entirely by now.

  • Closing, please see the bug report guidelines.

  • It looks at the pixel data. So it doesn't matter where the images came from, if they are identical they are deduplicated (except for the limitations mentioned in the tutorial).

  • Closing as not a bug.

  • Sorry, there's nothing we can do about this without at least a link to investigate.

    Most reports like this are simply because you forgot to upload all the files, so the images are returning 404 not found. This is a very common mistake. Alternatively the server configuration may be set to only serve files from a specific path and not a subfolder, or something like that.

  • Closing as not a bug - you need to give a layout name as a string, not a number.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • We could add a "On save failed" trigger, but it doesn't necessary help. Browsers take privacy very seriously and deliberately make it hard for the page to know what is happening to its data. For example Chrome in incognito mode will say everything saved to disk just fine, then when you close the window, delete it all. That's by design, and they deliberately prevent pages from identifying this mode so that the page can't nag them to have their data saved - it just looks like it worked.

    So even if we added this, you don't know when to show the alternative copy-paste system, because you can't really tell if the data will last permanently or not.

  • This is definitely a good idea, but is far from simple to implement. This is a classic case of something which looks easy to a user but in reality involves a great deal of architecting.

    C2's effect compositor is one of the most complicated parts of the engine. It has to take an arbitrary chain of effects - each with their own parameters and each with a varying ability to be drawn with different optimisations - and process all of them in sequence correctly eventually ending up on the screen without bloating memory proportional to the number of effects used. Adding custom texture to each stage is possible, but this is one of the most difficult aspects of the engine.

    Then on top of that you have to add all the UI. Right now there's no mechanism to edit an image which doesn't belong to an object (or a project icon file, a special case). So all of this would have to be invented and hooked in to the effects system too.

    As you say, it's a good idea and makes a lot more visual effects possible. However I think it would be most plausible to consider this for C3, and probably some time after its release at that.

  • Hmm... I think the problem with using 0.5 is it's exactly in the middle of the rounding direction, which makes it round semi-randomly due to floating point imprecision and dt variation.

    Floating point math isn't exact in processors, due to the binary representation, e.g. 0.1 + 0.2 = 0.30000000000000004. This happens literally at the CPU level, so again no technology or framework is going to save you, it's just a fact of floating point math on CPUs that regularly trips people up. Add to that the fact dt is not always an exact value, since it's based on timer measurements, and in practice your frame advances are going to look something like this:

    Frame 0: position = 0, displayed at = 0

    Frame 1: position = 0.50000000000000001, displayed at = 1 (+1) - rounded up

    Frame 2: position = 1.0000000000000001, displayed at = 1 (+0)

    Frame 3: position = 1.4999999999999999, displayed at = 1 (+0) - rounded down

    Frame 4: position = 1.9999999999999999, displayed at = 2 +(+1)

    so the slight variations in the math cause random rounding directions and create an irregular progression rate again.

    You can lock dt so it doesn't vary, but note setting a minimum framerate of 60 doesn't do that reliably - if dt was measured as 16.6ms (~60.24 FPS) instead of exactly 1/60, then it introduces a variation of 0.066666... ms. To avoid this kind of variation around the framerate you will need to set a much higher minimum framerate, e.g. 100, which would reliably lock dt to 0.1. In fact to cover all displays you should probably choose 200, and then base everything off a regular dt value of 0.05.

    Even so, what's to say the game won't offset something a tiny fraction at some point and then get all the irregular updates again? Then when you throw in to the mix a 50% parallax layer, you're probably opening another can of worms. This is much harder than I think most people really realise.

    My preferred solution would be to just use "high quality" fullscreen mode and turn off pixel rounding. Then you still get the blocky look, but things can move smoothly. This basically solves all the problems you will face, since larger windows mean even smoother scrolling, rather than making scrolling artefacts even more obvious. However it does look less like a lo-res display. If you really want that look I think your best bet would be to do something like the original retro games would have done and force it to move only on alternate ticks. You can do this fairly easy by enabling and disabling the platform behavior based on if it's an odd or even tick, and use a double speed of 60 instead of 30 in the platform behavior. This looks OK if you turn off the minimum framerate (since it reliably moves 1px on alternate frames), but then the parallax background hurts my eyes when blown up to a 2K screen, because it's not updating very often and creates a pretty bad flickering effect due to the parallax slowing down the scroll rate.

    Maybe a good compromise would be allow the player and scroll position to be smooth, but round the positions of the rest of the objects in the game.

  • It's much easier to investigate with confidence with a minimal .capx. I haven't sifted through the whole project, so this is only speculation from a glance, but I think it's because events 4 and 6 apply their own rounding to the scroll position. You really should not do this - turning on pixel rounding also rounds the scroll position. The best approach for this is to pretend scrolling is perfectly smooth, but let pixel rounding mode handle rounding the scroll position. In particular event 6 is using a different rounding (floor vs. round in another event), so these rounding modes could be doing different things creating a choppy motion. Removing these unnecessary rounds seemed to help.

    Also it looks like the speed you've chosen is 36 pixels per second. This will alias with the common screen refresh rate of 60 Hz. 36 pixels per second divided by 60 Hz = 0.6. Since you've enabled pixel rounding, point sampling etc. you can only scroll in whole pixels (by default you get smooth scrolling with sub-pixel positioning, but this is commonly turned off for retro games). However you have chosen a value that causes the object to move 0.6 pixels per frame. So then you will get an irregular pattern of scrolling one or zero pixels depending on the rounded total. It will look like this:

    Frame 0: position = 0, displayed at = 0

    Frame 1: position = 0.6, displayed at = 1 (+1)

    Frame 2: position = 1.2, displayed at = 1 (+0)

    Frame 3: position = 1.8, displayed at = 2 (+1)

    Frame 4: position = 2.4, displayed at = 2 (+0)

    Frame 5: position = 3.0, displayed at = 3 (+1)

    Frame 6: position = 3.6, displayed at = 4 (+1)

    Frame 7: position = 4.2, displayed at = 4 (+0)

    Note it had an on-off pattern until frames 5 and 6 which both advance 1 pixel - the 0.6 increment makes it irregular. This means that although I believe everything is working correctly in the engine, it still looks jerky - scrolling doesn't look good with irregular updates, the human eye much prefers regular updates. This is also why a speed of 60 looks better: it increments by a regular 1 every frame. dt variations will slightly randomise this too, but usually it's not so bad, with good v-sync it should fall within the rounding error. You can turn it off if you really want to by forcing a minimum framerate, but then you get the other shortcomings of a fixed step (weak devices run in slo-mo, 120Hz gaming displays run at double-speed instead of smoother, jank makes the game pause instead of moving past it, etc).

    Often people blame Construct 2 if something doesn't look good, but I think in this case no engine or technology is going to save you from these game design choices. Incrementing by 0.6 pixels a frame and displayed rounded to the nearest is always going to be irregular, due to maths, not code. For this kind of thing you either have to pick all your values super carefully so they divide in - but note they will break on displays with a different refresh rate! or if you use fixed dt, the game runs at a different speed on displays with a different refresh rate! - or just let it scroll smoothly...

  • I'm not sure what your particular implementation of "delegates" means or does. However the main point of fast triggers is to avoid iterating every trigger of that type. Normally firing a trigger runs every associated trigger in the event sheet, but fast triggers pre-filter by the first parameter. So running a function does not have to check every "on function" event in the project only to pass on most of them because they have a different function name - it only iterates the "on function" events it knows have the right name to begin with. This prevents there being a performance overhead to the "call function" action proportional to the number of "on function" events in the project (which would make functions slower the more you used them). However it had a laundry list of caveats that I can't exactly remember, like it only looked at the first parameter, it had to be a string, it had to be constant (no expressions that cannot be calculated at edit-time), etc... basically all specifically geared towards the "on function" trigger. I don't know if it will work for any other plugin, or if the performance impact would be important.

  • SCML is a third-party plugin, so please report it to the developer. Closing.