1StepCloser's Recent Forum Activity

  • Well said.

  • Thank you for the explanations Eleanor. 👍

    I don't know what this means. What kind of data needs to be sorted?

    As for the array sorting: I was referring to if you need to pick the highest or lowest value in the data series, or loop from the highest to the lowest/lowest to highest.

  • Ahh, I see, so you are using the alpha of a pixel at a coordinate as the Z value. Interesting.

    You mentioned animating, would this be based on multiple set JSON actions or altering the JSON of the sprite directly?

  • RTX 3080

    Changed out the text object for a sprite font, since it's being updated every tick.

    Probably more helpful to locate the point at which it drops in stability while moving but I got drawn in to the design it was forming, I might need to add a save and load / delete objects to properly test this.

    Technical question:

    The sprite is manipulated by setting it to JSON, with the z manipulation essentially forming a height map? How did you go about creating the JSON, was it automated based on the sprite?

  • Thank you Eleanor. That was a lot of intriguing info you provided.

    Notes/Questions

    1. Use self-referencing as much as possible.

    2. Arrays are slow (I generally agree here, would this be irrelevant for direct lookups (Array.At(0,0))?

    3. Should the storage of data in arrays be preserved solely for when there is a need to sort data? If so, what is your preferred method of storing data when performance is concerned? (You ended up answering this in your collision method explanation: Dictionaries, referring to the unused space of an array as another pitfall)

    4. Static variables, I’ve been down this road in another project, but stopped due to some posts I read, such as: construct.net/en/forum/construct-2/general-discussion-17/difference-constant-static-108524, Toby refers directly to constants in this case, but they would theoretically have even less overhead than static as they would not be accessible during run-time. If constants hold no performance benefit, I am curious how static variables would.

    5. You prefer to use ternary operators rather than the if else condition blocks due to overhead, this is interesting. I need to test this out.

    6. If a calculation needs to be completed more than once in an event chain, set it in a variable so the calculation is performed only once.

    7. Can you explain your collision method a bit more? Are you stating that you check if a coordinate of a player, stored as a dictionary key, is already in the dictionary (has key) to determine if a collision check has occurred?

    8. Speaking of collision checks, do you have any experience with relying solely on distance checks rather than collision polygons?

    9. Use containers when possible, I investigated this earlier, but I did not feel in “control” of picking the objects in events due to the automatic nature of referencing all objects in the container when one is selected. I will look back into this.

    10. Pick by UID is a preferred pick method.

    11. Using pins created big slowdowns for you, this one was surprising to me. What is your take on the set as a child manner of positioning vs set position vs Pin? (https://www.construct.net/en/forum/construct-2/general-discussion-17/pin-behavior-set-position-72028)

    12. You mention using events in favor of behaviors however: construct.net/en/forum/construct-3/general-discussion-7/picking-performance-132709 (scrolling down a bit refers to behaviors running faster than events due to the overhead, nonetheless I think I understand your point, behaviors can sometimes be general purpose, with a portion of its cost not being utilized and thus essentially serving as a form of overhead. So perhaps this is a case-by-case basis.

    13. Pick by evaluation is one of your preferred methods of picking, I used this quite often in a previous project, but I came across a post (cannot find it now) that mentioned directly checking an instance variable through the object is faster than checks through the system (compare two values, pick by comparison, evaluate), now this does not consider the benefits of ternary operators, so this might be moot.

    General questions for you:

    1) What is your take on physics? I tend to disable most collision-based physics and apply physics forces on collision instead, perhaps it is better to work with a more custom system for physics like outcomes?

    2) What is your current main bottleneck in performance? (I have watched gameplay of your project, several sprites running around, the main thing that impresses me is the multiple accessories that are also present on the characters, I have made a project with this feature in the past and that tended to be one of the major consumptions of CPU.)

    3) Is your target FPS 60? If so, how many characters are you able to have running around until you start to drop from that target.

    4) What is true scale pixel size of your characters? (16 x 16 for example)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hello all,

    I tend to find new ways to approach problems after discussing with others. I'm interested to know if anyone has unique approaches for performance, especially as the project grows; anything from tiny/specific situations to general coding principles.

    This serves as a good general guide: construct.net/en/make-games/manuals/construct-3/tips-and-guides/performance-tips, but perhaps you've encountered scenarios where you had to approach a performance issue in a less obvious way.

    Thanks for any response,

    1Step

  • You do not have permission to view this post

  • Haha, wow. Changing the way the issue is presented convinced Ashley to fix it. ^^. Welp, thanks oosyrag.

  • I think I understand what you are saying? It's such a small issue, that doesn't affect most users, and thus, is not considered worth the time? If so, fair enough.

    It's indeed difficult to address sparse cases. This issue is more relevant to those with larger projects that rely on collapsing groups more often than most. In these scenarios being able to see that the events are being deselected when moved outside of groups would be beneficial, but if that deselection mechanic is integral to how the engine/editor works, then I can see why it should be left alone.

  • Well for me personally it's now on my mind, thus, the odds of it happening to me are lower. However, the reason this came about was that I discovered after disabling/enabling some collapsed groups and moving them around for organization purposes that my project wasn't working as intended, thus I retraced my steps to discover that the collapsed groups I had toggle disabled/enabled were still disabled in terms of the events below.

    The main potential issue for an unaware individual is that a collapsed group will not give any indication of this default selection mechanic when dragging groups, as the only thing you can see is the group header of a collapsed group.

  • Yes, this wasn't about what it's doing but moreso why (presumably there is a good reason?), but thanks.

  • What this shows, and what Ashley has confirmed: github.com/Scirra/Construct-3-bugs/issues/4797, is that when a group and the events below it are selected and then moved outside of a top-level group it diverts to only the group header being selected. This is apparent if the group is not collapsed, however as far as I'm aware, if the group is collapsed there is no visual indication of this selection defaulting to only the group header.

    Thus, I was curious what benefit/rationale there is behind defaulting to only the group header being selected when moving the selection outside of a top-level group.

1StepCloser's avatar

1StepCloser

Member since 1 Mar, 2018

Twitter
1StepCloser has 3 followers

Connect with 1StepCloser

Trophy Case

  • 6-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

10/44
How to earn trophies