mekonbekon's Forum Posts

  • Mimitone, no worries, glad to be able to help out

  • Mimitone

    I think you need to be using the tiled background object for that tutorial rather than the tilemap object.

  • Glad to help

  • — You need to position your anchored object at 0,0; If you run the game in debug mode and check the coordinates you'll see that it still exists and is positioned outside of the viewport, so when anchored it remains outside. Anchoring fixes an object to the specified settings relative to its initial position.

  • Hi —, sure, you can send the file to or post a dropbox/google drive link here.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hard to say without seeing the capx, but here are a few guesses:

    Run the game in debug mode. Select the object and view its values; you should be able to see a dotted red outline on the layout when the object is selected:

    If it no longer exists in the object list then an action somewhere in your code is destroying it.

    If the red outline appears in the correct position and at the correct size then most likely it has either been set invisible, the opacity has been set to zero, or some other object is obscuring it; you can check the relevant instance values to determine if it's one of these options.

    If the object exists in the object list and the (x,y) coordinates are correct but no red outline is shown then either the object or the layer scale/size may be set to zero.

    If it appears to have moved and the (x,y) coordinates have changed then an action somewhere in your code is re-positioning it before anchoring.

    If it appears to have moved but its (x,y) coordinates stay the same then it may be that you have the origin set to different positions on subsequent frames (if the sprite is animated).

  • satellite23 If you have separate animations assigned for jump, fall, land, idle etc I would check that the frames for each animation are the same size, that the origin is in the same place on each and the collision boxes match. Otherwise what can happen is that on landing the animation changes, the new animation is overlapping the solid object and so has to pop itself out.

    An alternative to having the platform behaviour assigned to the animated sprite is to assign the platform behaviour to an invisible sprite object that remains a constant size and then pin the animated sprite (without platform behaviour) to the invisible object. You do all the platform and collision checks on the invisible object.

    If that isn't causing the issue then we have a mystery on our hands and it would be worth sharing the cp3 file

  • noahphoenix - if you set the scale rate for the hud layer to zero (in layer properties) then the objects on that layer should remain at the correct scale regardless of scale changes to the rest of the layout.

  • Bootfit: something like this:

    https://www.dropbox.com/s/hjg2pc3mnrq1h ... r.c3p?dl=0

    I've included two methods for representing the timer bar:

    1) The red bar's starting length is determined by unitWidthR x timerDuration, i.e. more time = longer bar.

    2) The blue bar's starting length is determined by widthMaxB regardless of timerDuration; instead it changes the rate at which it shrinks, i.e. more time = slower bar. This is useful if you have limited room for the bar or want to maintain sizes and positions of your HUD objects.

    timerDuration = how long you want the timer to run for

    unitWidthR = width of bar per second (only applies to the red bar)

    widthMax = standard length of bar (only applies to blue bar)

    unitwidthB = derived from widthMaxB/timerDuration (only applies to blue bar)

    You can fiddle around with these values to get an idea of how each bar is working.

    Hope that helps <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • —

    You're welcome, glad to be able to help out

  • You could do:

    timerBar.Width = timer*k

    where k = timerBar.maxWidth/timerStart

    k is a constant and can be calculated once at the start of the layout/round (assuming you're not changing the maximum bar width and the initial timer value on the fly).

  • Sorry, that was a C3 demo; here's a C2 one:

    https://www.dropbox.com/s/1igxvu9v9d2kn ... .capx?dl=0

  • —

    I was thinking about this same issue the other day; this might be a solution:

    https://www.dropbox.com/s/35vfsi9j0j8gw ... t.c3p?dl=0

    Each tick, the modulo (%) 10 of each sprite.IID is checked against the modulo 10 of the current tickcount and those with the same value are picked ((e.g. if the tickcount is 29, pick all the sprites with an IID that ends in 9).

    This means that each tick only 10% of the sprites are selected. You can pick less sprites per tick by increasing the value after the % sign.

    In the demo I've set it up so that the sprite's frame changes when picked - if you run the demo you can see the horizontal white band indicating the sprites that are picked.

    Now, I haven't stress-tested this to see how it fares when you have a lot of code affecting the picked sprites, but I'm guessing it should at least reduce some of the stutter.

  • AndreasR

    Thanks for the info, all very helpful

  • Hi,

    I made a few guides for that. Just see here.

    https://shatter-box.com/article-categories/android/

    Cheers AndreasR, I was actually looking at your Android APK sigining tutorial earlier today - I wasn't sure whether C3's APKS also needed aligning (and whether that's just something that is always required of a signed APK regardless of how it's generated).

    Also can I reuse my keystore file from a previous project or should I generate a new one?