SoupOrWorm's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.)

  • Update: I've been thinking about this for a while and I think that the best way would be to use loops to put a bunch of points on the screen and then use some sort of algorithem to check what color the point next to it is and create a "line point" between them if it is diffrent. Then, I draw lines (streched sprites) between the points.

    I need to implement the second half of that idea still but the first half is done.

  • This is pretty hard to explain but I am making a game that is loosely inspired by this animation:

    Subscribe to Construct videos now

    The part that I am concerned with right now is the quite literal front line. The main two parts of this that I need to figure out are #1 how do I make it so a sprite moving into it shifts that part of the line backwards? and #2 how can I make encirclement manuvers work (if the line intersects itself, it connects creating an encircled area in the process). Any ideas?

  • Update: I found a solution using arrays and setting parameters to 0 to make it work but it would still be nice if this was a feature.