tulamide's Forum Posts

  • There is an issue with 'or'. I think I found the possible reason for it some time ago, and wanted to work on it now that I started helping with Construct Classic development. But I currently don't have a pc, I can't work on it.

    Here is the link describing the possible issue: http://www.scirra.com/forum/viewtopic.php?f=3&t=7428

  • I hope I don't misunderstand you, but every expression does its job on every tick, unless it is forced not doing so by using conditions.

    + Always

    -> Add 1 to a

    -> Set b to 1

    This will add 1 to the currrent value of a (whatever it is) on every tick as well as setting the value of b to 1 on every tick.

    Tick 1

    a = 0

    b = 0

    doing always-event:

    a = 0 + 1

    b = 1

    Tick 2

    a = 1

    b = 1

    doing always-event:

    a = 1 + 1

    b = 1

    Tick 3

    a = 2

    b = 1

    doing always-event:

    a = 2 + 1

    b = 1

    etc.

    But using another condition breaks it:

    Tick 3

    a = 2

    b = 1

    + a less than 2:

    a untouched

    b = 1

    EDIT: Add to value is nothing more than a shortcut for n = n + 1

  • pyteo, I would love to investigate your caps, but I don't have Construct for a while. Whatever it is, there's something wrong with the sizes. Not only in theory but practically 4 256x256 textures consume the same texture memory as 1 512x512 texture.

    I once made an example for effective slicing, where I could prove that a bunch of sprites with totally different sizes (1x2, 256x32, 512x512, etc.) formed a picture of the size 700x700. A picture of that size needs 1960000 bytes of texture memory (1.87 MB), and all the sprites combined used exactly that size of texture memory.

    Here is the link to that post: http://www.scirra.com/forum/viewtopic.php?f=8&t=7786&p=60406&hilit=vram#p60406

    A 256x256 texture takes up 256 kB of texture memory.

    A 512x512 texture takes up 1 MB of texture memory.

    If you are experiencing other values (like 1.5 MB for 4 256x256 textures, or 3.5 MB for the 512x512 one) then there is something wrong. Graphic card reporting wrong sizes, driver issue, not exactly cut images, Construct reporting wrong sizes, I really don't know...

    It would be interesting to find out what is going wrong in your cap, maybe someone else could check it.

  • I made some examples using the date object as well as timer. If everything is set up accurately it works reliably.

    For counters, I recommend using the system expression timer only. The technique is straight forward: Whenever a countdown is needed, set a timestamp. Compare timestamp against timer and that's it. timer returns the time passed since start of the game, it does not reset across layouts, so you can rely on that.

    + bomb('armed') = 1

    -> bomb('timestamp') = timer

    -> bomb('time') = 35

    -> bomb('output') = 35

    -> bomb('armed') = 2

    + bomb('armed') = 2

    -> bomb('output') = floor(bomb('time') - (timer - bomb('timestamp')) / 1000)

    ++ bomb('output') <= 0

    --> bomb('armed') = 3 (signal for explosion code)

    ++ Else

    --> Set text to "0:" & right("00" & bomb('output'), 2)

    Or have a look at the examples (like Verve!, etc.)

    For using the counter across several layouts, make bomb global.

  • Damn, you're killing me

    But I'll do my best to make a third attempt.

    Distance from edge in pixel:

      d = DisplayWidth / 100 * desiredPercentage, e.g. d = DisplayWidth / 100 * 10 or just use a fixed value based on the display size, e.g. d = 100

    To get the "real" value:

      d = d * (100 / ZoomX)

    Applying left aligned:

      -> Scroll to x PlayerSprite.X - d + (DisplayWidth / 2)

    Or applying right aligned:

      -> Scroll to x PlayerSprite.X + d - (DisplayWidth / 2)

    I sincerely hope it works

  • In my opinion, using Python makes sense whenever complex custom data structures, inheritence or reusable code is needed. For the latter it wouldn't make much sense to "hardcode".

    from math import *

class Magnet(object):

    def __init__(self, centerX=0, centerY=0, radius=200):
        self.center = (centerX, centerY)
        self.radius = radius

    def lerp(self, a, b, x):
        return a + (b - a) * x

    def attract(self, construct_object):
        a = self.center[0] - construct_object.X
        b = self.center[1] - construct_object.Y
        c = max(self.radius * 0.5, min(self.radius, sqrt(pow(a, 2) + pow(b, 2))))
        f = self.radius / c - 1
        construct_object.X = lerp(self.center[0], construct_object.X, f ** System.TimeDelta)
        construct_object.Y = lerp(self.center[1], construct_object.Y, f ** System.TimeDelta)[/code:3jh1c5m5]

The script could now be saved, e.g as magnet.py, to ...\Data\Python\ and then be reused in every project with every object that has X and Y properties:

+ Start of layout
-> Script[code:3jh1c5m5]from magnet import *

myMagnet = Magnet(300, 300, 224)[/code:3jh1c5m5]

+ Always
-> Script[code:3jh1c5m5]myMagnet.attract(Sprite)[/code:3jh1c5m5]

Clean and simple 

(Please don't test if the code is actually working, it was just a quick written example to show the principle)

  • Changed host to dropbox, hope it works now...

  • Yes

  • I'm not sure what you mean. My avatar is not shown? I didn't change anything and I can still see it...

  • Ok, so you need to calculate the scroll center based on the player sprite. When the player sprite is at x = 300, then the left edge of the visible screen should always be 200, no matter the zoom. And when it is at x = 960, then the left edge should be 860, etc?

    Scroll to x

    PlayerSprite.X - 100 + (DisplayWidth / 2) * (100 / ZoomX)[/code:3hqapjqi]

[i]Without being able to validate it, I don't have Construct at the moment[/i]

  • You mean 100 "unzoomed" pixels, while zoomed?

    When zoomed to 200% every pixel uses 2x2 "unzoomed" pixel, so you would need to move the cam 50 pixels to the left instead of 100. So I would say it is

    currentX - 100 * (100 / zoom)

    EDIT: Ups, to the left, sorry. Corrected to minus...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Don't worry, your progress is saved per level

  • The really cool games deserve to be played...

    A house in California

    e7

    Have fun

  • Yes, that will be it.

    The first layout has the number 1, if you would have a total of 3 layouts, then number 3 is the highest number you can go to.

    The problem of counting 2x per level could be that the condition for counting up ist still true when entering the new level. Unfortunately, my pc is broken-down, and this 11-year old antique computer I have to use until my pc is repaired refuses to install Construct, so I can't look into the cap.

  • There are a lot of possible causes for this. One of the most common is using two conditions one right after the other for switching. If that's the case here, then this post may help you.

    Also, check for a correct animation frame speed.

    If both tips don't help, setting up a demo cap showing the problem helps a lot helping you