LittleStain's Forum Posts

  • you could also do a:

    for each sprite (ordered by sprite.x, ascending): set lowestx to sprite.x; stop loop

    for each sprite (ordered by sprite.x, descending): set highestx to sprite.x; stop loop

    etc.

    set scrollx to (highestx+lowestx)/2

    set scrolly to (highesty+lowesty)/2

    and calculate the zoom according to your aspect ratio etc.

    Much better solution.

    I'm so not into loops, haha..

  • You are asking us what your game should look like?

  • I guess it will only work with four variables and then something like this:

    LowestX

    HighestX

    LowestY

    HighestY

    every tick

    Set lowestX to 99999999

    Set HighestX to -9999999

    Set lowestY to 99999999

    Set HighestY to -9999999

    for each player

    if player.x < LowestX

    set Lowest.X to player.x

    etcetera

    and then you can change the example from above with these Global Variable values

  • In theory the program should indeed freeze while the event is repeated 2 Million times.

    I must admit it seems the mouse-clicks are being registered while the eventsheet is executing and as such used the next time the eventsheet is read (which is actually kinda logical when you think of it, when would mouse-clicks be registered otherwise?).

    I'm not sure why anyone would need a loop repeating 2 million times, though..

  • First of all I don't see any functions, just a loop for 2.000.0000

    this means you are processing 2 million events in one tick.

    if you set the loop to start the next tick (by adding a wait 0 command) it works.

    https://www.dropbox.com/s/73jo0hdu8tmpr ... .capx?dl=0

    It's not saving up extra presses as far as I can see..

    In your example there is a timer function which is restarted every time you click..

  • Using the search I found these two topics:

  • Could you give an example of what your function looks like?

    As far as I know a function is a triggered event that will be handled in the tick it is called, unless you use wait actions inside the function itself.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • ehhhmm..

    Aren't the functions performed in one tick?

    What is it that should be waited for?

  • I guess you'd just want something like this:

    system every tick - monster 8 direction simulate pressing left.

    monster on collision with "whatever" - monster play attack animation

    monster on finished attack animation - "whatever" destroy

    If you want more complex movement and/or other ways to control the monsters you'd need extra conditions.

    You might also want to look at the line of sight behaviour and pathfinding.

  • If there is no difference, why would one be better than the other?

    When to use it?

    Given the trade-offs above, the ideal case for render cells is when using large layers with lots of static objects. Remember unlike collision cells, this can include parallaxed layers. For example an ambitious game may involve thousands of scenery objects strewn across a huge layout. Providing few of those scenery objects ever change, then enabling render cells for the layer should save a lot of work checking whether or not thousands of far-away objects are in the viewport.

    Remember render cells can be enabled or disabled for individual layers. So you can enable render layers for a "static" background layer with rarely-moving scenery objects, and leave them disabled for other layers where lots of action happens with moving objects.

    When to avoid it?

    Any layers with lots of changing objects - either creating, destroying, moving or changing Z order - will probably incur more extra work than is saved by the cheap viewport checks. Also single-screen games should definitely not use render cells, since there is never much off-screen that needs skipping! The game will only be burdened with pointless extra work. In these cases using render cells could actually reduce the framerate.

    As ever, the key is to measure performance. If it's right for your game, you should be able to identify a measurable improvement to the framerate or CPU utilisation as measured by Construct 2. Don't turn it on assuming it will be faster - it could in fact be slower!

  • I'm sorry the question is still not very clear to me..

    When tapped a monster appears - this should be simple

    on tap - create monster at touch.x,touch.y

    I'm not sure what you think the bound to layout behaviour will do..

    How should the monster decide to which castle it goes?

  • From what you are saying I don't understand why your pc wouldn't be able to handle it, could there be other issues?

  • Well you could get the angle between the player and touch with:

    angle(player.x,player.y,touch.x,touch.y)

    after that it's just a matter of using the 8 direction simulate control action depending on the angle.

  • I'm not really sure if this is what you are trying to achieve, but:

    --- platcounter x<768

    platcounter set x = platcounter.x+platcounter.width

    platcounter spawn platform

    or

    --- platcounter x<768

    platcounter spawn platform

    latcounter set X = platcounter.x+platform.width