fisholith's Forum Posts

  • Hey iScream,

    If I understand the events correctly, I think that the first sub event is unpausing the game, and the second sub event is immediately pausing it again.

    Consider the following walkthrough of the events:

    Timescale = 0.

    > User presses Escape.

    Event: On Escape pressed >>> TRUE

    __ Sub-Event: Timescale = 0 >>> TRUE - because Timescale = 0

    ____ Action: Menutext set invisible >>> Menutext is now invisible.

    ____ Action: Set timescale to 1 >>> Timescale is now 1.

    __ Sub-Event: Timescale does not equal 0 >>> TRUE - because Timescale = 1

    ____ Action: Menutext set visible >>> Menutext is now visable.

    ____ Action: Set timescale to 0 >>> Timescale is now 0 again.

    You'll need to make sure that only one OR the other sub event runs.

    You can use an ELSE condition to achieve this. Manual page for the ELSE condition

    Using the ELSE condition, would look like this:

    Event: On Escape pressed

    __ Sub-Event: Timescale = 0

    ____ Action: Menutext set invisible

    ____ Action: Set timescale to 1

    __ Sub-Event: ELSE (This will only run if the prior event, at the same indentation level, was false.)

    ____ Action: Menutext set visible

    ____ Action: Set timescale to 0

    Hope that helps out.

  • Ah, yeah, containers will take everything down with them if they get destroyed.

    Below are a few possible alternatives that might work in place of containers.

    Also, I posted the link to the tutorial you mentioned at the very end.

    UIDs & Private Variables

    As an alternative to containers, you can store the UID of the ArmObj in a private variable of the ArmDetectorObj.

    Then if ArmDetectorObj collides with lava, you can,

    Pick ArmObj by UID, (using the UID you stored earlier), and Destroy just the ArmObj.

    To make sure the UID gets stored correctly, you can Have the ArmObj's "On created" event be responsible for creating the ArmDetectorObj, and saving the ArmObj's UID into a private variable of ArmDetectorObj.

    Thus, whenever you create an ArmObj, it will automatically instantly create and link its very own unique ArmDetectorObj .

    Pin Behavior & "PinnedUID" Expression

    In some cases, if you are already using the Pin Behavior, you can use it's built in PinnedUID expression to get the UID of the pinned object, though this is more of a special case.

    Manual page: Pin Behavior

    Store Reference Behavior

    Another option that might be worth looking into is the third-party "Store Reference" behavior.

    It can be added to objects to make linking them in events simpler and easier to read.

    Forum page & Download: Store Reference Behavior

    • - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Here's the link to the tutorial you mentioned

    Understanding UID, IID, Health, Cards and Rocket smoke trail.

  • Hey SandvichEater,

    By odd chance I happened to have just finished responding to another question that had a very similar potential solution, so I hope you don't mind if my response below is a little cut-and-pastely.

    Because each enemy is comprised of a collection of unique object types, (some for the image and some for the detectors), you might be able to use the "Containers" feature of Construct 2, to associate all the objects of an enemy.

    Each enemy would get it's own set of detectors that would be automatically contextually picked whenever the parent enemy is picked, and vice versa.

    Containers will work as long as an enemy only needs one of each object type.

    For instance, if an enemy has a body and two ledge detectors, all as separate objects, then you'd need the ledge detectors to each be unique objects (e.g. leftLedgeObj, rightLedgeObj), as you can't put the same object (e.g. ledgeObj) in a Container twice. At least not to my knowledge.

    Containers page of Scirra's C2 Manual

  • Hey Mario4President,

    If each enemy is made up of a set of unique object types, then you might be able to use the "Containers" feature of Construct 2, to associate all the objects of an enemy.

    This will work as long as an enemy only needs one of each object type.

    For instance, if an enemy has a body and two arms, all as separate objects, then you'd need the arms to each be unique objects (e.g. leftArmObj, rightArmObj), as you can't put the same object (e.g. armObj) in a Container twice. At least not to my knowledge.

    Containers page of Scirra's C2 Manual

  • Hey YetAnotherSuperhero,

    One possible approach might be, rather than rotating the next segment around the middle of the edge, make each segment rotate around whichever corner is on the outer side of the bend.

    This way you don't have to fix gaps after the fact by moving things, since there will never be gaps in the first place.

    e.g.

    If the tunnel is moving rightward, then when the tunnel bends down, you rotate the next segment around the top corner.

    When the tunnel bends up, you rotate around the bottom corner.

    This means the tunnel segments will always be fully overlapping where they join.

    Here is an example capx.

    GaplessWindingPath

    In this example, the path segments have been made semi-transparent, so you can see how they overlap.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey Minjaware,

    It sounds like you might be using the standard Text object. If so, that might be the issue.

    Sprite Fonts vs Standard Text

    If you use a Sprite Text object instead of standard Text object you should be able to get exactly the same result across all browsers. By contrast, the standard text object may not always get rendered as the same font from browser to browser, much less be rendered in exactly the same position.

    The unpredictability of font rendering across browsers is not a bug in C2, as far as I know, but is just a side effect of different browsers all using their own method for rendering text.

    By using a sprite font, you guarantee that C2 is directly responsible for rendering the text, directly from bitmap images, and so it will appear consistent everywhere.

    Using Sprite Fonts

    While it is a bit less convenient to work with Sprite Fonts, there are a few community made tools that make using them much easier.

    Sprite Font Generator - v2

    Sprite Font Generator is a freeware stand-alone font to sprite font conversion tool. It also generates all the JSON code needed by C2 to space and size sprite font characters, and it has a graphical interface.

    Sprite font +

    Sprite font + is a plugin for C2 that can take the JSON code for sprite fonts as a parameter, and will display (in the editor) the correctly sized and spaced character as they will appear at runtime.

    Tutorial, for Sprite font +

    Tutorial showing how to use "Sprite Font Generator" with "Sprite font +"

    Hope this helps out.

  • Hey YoHoho,

    You might be able to use either the "Destination In" or "Source In" blend mode.

    You would need to make the magnifying glass out of two sprites,

    (1) the image of the magnifying glass, and

    (2) a "mask" for the glass area of the magnifying glass.

    This mask sprite would have it's blend mode set to "Destination In" if you wanted items under it to become visible as the glass mask passes over them.

    Alternatively, you can use "Source In" if you want the glass mask to reveal objects above the glass.

    To see examples of these blend modes in action, you can open the blend modes example project.

    In Construct2, from the main menu, choose New, and scroll down to, and open, "Example: Blend modes".

    (You can also search for "blend" in the search field, instead of scrolling to find it.)

  • Thanks for the reply AllanR,

    I double checked the polygons but they were just bounding squares around objects that are squares. The individual vertices are all at integer coords, so I don't think the polygons are off. Likewise if I actually just set all the objects to bounding box collision mode (rather than polygons) I get the same gap.

    Setting the collision mode to circles seems to produce the nearly perfect collisions I recall from older projects, but unfortunately, my objects are not all circles, so that's not really a long-term solution.

    The "web" version of Box2d does seem to be quite a bit better with a gap about 1/4th or less than the size of the "asm.js" version.

    It almost seems like the collision poly lines themselves have some kind of line-thickness.

  • I just started working on a new physics based project, and I noticed that the physics objects, when pressed against each other, don't quite touch, as if there's an invisible 1 pixel wide force-field separating them. It doesn't appear to be a rendering issue, as when I set the layout zoom to 4x, the gap increases proportionally, becoming about 4 screen pixels wide.

    In older projects physics collisions appeared perfectly accurate up to 10x zoom, much less 1x.

    I don't recall ever seeing this happen in any prior projects.

    I now can't get precise collisions to work in any new projects.

    Is there something that changed in the physics behavior, or is there a setting that might help?

    Any thoughts or suggestions welcome.

  • Hey fundation2000,

    The effect shown in the image looks to be a per-pixel light ray shader.

    If you have some familiarity with shaders, you can actually make your own using the Construct 2 SDK. Construct 2 shaders are coded in GLSL.

    I've been making shaders off and on for a while, so If I end up building that shader myself at some point, I'll let you know.

    You can also try creating a very similar effect with C2's built in lighting system, but I suspect that it won't have the same per-pixel fidelity seen in the image above. That is because the C2 system casts shadows based on collision polygons instead of individual pixels.

    That said, using C2's built in lighting, you could create a lighting system on it's own white layer, such that you're casting black shadows onto a white background. You could then use effects to invert the layer colors, so you're now casting white shadows onto a black background, and finally "Screen" blend that into the final scene, and adjust the layer opacity to make it more subtle. Screen blending will make the black area appear transparent, and the white rays will act like an illuminated haze.

  • One approach is to use two images, one for the faint Shield (full-circle 360° arc), and one for the bright Impact arc area on the Shield (say about a 90° arc of the circle).

    Making the images

    The key is that you create both images, the Shield and the Impact arc, so that they are the same size, and both with the hotspot at the center of the image.

    The easiest way to do this is to start by making both the Shield and the Impact image full circles. Each image should have its hotspot centered in the circle. Then for the Impact image, which is just a bright circle so far, we soft erase away everything but the right-most quarter of the circle, so that the result is a mostly blank image with a hotspot in the middle, and a bright quarter circle arc on the right edge of the image.

    Behaviors & Events

    Now if you snap both the Shield sprite and the Impact sprite to your ship, the Impact arc should line up perfectly with the right edge of the Shield bubble, as if the ship had been hit from the right. If you click the Impact sprite and grab the rotation handle, rotating the image should make the Impact arc slide around the edge of the Shield.

    Now to make it stick to the Shield bubble as the ship moves, and also fade out over time.

    For the Impact image, add the behaviors "Pin" and "Fade".

    In the event sheet create the following setup:

    When a projectile hits the Shield bubble:

    * Have the Shield spawn a new object, the Impact sprite. (The Impact sprite should automatically be centered on the Shield.)

    * Set the Impact sprite's angle towards an object, the projectile. (If you need to destroy the projectile, do it somewhere after this step.)

    * Pin the Impact sprite to the Shield. (This way when the ship moves, it won't leave the Impact sprite behind.)

    The fade will run automatically, and destroy the Impact sprite after fading out.

    Final optimization

    Finally, if you have everything working the way you want, you can crop the Impact sprite image using the crop button at the top of the image editor. This will cut the image size down to just the actually image area, and leave the hotspot in the correct relative position. Just a minor optimization.

    Hope that helps out.

  • The replace feature, (as far as I know), has loosely two modes.

    If there's only one object available to replace:

    Pops up an object browser, and whatever you choose will replace the original object.

    If there are two or more objects that can be replaced:

    Pops up an object browser showing the objects that can be replaced, and whatever you choose will be designated as the object type to be replaced.

    Then you will be presented with another object browser, and whatever you choose will replace the object designated on the previous step.

  • Hey Ashley,

    Thanks for the reply. I figured that might be the case. It makes sense that it would be set up to work just on the 100% parallax layers, as that's going to be pretty much all the practical cases.

    As for setting all layers to 50% parallax, I agree that that would be pointless, I was just using it as a simple example of paired layers with matching parallax.

    I actually happened to be faced with a special case that is related to that example, but a little more complicated, in which I would have several layers that would have variable parallax rates, but the parallax rates would always all be the same value across all the layers, or at least all the layers for which collision detection matters.

    Reason being, I figured out a way to scroll layers completely independently of each other, which I've been interested in for a while, but the method involves keeping the scroll coordinates fixed and adjusting the parallax scales of each layer instead. The parallax scales for each layer become the individual scroll coordinates for that layer. It works, but I was worried that the weird parallax values would break the collision optimization, and it sounds like they would. In this case the game world layers would all have the same parallax scales, and would stay lined up, but they wouldn't always be set to 100%.

    The main reason I've been interested in scrolling layers independently is that I'd like to be able to have a "game" world that scrolls normally, and an overlay-able "menu" system that can scroll from page-to-page independently of the game world. Currently there's no way that I know of to decouple the scrolling of the menu layers from the scrolling of the game world layers.

    I'm aware that it's technically possible to make a system that kind of approximates the en-mass coordinate shifting that layers can do, but it seems a bit tricky to make it play well across multiple object types, and with anything else that effects coordinates, like behaviors, or for that matter Particle object particles, which don't move with the source object.

    I've seen some other threads talking about independently scrolling layers, and it sounds like it's not currently planned. For what it's worth, I think it would be a cool feature, but I can also definitely understand why it might not be a priority.

    In any case, thanks again for the info.

  • Thanks for the reply jobel,

    Yeah, I don't plan to have misaligned layers with collisions between them, I agree that could get ugly.

    What I mean is if I have, for instance, just one layer, and it's parallax is set to 50%, will that disable optimized collision detection for everything on that layer?

    And the slightly more complex scenario is, if I have two layers both set to 50% parallax, so both layers are still always in alignment at all times, will the 50% setting disable optimized collision detection for everything on both layers?

    I'm just not quite sure what situations cause C2 to forgo optimized collision detection. I think it might only use the optimization for layers at 100% parallax, and will brute-force anything else. That might kind of make sense, as there may be only one data structure handling spatial binning, instead of one data structure for each parallax configuration found in the layout.

  • I gather that C2 does some kind of spatial binning based on the project's window dimensions to optimize collision detection.

    If I set all layers to use a 50% X and Y parallax rate, all layers will still always be in alignment, but will this disable optimized collision detection across all layers?

    That is, will layers use optimized collision detection between each other if they line up, or only if they are at exactly 100% X and Y parallax rate?