Refeuh's Forum Posts

  • I fail to understand the difference ?

    Import a sprite sheet, slice as needed to separate all the frames, move/remove frames or adjust speed if required, and we have an animation good to go -

    what am I missing that doesn't satisfy the initial request, i.e. importing a sheet to build animations

  • add sprite > sprite editor > animation window > right click > import frames > from sprite strip

    I believe that's what you're after

  • You can already sprite sheets ; C2 tries to guess the sizes/rows/columns, but you can force the slicing to make it match your sheet

  • There's a "move to object", with option to place in front or behind another item.

  • I have little experience with Android, but I believe it is now possible by bundling expansion files with the app (while the app is still limited to 50Mb, the expansion files can be up to 2x2Gb), or using a downloader in the core game.

  • There's a System condition "Is number NaN" that you can use to breakpoint or output as log

  • Wrong layer ? Wrong blending mode ? Wrong parameters on the default instance ?

    Just a few things to check, as creating sprites dynamically does not affect the quality.

  • One way or the other, it's still inconsistent - some Solids trigger a collision while some other instances don't ? And simply moving Solids that don't trigger collisions suddenly changes the behaviour.

    I think I am using the Platform/Solid behaviours as intended, but the result is inconsistent.

    Maybe Ashley can comment on the exact intended way to use/combine these behaviours, if that's not a bug

    My guess would be that is has to do with space partitioning and cell boundaries during the collisions broadphase, if there's one ; objects sitting on the boundaries not handled properly would explain that sort of logic. Though it's a total gutfeel.

  • I've exported the test scene and uploaded to dropbox, if it's quicker to review the bug without downloading / opening / running the capx before looking into the issue.

    https://dl.dropboxusercontent.com/u/526 ... index.html

    All 3 red blocks are instances of the same object type ; the red block in the middle never registers a collision when jumping onto it *only* because it's at a specific y position. See original post for addition repro info

  • Problem Description

    Top/bottom collision between a falling player controlled object (Platform behaviour) and a static Solid object consistently does not trigger when the Solid object is at a very specific location

    Attach a Capx

    Minimal capx with only 3 object types and 5 instances :

    https://dl.dropboxusercontent.com/u/526 ... onBug.capx

    Description of Capx

    Minimal sample scene : 1 ground, 1 player, 3 blocks

    • brown = static Solid used as ground
    • yellow block = player controlled, uses the default Platform behaviour
    • red block = static Solid (could be an enemy, a platform, etc.) to demonstrate the bug

    Logic is simplistic : flash the player object (1second) when an Enemy/Player collision is triggered

    Steps to Reproduce Bug

    • Move right and jump on the first block (#1) ; notice a collision is triggered and the player object flashes as expected
    • Wait for the flash to stop
    • Jump right onto the next block (#2) ; notice the player object doesn't flash as a collision is NOT triggered
    • Jump right onto the last block (#3) ; notice a collision is triggered and the player object flashes as expected
    • In the editor, move red block #2 (the one not triggering the collision) up or down a bit ; test again, this time it does trigger the collision properly

    Also notice that collisions from the sides (left/right) or from below (player jumping into red block #2 from below) always work consistently

    This unexpected "falling/top collision" behaviour only happens when a red block is at y=524 ; there are other specific y values showing the problem as well but I believe they are all instances of the same issue

    Observed Result

    Collisions are not triggered consistently depending on the position of the objects

    Expected Result

    Collisions should be triggered consistently regardless of the positions of the obects

    Affected Browsers

    • Chrome: YES
    • FireFox: ? (don't have)
    • Internet Explorer: ? (don't have)

    Opera: YES

    Edge: YES

    Operating System and Service Pack

    Windows 10 Pro 64b

    Construct 2 Version ID

    212.2 64b Steam

    Edit: updated affected browsers

  • Very limiting indeed, though it's unlikely to change ; from the manual :

    "Limitations

    Unfortunately due to the architecture of the Construct 2 engine, breakpoints cannot be placed in the following locations:

    • Anywhere inside a triggered event, including any sub-events to a triggered event
    • Anywhere inside a looping event (such as Repeat or For each), including any sub-events to a looping event

    In other words, only non-looping events which are checked every tick can have breakpoints set on them, or be stepped in to."

    Something to consider for C3

    It is to do with the nature and architecture of every engine, they all have their limitations. You can still use the JavaScript console of your browser if you know your way around it, and revert back to "old" debugging techniques such as outputting infos to a debug log / array / xml / etc. that you can inspect

    As for performance, it is expected with any tool or language that debugging will impact performance negatively ; simply due to the overhead of the debugging itself.

  • If I understand the problem correctly, this seems to be typically what is referred to as "tunnelling", i.e. solid objects moving at relative high speed going through each other.

    This can happen if the size and speed of Bob and Bar, and the framerate, are in a configuration when at frame n Bob is totally above the bar, and at frame n+1 bob is totally below Bar ; in this situation, Bob and Bar are never really in collision, since they move too much in one single frame

    The usual solutions are time slicing (moving multiple times in smaller increments in one frame) and continuous collision detection (CCD, using swept volumes), though I'm not sure how you would solve this in C2...

    You might try using a bigger hitbox to detect possible tunnelling, and then the accurate hitbox, in case of possible condition

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I haven't used it myself, but you can try GreenWorks :

    And congratulations on getting a game greenlit

  • >

    > Unity is pretty easy too, especially with playmaker

    >

    As far as I know Unity doesn't use the node system for programming, you can only do that with 3rd party plugins

    Well that's exactly what PlayMaker, mentioned above, does ; visual scripting

  • I think this would be a bit restrictive, in the sense we would lose some flexibility ; the layer system means we can split and mix & match bits of global layers the way we want, so that we can "include" relevant bits of gui/inventory/options depending on the context / levels / etc. To keep this functionality, we would still need a place to define what to include/display in each layer, which would make "automatic" global layers clunky