Ashley's Recent Forum Activity

  • The best thing you can do is make sure you open a window in a user input event, like 'On mouse button clicked' or 'On key pressed'. Hopefully then the browser recognises that the window opening is an action the user intended, and not some spammy popup advert.

    However, this doesn't always work - spammers still use the same method for opening popups. So some browsers (Firefox especially IIRC) will simply block all window opens anyway, and the user must approve it by clicking the notification. Users are probably fairly used to this. So you can either just have a note (e.g. "Warning: opens new window") so the user knows when they see the "popup blocked" it was actual content rather than some popup ad. Or you can just navigate the current page - that will end the game, but it always works. Or, just put the hyperlink in the page HTML outside your game.

    This is more of a general problem with web development than anything specific to C2 - everyone hates popups, and if you try to open a new window, you're at the mercy of popup blockers.

  • If you test "Sprite is overlapping Sprite" with 100 Sprites, Construct 2 must test for a collision between every combination of pairs of Sprites, which is about 100 x 100 = 10,000 collision checks per tick, which at 60 FPS is trying to do 600,000 collision checks per second. That kind of thing doesn't even run well in C++ engines, you're just asking for way too much processing to be done.

    A simple way around it is to maybe only check every 1 second, or come up with a simpler way of trying to do what you're doing.

  • There is no problem with having a very large number of global variables. There is no limit on them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Change the 'parallax' property on the layer you want to scroll slower. E.g. make the background parallax 30, 30.

  • Arima - I deliberately went with the "Or block" design because it is very simple. Allowing multiple conditions between ORs becomes significantly more complicated, both in the editor's rules for valid events, the usability and in the runtime engine. So I opted for something simple which is easy to use and robust.

  • What's wrong with using a global variable? What you've done looks fine. If you don't want the variable to be accessible anywhere else, move all that in to a group or subevent and it will become a local variable not available anywhere else.

  • AJTilley - check out this thread.

  • Worth checking the documentation for the full list.

  • Well you're right, OR is kind of broken in my first implementation in r86. I was a bit naive with the implementation - if you make an event:

    A or B or C: do actions

    it pretty much gets run as three separate events:

    If A: do actions

    If B: do actions

    If C: do actions

    I think the examples in this thread have proven that's totally broken, since if more than one condition is true and you toggle something, it gets toggled straight back. Whoops! Or movements speed up, counters get too much added, etc.

    Luckily I've already changed it for the next build. There might still be bugs in the next release, but it's changed to only runs the actions once even if multiple conditions were true. So

    A or B or C: do actions

    will run once if at least one condition was true. It also properly handles picking, so:

    + Sprite X < 320

    • or -

    + Sprite Y < 240

    -> do something with Sprite

    will now correctly run the actions once with the picked objects being those instances which match either condition.

    r86 kind of had a lot of bugs with the new event features! 'Else' and 'While' both have some weird issues as well. I think I've fixed everything for the next build though. Thanks for the feedback though. It's lucky we've got the beta and stable releases sorted out, this is kind of what we expected - smoothing things out over a few beta releases then getting a stable update out which hopefully works as expected.

  • Potato, you're right, in r86 OR is a bit weird and actually is equivalent to copying and pasting the event multiple times with each condition. Luckily I've already changed it for the next build - it will work more like a true logical OR, only running the actions once if any condition was true.

  • Thunder, aren't you just missing the layer parameter for the Touch.X/Y expressions?

    Both mouse and touch take an optional layer parameter, e.g. Touch.X("Layer 1"). If that's not provided, the returned value does not take in to account any layer's scale.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,774,353 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs