Mithrill's Forum Posts

  • Hey everybody,

    Now I have this question floating in my mind. How to optimise events. In C2 events are read from top to bottom. Yes, I did my research ;)

    What is the impact to performance and/or efficient if events aren’t in an optimised order?

    Example:

    Let’s say I have 3500 events and I have organised them by folders. All player events are in the folder called “Player”, all enemy events are in “Enemy” and so forth.

      “Player” root folder
        “initialisation” subfolder “controls” subfolder “animations subfolder
      “Enemy” root folder
        “initialisation” subfolder “AI” subfolder “animations subfolder
      “Enviroments” root folder
        “trees” subfolder “animals” subfolder

    Next, on start of layout I want to create player object.

      “Player” root folder
        “initialisation” subfolder on start of layout: create “player” sprite object at X/Y. “controls” subfolder “animations subfolder
      “Enemy” root folder
        “initialisation” subfolder “AI” subfolder “animations subfolder
      “Enviroments” root folder
        “trees” subfolder “animals” subfolder

    Then I want to create some enemies and some trees, also on start of layout:

      “Player” root folder
        “initialisation” subfolder start of layout: create “player” sprite object at X/Y. “controls” subfolder “animations subfolder
      “Enemy” root folder
        “initialisation” subfolder on start of layout: create “enemy” sprite object at X/Y. “AI” subfolder “animations subfolder
      “Enviroments” root folder
        “trees” subfolder on start of layout: create “tree” sprite object at X/Y. “animals” subfolder

    Question: in this example, are all those on start of layout -events fired on start of layout, even though some of them are very bottom in events order? To me the answer is yes but could there be an issue of some kind if there are 3000+ events between the first on start of layout -event and the second? Should I do something like this instead:

      “Root” folder
        “initialisation” root folder on start of layout: create “player” sprite object at X/Y. on start of layout: create “enemy” sprite object at X/Y. on start of layout: create “tree” sprite object at X/Y.
      “Player” root folder
        “initialisation” subfolder “controls” subfolder “animations subfolder
      “Enemy” root folder
        “initialisation” subfolder “AI” subfolder “animations subfolder
      “Enviroments” root folder
        “trees” subfolder “animals” subfolder

    Personally I don’t want to use this method because I really want to organise my events by putting every player related stuff in “Player” folder and so on. BUT if there indeed are some performance issue or similar thing, then I guess I have no way around but to do like I described above.

    If someone has a tip or two to offer, feel free to do so ^^

    -M-

  • Conclusion: boolean variable isn't applied to containers. That is good to know.

    —, thank you very much for your answers AND patience. I Just read my previous posts and I realised that the way I described everything wasn't very clear. Sorry for confusion I caused to you.

    I will improve the way I describe things in the future

    -M-

  • I just deleted all of your logic and put in one line : Player is overlapping door_opener > set door animation "open", it picks the door that is in the container with the door opener you are overlapping. If you overlap two door_openers then it opens the doors in both. Seems to work fine.

    —, yes, opening door indeed works. That isn't the problem. Problem is closing. Other "Door" won’t close if player is overlapping with "Door_Opener AND there is also another "Door_Opener" overlapping that same "Door_Opener".

    Problem:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Doors%20and%20container/Door%20screenshots/not%20working%20both%20opened.png

    Like I wrote in my initial post, I know how to fix this, I just want know why boolean variable "isLocket" isn't enough to pick each individual "Door" and "Door_Opener" object. I want to learn this because then I have a knowledge (or at least a hunch) of what might cause the problem or if I ran into a similar situation in future projects.

    -M-

  • I'm also experiencing this same problem. Guess I need to Switch from Dropbox to external HDD.

    -M-

  • —, Sorry if I confused you. That was not intentional.

    Each sprite object called "Door" has another sprite object called "Door_Opener" added as a container. This "Door_Opener" will serve as a trigger to open correct "Door".

    What I want to happen:

    1) Sprite object "Door" boolen variable "isLocket" = false,

    2) when player is overlapping sprite object "Door_Opener",

    3) check which "Door" sprite object is container of this "Door_Opener" object and pick correct "Door",

    4) Open that "Door".

    Quote from Scirra manual: "If a condition picks one object in a container, every other associated object in its container is also picked." and "Adding them both to a container then allows events to treat both objects as if they were one, because they are always picked together."

    My question is: why boolean variable "isLocket" is not enough to filter out correct "Door"? I need for each: "Door" -loop to do that. Because "Door_Opener" is added as a container to "Door", I thought boolean variable "isLocket" will pick each individual "Door" AND "Door_Opener" sprite objects (because of the container -thingy).

    -M-

  • >

    > Problem is that the other door's won’t close if player is overlapping with multiple Door_Opener’s.

    >

    It does work, you just have the initial bool set to true on that left door.

    —

    But player character isn't overlapping left door's Door_Opener container? Like in even sheets are conditions: Door.isLocket = false and Hitbox is overlapping Door_Opener and animation "closed" is playing>>> open door else Hitbox is NOT overlapping Door_Opener and animation "opened" is playing >>> close door.

    So why that other Door_Opener is also picked? I understand what you said about boolean variable but that Door_Opener is a container of that left door so it should not be picket because player is not overlapping it. Clearly I'm missing something here :/

    -M-

  • 99Instances2Go , just remove those *** between h*t*t*p*s and you are good to go

  • Hey everybody,

    Yet again there is something bothering me. This time it’s doors. I included a sample capx so everybody can check what I try to describe here :)

    How everything will work:

    Each door has boolean variable isLocket. This needs to be false for player to be able to open a door. Door_Opener sprite object is added as a container. This will serve as a trigger. When player overlaps with this object and Door is not locket (boolean variable isLocket = false), correct door will open. There is also a condition that a proper animation of the door is playing before door can be opened. Then, when player isn’t overlapping Door_Opener, correct door will close.

    Here is couple of screenshots to give you a perspective.

    Picture1:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Doors%20and%20container/Door%20screenshots/working%20both%20opened.png

    Picture2:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Doors%20and%20container/Door%20screenshots/working%20one%20opened.png

    Problem is that the other door's won’t close if player is overlapping with multiple Door_Opener’s.

    Picture3:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Doors%20and%20container/Door%20screenshots/not%20working%20both%20opened.png

    I did found out how to correct this. Just needed to add “for each: Door” -condition and then everything will work properly. Sample capx contains 2 door groups. Enable/disable to switch between working and not working events.

    My question is though: why I need to add that “for each” condition? I though that boolean variable (isLocket) will pick each object separately (and also Door_Opener's because they are containers of Door ohject's).

    Or clearly there is something I don’t know about containers and how they behave :)

    Sample capx: h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Doors%20and%20container/Open_door_with_container_r233.capx

    -M-

  • Option 2 - Create imagepoints where your collision polygon vertices are. You can refer to these imagepoints' positions, and get the difference between two of them to calculate a width and a height value.

    Yes, That could indeed do the trick. Thank you

    -M-

  • Hello everybody,

    I have an question to ask.

    Let’s say I have a sprite object called Sprite1. It’s collision polygon is smaller than image itself. Now I want to create another sprite object called Sprite2 on top of Sprite1.

    Next, I want to set size of Sprite2 depending of the collision polygon size of Sprite1. First I thought that setting Sprite2 size by using expression Sprite1.BBoxTop etc. values but it turn out that they refer to the image’s bounding box, not collision polygon bounding box. Which makes totally sense now I think about it :)

    So my question is: is it possible to set size of sprite object to match the collision polygon size of another object?

    -M-

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • R0J0hound, Thank you for your examples! I appreciate your effort and help.

    Actually, I already knew about that wallcrawler3 example :) I have also implemented that into my game. Sadly, there is also a problem. Those wallcrawler3's are moving 8 pixels above the ground object. I have tried to tweak them but I can't manage to make them to move on the correct hight. I think it's because of two reasons: 1) the grid size (16x16), is messing with wallcrawler3's origin point. 2) wallcrawler3's origin point is in the middle of sprite. Ground object's origin is in top-left corner. I think one of or both of those reasons are causing that 8 pixel offset. Not sure though.

    Here is an example. Blue arrow is indicating wallcrawler3's top part (head :), NOT movement direction.

    h*t*t*p*s://www.dropbox.com/s/4x059rqqa8g67l3/wallcrawler3.png?dl=0

    Both of those wallcrawler4/5 examples are so simple :) They also make me realise how I could reuse the same boolean to work with multiples conditions! So thank you for pointing out that ^^

    Those examples gave me so much new ideas that now I know what to do today :)

    -M-

  • Nice! Thank you ^^

  • Hi everybody,

    I created a wall crawler enemy for my game. Enemy can move on the ceiling, wall and floor. Nothing special here. The reason why I’m writing this post is that I have a really odd problem with the enemy collision checks. Well, I think it’s because of collision checks. Not sure though.

    First, a quick preview how everything is set up. There is a GroundChecker -sprite under the enemy. This sprite will check when enemy is on top of something and vice versa. So this sprite controls the positive corner rotations (sort of descending the wall). When enemy is not overlapping the ground, rotate it to the direction of the enemy’s movement.

    There is an another sprite called WallChecker. This sprite will check when enemy is next to a wall. When it is, rotate enemy to the correct direction. Again depending of the movement direction. This sprite controls the negative corner rotations (sort of climbing the wall).

    This is the basic logic. Problem is: when ever the enemy cross a seam of 2 sold blocks, it will get stuck. Sometimes it will break out from this state and continue to move forward but most of the time it will just twerk in place. I think, I THINK it’s because of the GroundChecker collision checks. So when GroundChecker is overlapping the ground and then move a cross of the seam of 2 solid grounds, it will think it’s not overlapping the ground. In fact it is, but because there was that seam, GroundCheker thinks it’s not overlapping the round and tries to rotate the enemy. Of course this will cause some problems to collision checks. But to me that sounds so odd because GroundChecker is STILL overlapping the ground. There was just that seam between 2 separate ground objects. Like I mentioned, I THINK this is the problem. It could also be that some events are causing this odd behaviour. I wouldn’t be surprised if that turn out to be the case :)

    I included .capx file so everybody can check out in details the events. The enemies which are causing me the problems are marked as nb: 2’s.

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Scirra%20forums/wallcrawler/wallcrawler_gravity_based_instant_rotation_r227.capx

    Any kind of constructive help is highly appreciated. If there is something in the capx -file that you can’t figure out, let me know.

    -M-

  • Problem Description

    After exporting project to NW.JS or html5, pixelate effect is broken. In preview mode it's working correctly but after export, sprite becomes pixelated even before effect amount/value is increased.

    Attach a Capx

    h*t*t*p*s://www.dropbox.com/s/sqxfif4lwhgvs35/pixelate_effect_problem_after_export_r227.capx?dl=0

    Description of Capx

    Contains a sprite with pixelate effect attach to it. Use X key to increase amount of pixelate effect. Use Z key to decrease the same value.

    Steps to Reproduce Bug

    • export to NW.JS
    • go to folder created during previous step
    • launch nw.exe
    • press x key to increase pixelate effect value
    • press z key to decrease pixelate effect value

    Observed Result

    On start of layout in NW.JS, sprite is already pixelated even before pixelate effect value is increased. To me it looks like pixelate effect value is at least doubled on start of layout.

    first state In preview (pixelate effect value is 1):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20in%20preview.jpg

    second state In preview (pixelate effect value increased a bit:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20second%20state%20in%20preview.jpg

    last state In preview (pixelate effect value is maxed out to the cap):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20in%20preview.jpg

    Below are the results after exporting:

    First state (pixelate effect value is 1):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20after%20export.jpg

    Last state (pixelate effect value is maxed out to the cap):

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20after%20export.jpg

    Expected Result

    Pixelate effect not to be applied to the sprite on start of layout.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (untested)
    • Internet Explorer: (untested)
    • NW.JS (YES)

    Operating System and Service Pack

    Windows 7 Professional SP1 32-bit running through vmware Fusion 5.0.5 (1945692) on Mac OS X 10.9.5.

    Construct 2 Version ID

    r227 32-bit

  • R0J0hound

    I made a test with the pixelate effect like you suggested. I even installed a fresh copy of C2. Again like you mentioned, to make test with a vanilla version. Then I only installed your outline effect. Results: pixelate effect is also broken after exporting to NW.JS. I also exported to html5 and effect is broken. In preview pixelate effect is working but after export, well, see yourself:

    first state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20in%20preview.jpg

    second state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20second%20state%20in%20preview.jpg

    last state In preview:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20in%20preview.jpg

    Below are the results after exporting:

    First state:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20first%20state%20after%20export.jpg

    Last state:

    h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/C2%20pics/pixelate/pixelate%20last%20state%20after%20export.jpg

    Maybe I should post a bug report?

    -M-