tulamide's Forum Posts

  • I'd sample the player's position to calculate the angle. Add two pv to buffer .X and .Y

    + System: Start of layout

    -> Sprite: Set 'lastX' to.X

    -> Sprite: Set 'lastY' to.Y

    + System: Always (every tick)

    -> Text: Set text to "Current slope angle: " & angle(Sprite ('lastX'), Sprite ('lastY'), Sprite.X, Sprite.Y)

    -> Sprite: Set 'lastX' to.X

    -> Sprite: Set 'lastY' to.Y

  • If I check for 'Is Overlapping', then I expect it to be a continuous check and not a one time result. And perform actions according to "as long as overlapping". If I wanted them to be executed once I'd use the 'perform once' expression.

    But this way it would be useless in a while loop, unless I used the System Condition.

    In other words, if I applied actions to the Sprite Condition, it would make no difference if they are in a while loop or not, this way. It would behave the same.

    I know what you mean, although we don't have exactly the same point of view. I wouldn't expect sprite's "is overlapping" to bahave as it does, but I wouldn't expect the system's one to behave as it does, either!

    And here's why. CC is a tick-based system. Every tick is like a short period of stopping the process. You can do whatever you like within that tick, and everything gets computed, and the whole process will continue as soon as you are done. So one tick may use 10ms to get computed, another one may need 2 seconds. But I'd expect consistency, everything that's true at the beginning of a tick should be true throughout the tick. Of course that would render loops within a tick almost pointless, but one could rely on the status of a tick.

    I suspect that "Blue Sprite overlaps Red Sprite" is only checking before entering the tick and then gets confused by continously asking for the state of that Blue Sprite while at the same time altering its position value. I come to this conclusion, because I can make it work, if I avoid using the overlap condition as a while-condition.

    + System: Always (every tick)

    -> Sprite: Set position to MouseX, MouseY

    -> System: Set global variable 'done' to 0

    + Sprite: Sprite overlaps Sprite2

    -> System: Set global variable 'done' to 1

    + System: While

    + System: Is global variable 'done' Equal to 1

    -> Sprite: Set X to.X - 1

    ++ Sprite: [negated] Sprite overlaps Sprite2

    --> System: Set global variable 'done' to 0

    Believe it or not, this one works. The only difference is that the while-condition is a test against a value of a global now, and that global will be altered in a sub-event that checks for overlapping, again. Confuses me.

  • you can get the number of the selected line with the expression "Get selected line number" or ListBox.SelectedLine

    + ListBox: Double clicked

    -> Text: Set text to ListBox.SelectedLine

    This would set the textbox to the current line number selected by the double click.

  • Now when I do it like this:

    + Always

    -> Sprite1: Set X to MouseX

    -> Sprite1: Set Y to MouseY

    + While

    + System: Is Overlapping(Advanced) Sprite1 (PICK) Overlaps Sprite2 (PICK)

    -> Sprite1: Set X to .X - 1

    It works. (The Pick option doesn't even matter in this case, even when I didn't pick either it worked)

    This is where my advice is important: Take care of the trigger.

    There is a difference between them both. Sprite's overlapping condition is like a one time switch. If it is true, it is true at the beginning of the tick, and loses its state as soon as we do an action (yes, gets invalid within the tick). Therefor the while-loop will only be executed for exactly one iteration.

    The system condition on the other hand is like asking for the current status, without changing it. Therefor the while-loop will go through all iterations needed, until asking, if both are overlapping, returns false.

    To prove that, you could add a global that you raise by 1 for every iteration of the while loop. You will then see, that it will only raise by 1 for every tick, if you use sprite's overlapping condition, but raise by whatever pixels needed, if you use the system's condition.

    Don't ask me though, why the sprite's overlap condition behaves that way. <img src="smileys/smiley36.gif" border="0" align="middle" />

  • I don't know if something like this works?

    cbe005.chat.mibbit.com

    That link opens up mibbit's connect page, where one enters a nick and then goes to the construct channel. But maybe that only works like the old one, just until mibbit changes something again.

  • No, it's not a bug. It is just you thinking way too complicated :D

    Serious, a while loop will normally be executed within one tick. But if you use triggers to start the while loop that will be true for a couple of ticks, then it will loop a couple of ticks.

    Try this:

    + System: While

    + Sprite: X Less than 640

    -> Sprite: Set X to .X + 1

    Now if you use a textbox and an always event with

    ->Text: Set Text to TickCount

    you will see that the sprite is immediatly at x = 640

    The loop will be checked on every tick, but since the sprite is at 640 from tick 1 on, it won't be executed.

    If you'd set .X to 300 or whatever in the always event, then the while loop will be executed (and will iterate 340x) on every tick, not just once.

    So, take care of the trigger and make sure the while loop will only be run once and when needed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I see.

    I never worked pixel based, because I prefer time based, but couldn't you just make your own push out routine?

    If the player sprite overlaps the left side of the ellipse, then repeat sending the player sprite to .X - 1 until it doesn't overlap anymore.

  • I wouldn't know of any way of getting those informations, unless you know the shape of the object and calculate it.

    But what you describe sounds like a typical job for a pixel shader. Is there a reason for trying to do it on the cpu side?

  • Maybe this one?

    Subscribe to Construct videos now

    Found it after a little websearch, but never tested it myself. I just saw, that there was no limitation for entering the tilesize.

    Download link is in the description.

  • I'm not a pro when it comes to irc, but clicking the link firefox offers me to send that to mibbit, and it works. I'm in. Finally. Thank you! :D

  • I can't log into the chat for several weeks now. All I get is a black window. Could someone post the correct url? This one ("http://wbe04.mibbit.com/?settings=&server=irc.esper.net&channel=%23construct&noServerMotd=true") doesn't work for me.

  • Ah, good to see your edit. I was just about to tell you I couldn't reproduce it.

    Btw, when checking visuals and values using the debugger, especially when using a very low fixed frame rate (like 1 fps), you might get confused because of the parallel processing.

    What you see is the result of the tick before, not the actual tick. While the graphic card processes the results of tick n, sent by the cpu, the cpu processes tick n + 1.

  • Try anglelerp from lucid's math plugin - it always lerps to the smallest angle difference, even if you cross the 0� barrier.

  • Sent you a pm.

  • But everything is in there. Just adapt it to your project. For every mirror create an out-beam just like I did in the example, just keep track of the id.

    Just enumerate the mirrors and out-beams and instead of my "Start of layout" event, use a trigger to create mirror and out beam.

    And instead of just setting the mirror values, use a "for each mirror"-loop.