Static HUD Differently

  • What are the other ways to make a static HUD without having a layer with parallax (0,0) ?

    If there are any of course

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Have you tried the pin behavior?

    Otherwise,

    Every tick> set x position to x coordinate of ViewportLeft +whatever number of pixels and set y position to y coordinate of ViewportTop +whatever number of pixels

    cheers.

  • Have you tried the pin behavior?

    Otherwise,

    Every tick> set x position to x coordinate of ViewportLeft +whatever number of pixels and set y position to y coordinate of ViewportTop +whatever number of pixels

    cheers.

    I can't get it to work, should it look something like this ?

    Every tick > Set Position > X=ViewportLeft(10), Y=ViewportTop(10) ?

  • No. the number in parenthesis should be the layer number.. for example, the top most layer. probably layer 3.

    Every tick > Set Position > X=ViewportLeft(3)+32, Y=ViewportTop(3) +32

  • No. the number in parenthesis should be the layer number.. for example, the top most layer. probably layer 3.

    Every tick > Set Position > X=ViewportLeft(3)+32, Y=ViewportTop(3) +32

    The set position works now, however the HUD is not visible for some reason.

  • bump

  • It may help if you share your capx.

    P..S - Are you just experimenting with this idea or is there a reason why a different layer with parallax of 0,0 is a no-go?

  • Double post :/

  • > It may help if you share your capx.

    >

    > P..S - Are you just experimenting with this idea or is there a reason why a different layer with parallax of 0,0 is a no-go?

    >

    I'm using free version and I'm already using 4 layers. This game is for my school project so I could delete layer with parallax effect to make the HUD, but I don't want my game look like shit.

    I can't post URL so I can't share my capx

  • Hey deropke2,

    I'm not entirely sure I recall all the limitations of the free version but I think the following setup might be an option...

    "ScrollTo" & "Pin" Behaviors

    If you create a sprite object (e.g. named "camTarget") and scroll the camera to it using the "ScrollTo" behavior, you can then move the camTarget object to move the camera.

    As an added bonus, you can pin other objects to camTarget and they will follow the screen around.

    This means you don't have to fiddle with typing in pixel offsets in events to position the hud items. You can just position hud items in the editor, wherever you want them to appear, relative to the camTarget object.

    The HUD items will keep their positions relative to camTarget, and camTarget will always be centered. You'll need to enable "Unbounded Scrolling" in the layout properties, to make sure the camera can stay centered on the camTarget even at the edges of the layout.

    Another benefit of this setup is that it requires almost no events, just 1 per pinned HUD element. Or if you use families, 1 per pinned object type. (e.g. Put all the HUD sprites in a fam, and pin the fam. Put all the HUD text in a fam, pin that fam. That's just 2 events.)

    Behavior/Event sequencing Problem

    There is one possible problem though. Behind the scenes, behaviors work like invisible events. The problem is that you can't (to my knowledge) control exactly when behaviors execute their event-like effects.

    This means that the position updates executed by ScrollTo and Pin, may occur always after or always before your actual events. (I forget which) And the danger there is that, if you try to stick the camTarget to your main character with an "every tick" event, you may find that the behaviors are updating the camera position before your custom events move your main character.

    That is, the behaviors move the camera to your character, THEN your custom events move your character somewhere else, THEN the frame is rendered and the camera is looking at where your character was.

    This means that your character will always be one frame ahead of the camera position which will look stuttery. One work around is to also use the Pin behavior to pin and un-pin the camTarget object to your main character, so that the entire camera movement system is handled through Behaviors. That should minimize the possibility for behavior/event sequencing problems.

    C2 online manual

    In case you're interested, you can read more about those behaviors in the C2 manual at the links below.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)