NoticEmpire's Forum Posts

  • I shrunk the bounding box to be perfectly on the sides of the collision box and that seems to have fixed it. Thank you!

  • Thanks again, seems to be working for the most part but when multiple sprites overlap I encounter issues still.

    Here the table on the left slips under the table below it, and the table behind renders below the table under the table in front of it. The table on the right also slips under stuff it is supposed to be standing on.

    While the change in the code seemed to fix most issues of the player rendering incorrectly, here is the player being rendered behind a table it is above.

    I thought this might be due to the origin points not being at the bottom of the sprite, but they are in this screenshot and the problem still occurs regardless.

    Edit: I should also mention I'm using the BBox collision method instead of the default overlapping.

  • The image isn't loading in my previous post, here is what the code looks like.

  • newt I understand how to sort the z-order, I also understand how to change an object's z-order based on their Y. I'm not doing this in my case because the z-order is affected by a z-axis as well as a y-axis.

    alextro My objects all have different widths and heights and my game isn't isometric, although your formula is quite clean, I really wish it'd work for me :(

    R0J0hound I've tried your sorting algorithm designed for my perspective, and while it works in the capx you sent, it seems to function incorrectly when I try to implement it myself. Since it works for you, there is evidently something I am doing wrong.

    "SOLID_SPRITES_Family" would be equivalent to "Sprite" in your example, and "SOLID_SPRITECOMPARATOR_Family" would be equivalent to "other" in your example.

    The main issue that arose was that some objects just wouldn't sort correctly, and would be placed under ones they should be over. The other issue was that sorting wouldn't occur unless the collision boxes actually overlapped.

    In my game the collision boxes do not cover the full sprite due to how the collision works with incorporating the z-axis. I thought this was potentially the problem, so when testing I made the collision boxes cover the entire sprite like in your example, which didn't fix it.

    I thought potentially it was because the origin point was not at the very bottom of a sprite like in your example. I moved it to the bottom, which did not fix it.

    You may notice that my sorting method is not a 1:1 copy of yours, this is because the z-axis is more positive the higher up an object is in my game. In your example, the z-axis is more negative the higher up an object is. To fix this, I just made the references to the z-level in the algorithm flip (instead of -sprite.z it'd be +sprite.z, I doubt these changes are the cause but I thought they were worth mentioning).

    In the portion where you set dy, using yy, I just do the yy calculation there. I don't think that would affect anything besides performance. I also add z to y instead since z is positive in my case.

    I didn't have an sy value prior to implementing your system, so I added it and set it accordingly for the sprites I was testing with.

    Just so it is easy to understand the difference in variable names, yy is just y+z (in your case it was set to y-z, but I can't do that), z is z (but positive), sy is length, and sz is trueHeight.

    The alternate family has the same sprites as the main, and all its variables are properly synced with the main. SCz is equivalent to z, SCtrueHeight is equivalent to trueHeight, etc.

    Any idea what I've done wrong? Once again, if I've explained poorly and you need clarification please let me know. I really appreciate how helpful you've been.

  • R0J0hound Are you familiar with ways to order objects along the z-order that takes into account multiple variables and overlapping?

    (for the sake of clarity z-level refers to my custom 3d system's z-plane, z-order refers to the order in which sprites are rendered in construct)

    I've tried to do a For-Each ordered loop which takes into account the y-level of objects to place them correctly in the z-order. This works for objects with a z-level of 0, but once I start stacking objects on top of each other in the 3d z-plane or increase the z from 0 (eg. bottom object has a z of 0 but height of 10, and top has a z of 10 and height of 5, the one with the height of 5 rests on the one with height of 10) this obviously breaks the display because it considers the y level of the object, and as the top object has a lower y value, it gets displayed BEHIND the object it is on top of.

    (this would render the top box behind the bottom box)

    So the solution would be to incorporate the z-level into the calculation, correct? Well no, because if I set it to order based off y+z, if the object is slightly behind the equivalent of the bottom object's origin point when factoring in the z-axis, it will STILL BE DISPLAYED BEHIND despite being on TOP of the object.

    So rather than place objects in the z-order based off a simple calculation of values, would I have to check objects overlapping at an offset determined by the different in z-level, then check of one of the them has a higher z than the other's z+height?

    YES! I WOULD! And it works when using the custom sorting function with rexrainbow's zsort plugin.

    But only sometimes! If a large number of sprites overlap, the ordering breaks.

    Here is the code, I'm aware it's not efficient but I was trying to avoid using if-else since in rexrainbow's example he doesn't use it for some reason.

    I'm at my wits end trying to fix this stupid bug. It has nothing to do with the actual collisions or functionality of 3d which has been perfect for me so far.

    I know this is a weird question to ask and I apologize if I should have opened a separate post. Please, if anyone is capable of helping in the slightest or needs more clarifying information, let me know.

  • In case anyone else wants to implement a 2.5d game with a z-axis, the system proposed with two families absolutely works.

    Apologies if the perspective or the visuals look a bit wonky, this is just a test room.

    The Z-Axis IS possible :)

  • Ah, it seems I misunderstood what the value in the parenthesis did. I thought it referred to the nth instance of the picked instances, not the iid of all instances of that object.

    This is huge, thank you so much for your time and help, glad you are always around to push Construct 2 to its extremes.

  • Hello, I am having an incredible frustrating problem where I cannot check collisions between two objects of the same family correctly.

    My goal is to have a functional 2.5d z-axis within Construct 2, and while I have the basics for collision checking down, updating the z-axis via gravity is proving rather difficult.

    What I am attempting to do is check if a member of the family of sprites with the special variables concerning z-axis, z-height, etc, is standing on top of another member of the same family. If they overlap at an offset that FACTORS IN THE FAMILY-SPECIFIC Z-AXIS VARIABLE then the object ON TOP of the other object knows not to fall through the object under it.

    My main issue is that when using a For Each loop, the instance picked from the family cannot interact with other instances in the family via collision checks because the overlap check will only work on the instance that is ALREADY PICKED - the one selected via the For Each loop.

    I have seen workarounds to checks between two of the same object that require using a second family, but that is undesirable for me as the overlap check refers to a family-specific variable.

    What the hell do I do? Something like this would work if the overlapping object (second/index 1 instance) was pickable IN ADDITION to a set object picked in the For Each loop, but as far as I know that's not the case.

    Sorry for the seemingly overcomplicated issue, if any clarification is needed on what my problem is or what I plan on using the code for please let me know, I am desperate for help.

  • Fixed via switching step mode to horizontal then vertical and by going back a step when overlapping a solid (there is no "is overlapping solid" option so I had to check via families).

    Funnily enough this makes 2.5d top-down collisions super easy to do, so I'm kinda lucky I had this bug!

  • I have been trying to transition from using the 8direction plugin to CustomMovement for added control and for high speed movement collision detection with the step system.

    Problem is, when I try to push out of solid using the (Nearest) option, the object slides like this:

    And when I try to push out of solid using opposite angle, the object can get stuck on walls like this:

    Keep in mind that the collision box doesnt change at all between animations as the animations are a seperate sprite from the collision object.

    Any help? I have no idea what to do to fix this.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • All good, I had to remove the directions to be just 4 instead of 8 and then remove the smoothing effect in between them.

    For anyone wanting to do this it's actually super easy, just remove a0 through a3, rename a4 through a7 to a0 through a3, and edit the ina variable accordingly.

    The imperfect screenshots were from edits involving all a0 through a7 still in use with an edited diag value. Turns out just removing the values used as intermediaries works way better.

    Many thanks for your effect and work in the construct 2 community R0j0hound! You don't know how many devs you've helped.

  • I don't really understand what you are saying, but if they are both trying to modify the same effect's parameters then the changes would override each other. You'd need two separate effects.

    If you mean that there are already two separate pulse effects and that the pulse's ripples aren't overlapping, its likely because the effects are applied in order, so changes to the base visuals can only happen for the first effect, the second will apply its changes to the visual after the first effect etc. If this is the case I doubt its possible to have both effects affect the base visual.

  • Found the cause, turns out there was a bug that made arrays impossibly large at an exponential rate, causing rapid increased engine use once it arrived at a critical point.

    I'm not a big forum user, is there a way to delete threads or mark as solved?

  • This is incredibly frustrating because it's likely something I've done and not a bug within the engine, but because it doesn't give any information on what the cause is I have nothing to go off of.

    If anyone has had something similar happen or knows what can create this issue please let me know.

  • Hey, does anyone know what can cause Engine to spike to over 300% in the debugger? In the Profile tab it says that events take up literally only 0.2%, so I'm unsure as to what it is I'm doing that's been causing this.