Je Fawk's Recent Forum Activity

  • If you are using Object has tags when you use only one tag all the time, you'd better reconsider using some instance variable instead.

    The CPU test shows massive changes in the CPU profile per groups. (tested with r449.2)

    Try it yourself, disable all the groups and enable them 1 by 1, then run the project and check the CPU profile: OneDrive

  • BTW fun fact, if you set opacity to a decimal number, I recall it eating CPU far more. Makes sense in some ways, C3 gotta convert it to int, but I recall it was a measurable different in cpu. Worth noting if you make your own opacity fading systems, better to wrap your opacity result with int() instead.

    Very interesting, thanks for sharing!

  • I think I've found the Never-Ending Fountain of Knowledge. The more combinations you try which achieve the same thing, the more random results you get.

    Also a real world example of attempting to use these optimizations ended up in a 5% CPU decrease for my tooltip system! (Not 5% overall, but from the CPU profile)

  • Checking for visibility before collision wastes CPU power. Collision detection already handles visibility efficiently, so extra checks slow performance. Make sure collision systems do their job by not over-optimizing.

    Collision detection has NOTHING to do with visibility. What are you talking about?

  • Sad to see your work went to waste 😢

  • It's ridiculous that we have to do such intense testing to figure out which way to write code in C3 when, visually, every version that dop2000 wrote made sense.

    I agree there can be some small changes in resource usage but from 10% to 60% is completely insane.

    Now you can argue that "well there are a lot of objects" but if a project has 90% less objects but more code (complex UI, combat, quests, NPCs, etc) writing it in a "bad" (???) way can lead to say 1% CPU increase for no other reason than checking if Sprite.X instance var = something, versus Comparing if Sprite.X = something.

    And then we have projects that look like this:

    So imagine how that small 1% can stack up with the amount of code we had to write.

    We enjoy the easy entry in C3 but mastering it is a whole new level. And while we can test for every small thing that we need to implement, it kinda starts to waste our time when ridiculous bugs like these (10%-60%) appear.

    I remember something similar when a Tween that was disabled was still causing havoc. fedca reported it and it got fixed. Can only hope for something similar here, but then it begs the question: what other hidden CPU hogs are there in C3?

    Would be interesting to hear Ashley 's opinion on this.

  • I figure that setting opacity is just setting a number so it’s light to set it twice. Else does a bit more than just run if the previous event was false. I tend to only use it in simple cases like you did since how it behaves with more complex picking isn’t entirely intuitive to me. However, it may be mostly a personal preference to do things in as few events as possible.

    I was almost going to write out some pseudocode for all that the events are functionally doing under the hood but I’m not sure that would be useful. I’ve only perused the source for the picking system in the C2 days, but mostly regard it as a black box so I don’t know all that’s going on other than basic behavior.

    Thanks for explaining :)

  • igortyhon thank you for the testing. My point was to first filter all the objects and then do the loop with the check, to make it run better.

    Obviously it didn't work, hence why I asked if people know the reason.

  • Thank you guys for your feedback!

    skymen also mentioned that putting a check before a collision removes the collision cell optimizations, with BeatsByZann that did some testing on this.

    I also thought, as dop2000 , that filtering before a loop is more efficient because it makes the SOL much smaller and that loops are very resource intensive.

    R0J0hound great ideas, thank you! But why skip the Else though? I always use it because I think an else is always cheaper than doing something on the same tick again, just to be replaced. In your example you set the opacity to 33 each time, and if it's overlapping it gets replaced from 33 to 100 (basically setting the opacity on the same sprite twice in that tick).

    It's less code and it looks cleaner that's for sure.

  • I tried to optimize my code a bit by checking if the sprite is visible, and if the layer is visible, before checking for a collision.

    I thought this will cause less collision checks and will cost less CPU. I was half right. It did have way less collision checks but the CPU actually increased a decent amount from the Sprite is visible check alone.

    Using r. 449.2

    This is the test project I used (OneDrive)

    When the Is Visible condition is enabled the CPU is at 5.7% and the checks are at 30.000

    When the condition is disabled

    The checks are 60.000 but the CPU is only 3.9%!

    I'm pretty curious why this happens and if it's normal.

    Any ideas?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Doesn't work with the latest beta either (r455) and the latest addon version 1.4.3.0.

    Shift+Tab doesn't do anything. Is there some debugging/verbose mode we could turn on in the addon or something to see what's happening?

    The only way to use Steam's features is to call the Steamworks action. So my workaround will be to build some ... menu of sorts when the user presses Shift+Tab hopefully, and to surprise him (in a bad way).

    Console:

    I'll try to contact them and link to the repository (https://github.com/Scirra/Construct-Plugin-Steamworks) but... pretty slim chances they would care. Now if Unity or UE5 integration would break....

  • We're publishing a demo for our game as well and there is no fallback working either. Shift+TAB won't do anything.

    We were hoping the new export option will make it exporting to Steam better, not worse!

    Steam won't stop you but you're missing access on literally the HUB your game can have on steam: screenshots, friends, community, achievements, etc.

    Why is NW.js being deprecated when we have a worse solution?

    I managed a while back to use it to show the Steam Overlay and for achievements.

Je Fawk's avatar

Je Fawk

Early Adopter

Member since 7 Jul, 2014

Twitter
Je Fawk has 3 followers

Trophy Case

  • 11-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • x3
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x6
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Email Verified

Progress

20/44
How to earn trophies