SoupOrWorm's Recent Forum Activity

  • I just encountered another really weird bug. I am trying to make the movement loop stop if you run into another unit, but for some reason no matter what I try it just doesn't work. It always keeps going until the loop ends. How do I stop it?

  • Changing the timescale wouldn’t do anything about making it run faster, and ideally you wouldn’t use any waits. Wait 0 is a handwavy way to address a quirk with the picking system related to when stuff is actually destroyed or when created objects are generally pickable. It’s not that it takes time to happen, it’s more that the objects are actually added/removed from the object lists in between top level events (events that aren’t sub events of anything).

    Anyways another benefit of using an array is you avoid all the nuance when dealing with picking.

    I've got another question. Is there a way that I can check if a sprite is overlapping a position on the array (multiplied by 20)? I can probably find a workaround with the linepoint sprites that I already put in, but I'm sure it would perform better if I can just check if it is overlapping a position and then check the array to see if it is a 0 (red) or 1 (blue).

    Edit: I found a way to make it work and it still runs surprisingly well, but it doesn't use my performance box technique and it requires a loop to run a bunch of times a second which is still probably not ideal for performance.

  • Changing the timescale wouldn’t do anything about making it run faster, and ideally you wouldn’t use any waits. Wait 0 is a handwavy way to address a quirk with the picking system related to when stuff is actually destroyed or when created objects are generally pickable. It’s not that it takes time to happen, it’s more that the objects are actually added/removed from the object lists in between top level events (events that aren’t sub events of anything).

    Anyways another benefit of using an array is you avoid all the nuance when dealing with picking.

    Yeah it actually makes sense that it's a picking problem. I don't see another way around this so I suppose now I have to use the array method.

  • > I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

    > Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

    > I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

    I see... thanks for the response! Edit: after looking into it more it doesn't seem to be a performance issue anyway. I think my code is just busted.

    Hmmm... okay, so the issue seems to be caused by multiple things:

    1) I had it wait a seemingly insignificant time before calling the DrawLine function, but forgot that I set the time scale way lower since then. Making it wait 0 seconds makes the stuttering problem way better.

    2) It actually does seem to partially be a performance thing. Lowering the time scale more helps a bit, but still doesn't completely eradicate the issue.

    By now it doesn't seem to miss any points, but it can still stutter for a second. Good enough I suppose.

  • I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

    Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

    I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

    I see... thanks for the response! Edit: after looking into it more it doesn't seem to be a performance issue anyway. I think my code is just busted.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

    https://www.dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p?rlkey=x69nftupmwepk22idoycmf8vj&st=uhxgwm1i

    That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

    Ok so it works and runs great now with only 1 unit attacking, but with multiple attacking at once it seems to glitch out a bit and not show them properly. I can only think of 2 reasons for this; Either running the function twice at once is problem for some reason or it is a performance thing. Assuming it is the latter, do you mind elaborating a bit on your array idea, (assuming it is compatible with my update box technique) R0J0hound?

  • Well, I found a fix. Let us never speak of this again.

    Now to write an algorithm to connect the dots...

  • > > You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

    > > dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

    > >

    > > That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

    >

    > Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

    >

    >

    >

    >

    >

    >

    It seems that this optimisation causes a bunch of points around the edge of the square to not appear properly. I'm not sure what could be causing that, but I'm working on a fix.

    I still haven't found a solution to this. Could anyone help me out? I can upload the file if you need it.

  • > You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

    > dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

    >

    > That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

    Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

    It seems that this optimisation causes a bunch of points around the edge of the square to not appear properly. I'm not sure what could be causing that, but I'm working on a fix.

  • You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

    https://www.dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p?rlkey=x69nftupmwepk22idoycmf8vj&st=uhxgwm1i

    That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

    Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

  • You're probably on the right track for a way to do that. Basically, drawing to a 2d grid and then looping over it to find the edges.

    Your screenshotted events aren't working because you first pick one point, but you can't pick the second point when the first is already picked. A quick fix would be to add a "pick all point" condition after the finding if the point was blue.

    It seems to be working; Thank you! The only issue now is that it is insanely laggy. Any ideas on how to optimize this?

  • Ok so I got s'more progress. I tried writing the algorithm that places the line points, but it doesn't seem to be doing anything. I have a hunch that it is because of the "pick" command, because I don't really know how to use that. Please let me know if you see any potential bugs (the code runs when the player moves into a blue area, changing the point to red and thus updating the line. also, the bottom 2 lines are copy pasted and altered beneath the screenshot so it also checks and places above, below, and down, in theory at least.)

SoupOrWorm's avatar

SoupOrWorm

Member since 7 May, 2021

None one is following SoupOrWorm yet!

Trophy Case

  • 3-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

7/44
How to earn trophies