TheRealDannyyy's Recent Forum Activity

  • Wow, didn't expect the Firefox alpha to be released this quick. I've tested it out for a while and it seems to work.

    I have posted all of my mostly minor bugs over at Github.

    If there is anything specific we should focus on in the future, an update here or in C3's changelog would be appreciated.

  • TheRealDannyyy

    skymen

    Thanks for using our game for this benchmark! Yes on an Xbox One, putting Crystal Brawl in the background and then running other apps still lets me resume the game from where it was. Maybe it compresses the game's memory and writes it to storage, etc. I don't think this is a "revolutionary technique", doesn't iOS and Android also suspend many apps into the background in a similar way? Anyway it's cool to see the numbers for memory usage!

    Interesting and yeah, it's not really that new. "Revolutionary" might have been a little too much.

    I still find it fascinating that you can suspend and bring down memory use to this extend though.

  • TheRealDannyyy I removed that line " --in-process-gpu" at the end of my package.json file? (I added in because the Steam4c2 plugin by AJ2DI suggested to add it in.) Hopefully my players will stop having issue now! thanks

    It seems to work without it but it still didn't get 100% confirmed from the Steam4C2 Dev's, some features might not work as intended without it.

    I would be careful with this, especially when you have a game on Steam and plan to update it with this experimental change.

    I'm not liable for any damages caused by this change, everything is at your own risk.

  • Introduction:

    Hey there, my name is as it says on the left and I've decided to do some research regarding UWP's.

    A group of people have run several tests on "background memory use" and we've got some interesting results out of it.

    The Problem:

    As people that read through this topic might already know, UWP's come with a set of restrictions.

    The most concerning restriction was clearly the following: The maximum memory available to an app running in the background is 128 MB. A lot of people (including myself) immediately came to the assumption based conclusion, that this restriction would make it impossible for C2/C3 to run and result in some sort of "crash".

    The Results:

    As mentioned before, a group of people inside the Construct Community Discord server, came together and found out something interesting. UWP's seem to have some kind of "technique", which greatly reduces the amount of memory when you suspend the game (e.g. open the main menu).

    TL;DR: In conclusion, memory use in the background is not an issue based on our test.

    The

    Actual Test:

    The test is fairly simple. UWP's, are as the name already implies "universal" and run pretty much exactly the same on all platforms (currently Win10 + XBone).

    So instead of doing assumption based complaints/accusations, we decided to do tests using an actual UWP game.

    (More details about the game can be found HERE.)

    Step 1:

    Install "Crystal Brawl" on a Windows 10 machine using the Windows Marketplace for UWP's.

    Step 2:

    Run the game and measure memory use, while the game is active and suspended.

    Memory Use (active): ~130mb | Memory Use (suspended): ~116kb

    Visual Proof (*):

    Our Conclusion:

    While limited use of CPU and memory in the foreground are still fairly impactful issues, memory use in the background doesn't seem to be a problem.

    Construct 2/3 games might not run with 60fps and require a lot of optimizations, it's not the fault of the engine though and rather the fault of Microsoft's deliberate hardware limitations for UWP's.

    It's recommended to submit further complaints about UWP's directly to Microsoft.

    We additionally recommend everyone do the test by themselves and give Crystal Brawl a play on Xbone or Windows 10!

    If there are any questions regarding this left, feel free to leave reply to this post or send us a PM in Discord.

    Cheers!

    *provided by

    skymen | ko = kilobyte

  • Ashley - wow, that's interesting. I love it! On another note, will C3 be able to ability to select an object in the debugger, by clicking on it directly in the viewport? instead of having to find it in the list

    Suggest it here: https://construct3.ideas.aha.io/ideas

    I'd personally like to see a complete overhaul of the debugger in Construct 3 to be honest, including enhancement like this one.

  • ...I am really not sure what to do at this point besides start over. There is literally 100+ of hours of work that just went poof into corrupt land. I am beside myself...like just cant imagine having to start over again and this is my second time having to start over on the same project in Construct 3. Construct 3 should not be used for production in anyones case, ever, until its fully stable and ready. I think I have learned my lesson now though. Cancel Construct 3, and stick with Construct 2 I guess. I cannot believe this.

    Complaining about it on the forums won't get you anywhere and I mean this in a sincere way.

    Report it as a bug (if possible) here: https://github.com/Scirra/Construct-3-bugs/issues

    If you cannot report + attach a c3p for reproduction, just hit Scirra up with an Email (support@scirra.com) and I'm sure they'll look into it and try to help you out with this.

  • Problem Description

    Construct 2 behaves in a weird way when selecting the rectangle tool inside the image editor.

    It even locks your mouse while importing sprite stips in certain cases.

    Attach a Capx

    Example Download

    Description of Capx

    Empty project a with single sprite on a layout (including sprite strip for testing).

    Steps to Reproduce Bug

    • Open example project
    • Doubleclick sprite and open image editor
    • Select the rectangle selection tool*
    • Rightclick the animation frames pane > import frames > from sprite strip
    • Click on import and notice that you cannot click anywhere

    *IMPORTANT STEP: I highly recommend to re-select the tool if it was already selected!

    Observed Result

    Any mouse interaction while importing a sprite strip is being blocked by Construct 2.

    There are also noticeable UI errors, which don't seem to be engine-breaking at the current time though.

    Rectangle selected:

    Other selected:

    Expected Result

    The rectangle tool shouldn't behave in this way and work just like any other tool. (No mouse locking and buggy UI.)

    Operating System and Service Pack

    Win 7 SP1

    Construct 2 Version ID

    r245+ (beta)

    Tagged:

  • Yeah I always forget that...

    Here it is: teleport me now!

  • I can further confirm that the rectangle selection tool might actually be at fault in this case.

    For some reason I've also noticed that parts of the right-click dialog get greyed out when the rectangle tool is selected (they still work though).

    Rectangle selected:

    Other selected:

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley & zenox98

    I can reproduce this as well. I think this issue is somehow caused by the file itself and the way that Construct 2 checks its validity.

    This is however not really a traditional "App-hang" but more Construct 2 locking you out, probably caused by an error during the importing process.

    Here is a reliable way to reproduce this issue (on my end):

    • Open an empty project.
    • Create a sprite object.
    • Choose the rectangle selection tool* > right click the animation frames pane > import frames > from sprite strip.
    • Select an image to import
    • Notice that you cannot click anywhere, however pressing escape still works (unnecessary mouse locking code?)

    *This step is very important! I highly recommend to re-select the tool if it was already selected. For some reason this also seems to be a part of the reproduction process.

  • Alright I finally found the issue and it's caused by the --in-process-gpu chromium arg. Removing that arg fixes all the "ghost process" problems.

    EDIT: I have reported this issue to the NW.js dev's and they have confirmed it: https://github.com/nwjs/nw.js/issues/6059

    This issue is not caused by Construct 2 and therefor can be closed.

  • No, that's just papering over the cracks rather than fixing the actual underlying issue. There is data being received but it's not resetting the kill timer for some reason. And the kill timer is important in case the destroy notification was lost in transit, ensuring it reaches an eventually-correct state rather than piling up zombie objects when packet loss occurs.

    Well then I guess it's all up to you Ashley.

    Is there any possible way to help you out with this? Is there something wrong with the samples that bjayfont provided you?

    (Sample 1 | Sample 2)

TheRealDannyyy's avatar

TheRealDannyyy

Member since 30 Sep, 2014

Twitter
TheRealDannyyy has 18 followers

Trophy Case

  • 10-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

18/44
How to earn trophies

Blogs