d939569e84594e1586eac3e65e28dfb2's Forum Posts

  • —, there are several in your boat.

    Pinging —

    If you must use C2, I strongly suggest using a Windows 7 VM, or dual boot with Window 7.

    You can also restart your computer, which typically alleviates (does not fix, but improves) the issue for a while.

    You can also try a previous C2 version.

    No one is scaremongering. Not unless you consider stating facts with plenty of evidence to back it collected from dozens of computers from different users around the world with all very different set-ups, as scaremongering. Your new anti-troll law does nothing but further, discourage people from reporting bugs to you.

    Anyways, Methuselah feel free to PM me and I would be more than happy to try and see what I can do for you in order to speed things up.

    C2 and W10 don't mix. Plain and simple. It most likely will never get fixed. Your best bet since your machine is powerful is running a VM with Windows 7, or dual boot. Neither is pleasant...but will work better if your intention is to use C2.

    Some of the performance issues were addressed, but plenty outstanding as dop2000 pointed out.

    There are other odd W10 behaviours I have seen which I did not get on W7, such as: image editor not loading (restart C2 fixes), exports get corrupted (restart C2 to fix), exported projects have artifacts in images (restart C2 to fix), sounds importing into "nothing" (restart C2 and reimport), copy and paste oddness, and lots of menus that fail to draw fast as dop2000 has experienced.

    I am not bothering to report these issues. Not after the last bug report. Ashley closed the bug, even though it is not fixed. Ashley keeps getting the facts wrong on the bug, compiled together with all the other issues . . . Someone else will have to pick up the towel on this one. I mention this Methuselah, to emphasize your options (or lack of I suppose).

    Basically, C2 does not support W10. Scirra may or may not say that, but it is the truth when you look at all the issues C2 had/has with W10 and given Scirras stance on it...it won't get fixed. Scirra should really post this somewhere officially, such as the Buy/Download page. These threads are going to just keep popping up more-and-more overtime (as more users switch to W10).

    Tl:Dr; C2 is not supported by W10. It will work, but don't expect it to work flawless compared to running on W7. Your best bet is running a VM instance.

    Edit: Edited for clarity

  • I agree that plugs really are a big issue, and have been for a while.

    I also think that Scirra is going to have to lead the way in fixing it. We need better support, and set rules over all aspects.

    From behaviors with no license to store plugs that have zip documentation, and even less support.

    I mean the thing is useless without plugs.

    This is one of Construct's biggest downfalls really. It is why Blackberry and Windows failed - lacking dev support. It goes two ways, Devs support Scirra and Scirra supports Devs. The bond is just not there like it used to be. This has some pretty damning impacts on current and future users.

    cjbruce has the right idea. You use what is best for the job you are doing. For people with less experience, it is hard to know what is "best" I recommend plenty of research and testing things out. Don't start any big projects without testing the waters first of each option. IE: Do some prototypes, check out features and ease of use. Check out the support documents and user complaints/praises. If you just pick a tool at random, without any real thought . . . you are going to have a bad time. Once you are more experienced, you will notice you use a vast range of tools typically...dabbling in each one for certain tasks.

  • This would be awesome!

    So, did some quick test:

    Add action (brand new): Unbelievably faster now. Near instant in one of my test CAPX's now.

    Edit Action (existing): Much faster. On one of my test machine's (the same one I ran the fresh install test on in the previous page), the same one that reported about 1.5-1.8s is now taking ~0.5-1s. This is a huge improvement.

    I did notice *some* actions are faster to edit than others. When editing a function action, it is noticeably faster than editing an action that was setting layers opac.

    I then tried r251 on my more powerful machine. It is pretty much on par with my W7 machine. The W7 machine is an old laggy machine, but still out beats my 6700k beast. But, in comparison to speed previously witnessed this is a huge step forward. I would say the speed is within acceptable ranges now

    Again, I have not done heavy testing yet. But these initial results are amazing.

    Windows Update / Meltdown

    It is worth noting, this issue was not caused by a windows update, or meltdown. For several reasons (not that it is too important, but to keep facts straight and prevent going down rabbit holes):

    • The bug was shown on both AMD and Intel (there is meltdown and specter. one of them effects only Intel, the other is both AMD and Intel).
    • This bug pre-dates meltdown updates, and was also tested on pre-meltdown updated machines
    • a user actually reported better performance after the meltdown update
    • it was shown early W10 had the issue (it has been there since the beginning of W10).
    • Similar bugs were reported months and even over a year ago, showing this is not related to a recent update
    • ...there are plenty of other test and benchmarks that could be run around Windows Update, but I don't believe they are too important given the vast amount of information already collected (and given the improvements with r251)

    It is completely reasonable to assume (and probably did), updates may have caused the issue to get worse and better over time (one update makes it worse, the next better, and so forth). But, it would be incorrect to say without a doubt windows update or meltdown caused this bug when you look at all data at hand. It would be safer to say, this has existed since W10 was officially released (which has been confirmed through testing). Again, not too important, but it should be said to prevent people from going down the wrong rabbit hole.

    Sidenote

    A side note, there are still other issues in the performance that users have reported, such as slow image loader. I have done my best to keep those out of here and stay focused on the issue I reported which was slow dialogs mainly with adding/editing actions. My hope was they were related, but this fix did not fix the other issues. Unfortunately, the users affected by other slowdowns will need to create a new bug report. This one has worn me down, I rather not pursue the other issues at this point (and to be honest, the other issues do not affect me as much). I will, however, help anyone with testing that does try to pursue the other issues as it is the right thing to do (as so many have helped me with this issue).

    Summary

    All-in-all, initial results are great. One could say the difference is beyond great, it is fantastic.

    Going Forward

    I am quite happy with the performance right now. Others are still affected by similar issues but, if we look back at the original bug report, so far it is much better. I am going to plug away and see how it goes over the next week.

    It took a lot of effort on both sides Ashley (there were plenty headaches on both sides). Ultimately, you came through and I am very happy with this release. I also recognize and appreciate the effort you have put into this at the end.

    I would also thank everyone who helped test out this bug. This would have been impossible to fix without all of your help.

    And with that...Program on folks!!

    Edit: fixed broken list

    — - you repeatedly said "C2 is broken on Windows 10" earlier in the thread, and now you say "No one is trying to blame anyone here". This is obviously contradictory. I've also seen you repeatedly edit previous posts in this thread, sometimes deleting a lot of content. I mean, this whole thing started with you pressuring us to fix it over the holidays treating it like an emergency even though we currently have other more serious issues. Frankly what I take away from that is your objective is mainly to troll over this issue and make everyone as upset as possible. This is a totally needless attitude; after this issue is resolved, I will be updating our bug report guidelines accordingly, so that no Scirra engineer is obliged to investigate an issue that users are being needlessly combative about.

    If you feel that strongly about it, I am always available for a quick phone call to clear the air and misunderstandings. That said, I am not going to comment here about what you wrote as it is not needed for the bug.

    Anyways, I'm looking in to the issue and I should have an experimental build out soon to trial a fix.

    Great, can't wait to try it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    nimos100, the performance issue is hit with only a few objects. The sample capx's were to show the issue.

    Some people are hitting 4-5s per dialog, with only a handful of objects.

    When comparing to W7, the same project loads instantly.

    That is the issue in the thread.

    Thanks for the update Ashley, truly appreciate it.

    I believe you are looking at this the wrong way in terms of passing blame, and ultimately is getting us nowhere. No one is trying to blame anyone here, we are simply trying to use the software and it is not working as expected. No one is calling you incompetent, or anything along those lines. You built a great tool for creating applications and games and not many people have the dedication, skill, or will to do that.

    Sometimes, updates make older optimizations not work well. For example, a game that worked well on iOS 7, could be laggy as hell on iOS 10. The developer needs to update the game for iOS 10. It is not Apple or the developer's fault, at the end of the day the developer is the one who needs to do something about it.

    Similarly, when going from C2 to C3, a project needs to be converted. Plugins need to be converted. And so forth. That is on the plugin developers and developers of the project. There is no blame, just the fact that work needs to get done for it to work properly.

    There are numerous, and I mean countless pieces of software that had to do numerous patches and fixes for W10. That all fell on the software creators and not W10. Sure, there are some things that Microsoft broke, but they only came to light by software developers doing their due diligence in debugging their software to determine the root cause. Most software updates for W10, were in the same boat as you. No ones fault, simply changing times.

    Now, if you connect the dots here. W7 updated to 8 then 10. C2 did not change for W10. It is not working properly on W10. That ultimately puts it in your hands. Again, no blame, but going back to the software cycle it ultimately falls on you to look at it (which you are currently doing).

    Now, it is entirely possible you find some sort of Microsoft Library they broke and they never noticed. Then a bug can be filed with Microsoft, but only once that is determined (which, only you can determine). Simply saying W10 broke it, is not enough. Microsoft would say C2 needs to optimize itself.

    Perhaps, there are workarounds you can find. Who knows.

    I just want to be clear. At the end of the day, there is no blame. The blame game gets no one anywhere. It is simply who ultimately needs to look at it, and you are doing just that. You are looking at it, and that is all we can ask. We the users, cannot look into this issue beyond what we have done. We also cannot bring this issue to Microsoft with the little knowledge of C2 users have (we don't know the libraries, how the internals work, only you do). Putting all that together, we the users have our hands tied and you are the only one who can free us. That is a lot of responsibility on your plate, I get that. But if you look at it from our perspective, it might shed some light on the issue. It is beyond frustrating, to say the least, for these performance issues to be hit. The way you were responding previously, added to the frustration. Your new stance on it is much better and definitely cools the tide.

  • I can't instal this plugin, why?

    what have you tried, and what is happening?

    A bit of a long read. But, here is some concrete evidence, anecdotal notes, and trial runs about the issue which show roughly 20 hours per project can easily be lost to this bug (so, if you did 5 projects a year, that is roughly 100 hours of your time lost forever due to this issue . . . that is 2 and a half working weeks). It is important to note, these test below are only for the issue of the edit action functionality being slow. It is possible it is related to the other slowdowns experienced, but I could not validate that as it is too time intensive.

    TL;DR;: C2 does not run well on W10. Even a small object count (such as sprites) causes slowdowns. The slowdown is overtime as you add more objects, so you don't notice and get "used" to it. By the time you notice, it is too late for your project. Layouts, layers, and global variables do not seem to contribute any notable difference to the general slowdown reported. Several W10 settings/optimizations were attempted with no real difference.

    Ran some test with a fresh install of Windows 10, still, need to run a few more to be complete. Essentially going under the assumption *if* the issue is Windows, then there must be a way to make it better. These tests were using the same project each time, same edit each time, fresh reboot each time, and no other applications notably running (one drive shut down, nothing else really has been installed).

    Quick Summary: No Windows changes made any real difference so far. However, selecting not to cache icons (within) made the biggest noticeable difference (but not enough of a difference).

    Conclusion of the test(s) in this post: No significant change in performance, still at unacceptable levels. (See summary of time lost below)

    Overview of time results

    When I was done with this batch of testing:

    First load (first action change) Icon Full Cache (C2 setting): ~3s

    Subsequent loads: ~1.6-1.7s

    First load Icon Cache Off (lowest C2 setting): ~1.7s

    Subsequent loads: ~1.5s

    Note: By load, I mean editing an action. The time it takes from clicking the action, until the dialog pops open.

    Quick estimation of time lost in W10 versus W7:

    Assume 5,000 events.

    Each event has on average 10 actions.

    Just to create these 50,000 actions is (best case): 75,000s lost (1,250 minutes or 20.83 hours)

    If you do smaller projects, estimate accordingly (500 events means ~2 hours lost).

    This is a rough estimation and in my opinion best case scenario. In reality, it is much worse because more than just adding/editing actions are affected as seen in dop2000 video and others. This is also ignoring the slowdown overtime issue. It also ignores edits to actions (aka you wrote "perfect" code and ran into zero errors).

    Test run so far:

    Indexing completely shut off. No difference.

    All background apps, telemetry, and so forth shut down. No difference.

    Display settings set to best performance. No difference.

    C2 in Compatability mode: No difference.

    C2 with higher affinity/process power: No difference.

    C2 with elevated priviledges: No difference.

    Note: I did not test for extended use in these scenarios. This means, how C2 slows down while the computer is on longer. This type of test would be too intensive for all of the scenarios I am running.

    Final thoughts

    Once time allows, I have several other tests to run (such as caching size, paging, and some other test which I have run already but am now collecting concrete data on).

    Side Note/Test

    I wanted to see at what point did the project become fast again. I did a series of "reverse coding" or stripping down. Here is the results:

    Deleted all global variables: No difference.

    Deleted all sounds: No difference.

    Deleted all but 1 layout and event sheets: No difference.

    Deleted Sprites: This is where it got interesting. Deleting the first couple, took forever. You could see the Object Properties scan through every object (or so it seems). It took a couple seconds (5 seconds for the first batch) to delete each one (once less objects existed, it was near instant). It was not until I had a couple left did the editor become more responsive. By the time I deleted every object, the window pops after 0.2s (visibly, it is instant). A difference of ~1.5s. The dialog pops so fast, I cannot time it accurately.

    This confirms what others have mentioned, about object count is the killer.

    The project did not have that many objects to start with. Even at ~30 objects, the editor was terribly slow. (speed is directly correlated with number of objects/sprites as shown in this thread throughout numerous examples).

    My question or thought as a result of this is , why would this slow down updating a variable in an action? What is C2 doing that is taking so long, if it is drawing icons as suggested in another post, something does not add up. Does C2 redraw the whole window, and all objects, when opening the edit action pane?

    What I found from the above "tear down":

    1) The editor for some reason goes through all objects below the object being deleted. I can visibly see the objects underneath being processed. If I have 10 objects, 1-10. If I deleted #1, I see 2-10 in the object info window. If I delete 9 I only see 10 get processed and it is incredibly faster than deleted #1. This means, if you had 100 objects, deleting object 1 will cause C2 to spin gears while you wait. This is not part of the bug (unless they are related, but I have no way of knowing), but an interesting finding.

    2) More objects causes the project to go slower. Slow downs seem to be seen pretty easily. The slowdown is rapid and hard. When deleted the objects one by one, the editor got faster and faster.

    3) Number of variables, does not seem to have any affect. Number of layouts either. Not in this test atleast.

    4) Having Properties Bar, Project Bar, Layer Bar, Object bar enabled or disabled had no difference.

    5) Having dozens of layouts + event sheets open versus just 1, made no difference.

    6) Based on my tear down, if you hit this issue it is already too late. The object count is super low to start having issues, and its compounds in itself terribly. Re-use sprites as much as you can, but unfortunately, it seems even optimized projects with low object counts can hit this issue. I cannot think of a reasonable workaround at the moment, as any full-blown mobile app/game would reasonably go over this threshold of the object count. Since the issue is slowly rising, you get used to it and explains why so many people did not realize it was an issue until they compared between two projects, or compared W7 vs W10.

    7) I tried moving objects into folders, this had no effect on action dialog time in the end. However, it did trigger the "slowdown overtime" issue. The dialogs took 4x as long to pop after moving a bunch of objects into folders. Upon a system restart, the times went back down. For example 1.5s load. Move a bunch of objects to folders. 5-6s load time for dialogs. Restart, back to 1.5s. This is unconfirmed if reproducible. If I have time I shall try this a few more times, it just takes forever to repeat since moving objects is crazy slow to do.

    8) The issue is not resource bound. I tried this while mining on both CPU and GPU. Similar times were experienced (This was near constant 100% load on my CPU and GPU).

    I'm glad you guys had a talk and reached some sort of agreement.

    Meanwhile I just want to demonstrate how bad Sprite Editor performance is on my Windows 10 machine.

    It takes about 0.5s to draw toolbars, 2-4 seconds to open the little window with image points, and if I right-click on animation frame - 2-4 seconds to show the context menu. This happens even with very small sprites in small projects.

    Youtube video

    Rebooting Windows fixes this temporarily, restarting C2 doesn't.

    dop2000 the video you have clearly shows a worser case of the issues. It is frustrating indeed. I have hit similar timings at times on my machine (where the outline of the context menu shows, and it takes a few seconds to load contents). If your machine is powerful enough to run a Windows 7 VM, that could be an option for C2 dev for now. Not a great solution I know, but it is the best I have at the moment.

  • —

    Replace frames of fan sprite with a large angle, for example, add 2 degrees on each image might be better, It is not the problem of behavior.

    Do you have a sample CAPX with it working properly ? If so, could I get that, so I can easily recolor the sprites known to work?

    Thanks

  • —

    Yes, it is because that fan is created by sprites with different angle, you might replace frames of fan sprite with large angle.

    Or try another solution -- "cooldown mask by canvas" (ACE table, sample capx)

    Is there a way to make the fan mask seamless, with no graphical errors?

    Hi folks,

    Ashley, myself, and a few others had a very productive conversation on Discord. A lot of misunderstanding from all parties was cleared up and everyone who has been antsy like myself can rest assured knowing that Ashley has given with confidence he has spent a long time on this issue and has agreed we are far from a solution. It is entirely possible, this issue could go as-is for a long time. Sometimes, that is the nature of the beast especially with this type of issue.

    We have agreed to put this to the side for a few days to allow for the air to clear a bit. And, if anyone has encountered tough issues before, sometimes simply setting an issue to the side and coming back to it later allows you to think more clearly about it.

    If anyone finds any more data, or settings that mitigate the issue feel free to post them. But, for now, let's let the air clear before coming back to it.