Ashley's Forum Posts

  • You do not have permission to view this post

  • Closing, .capx is mandatory, please follow the bug report guidelines.

  • Closing, please always attach a .capx to every report, it is mandatory. I tried a quick test using the Browser object's 'Open URL in new window' and it worked in both Chrome and NW.js without any error appearing. I am guessing you did something different to me, which is why we always need your .capx.

  • This is by design. To save memory, all Sprites share the same textures for their animations. If you load an image in to frame 0 of the animation, all instances showing that frame will be affected. The method of switching animation frame then loading an image is the recommended workaround.

  • Yeah, Cordova still uses UIWebView instead of the JIT-enabled WKWebView. This likely explains the performance discrepancy, since asm.js relies heavily on the ability of the JIT to optimise the code, otherwise it can be considerably slower.

    I think Ludei's Webview+ for iOS uses WKWebView, so you could try publishing with that. Alternatively I think there are a couple of third party Cordova plugins around that enable WKWebView in Cordova so you could try them out. In the long run, Cordova should end up using WKWebView by default (although this may need Apple to fix bugs in iOS), so hopefully this will resolve itself then. Another workaround is to keep using Box2dweb physics on Cordova for iOS, which isn't hit so hard if there is no JIT support.

  • I can't see anything wrong with your .capx. It would also be less confusing if you produced a minimally simple .capx with no events, not even disabled ones, if they are unrelated to the problem.

    With your example it works correctly no matter if I use:

    List files from "C:\Users\Ashley\Desktop"

    List files from "C:\Users\Ashley\Desktop\"

    List files from NWjs.ChosenPath (after choosing the Desktop folder)

    The last is no surprise, since ChosenPath returns "C:\Users\Ashley\Desktop", and is therefore identical to hard-coding that string. I can't explain why using ChosenPath would produce any different result compared to hard-coding the string it returns. It should in theory be identical, and indeed I have tried it and it is identical.

    At no point can I see anything that looks like your "Example 1" screenshot, which returns a list of files separated by semicolons.

    You should always indicate which version of the software you are using in bug reports, and you haven't included your NW.js version. I'm testing with 0.12.0 and it's working fine. If you're using an older version and that is causing the problem, it won't be fixed, you will just have to update NW.js.

  • There are two issues here:

    1) You set a value then try to retrieve it again (after restarting the layout) before you are sure that it has actually been written to storage. You should wait until 'On item set' triggers before restarting the layout.

    2) 'On item exists' does not set the ItemValue expression. I found that it can since the code happens to have the value available when it fires that trigger, so I added support for that.

    #1 is your fault, #2 is fixed for next beta.

  • Your .capx link doesn't seem to be working right now, I just get a blank page. Maybe it's a site outage? Could you try posting to Dropbox or another service as well?

  • Added for the next beta.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Closing, please follow the bug report guidelines. Often people assume we can reproduce the problem where we cannot, or forget to mention steps that are critical to the bug report, so we require a .capx to ensure we can see what you are seeing.

    If you need a test video I recommend finding a clip of Big Buck Bunny or some other free-to-share video.

  • Closing, please follow the bug report guidelines.

  • The bug report guidelines are there to help you too! They exist because bug reports that don't follow them are generally completely useless, and we cannot do anything to help you. People very often do things like report a bug which is nothing but a screenshot of an error message. There is usually nothing at all we can do about that. I actually want to help, but bug reports which don't provide the necessary information are impossible to do anything about. It's also common that users blame the wrong thing in their bug reports, e.g. that audio is broken but really some other bug was breaking an event that played audio, so I need the actual .capx project to investigate what is really going on since if I dutifully went off looking for problems in audio I wouldn't find anything and the bug would not be fixed. I know it can be tricky to follow the guidelines, but it's important to be able to actually resolve the problem. It's also very common that bug reports turn out to just be mistakes in events, and the engine was working correctly. It's very costly to developer time to spend several days picking through someone's 1000-event project, only to find their events are wrong and the engine was working correctly all along. We simply cannot afford to be doing that over and over again with every bug report, since we'd simply never have time to actually fix all the issues that are reported, let alone develop new features that other people are asking for. So the minimal project requirement is important to prove the problem is not in your own project logic. Performance bugs can be an exception to this since it depends on the full project; I have several in my email inbox at the moment which I will investigate in due course.

    I think the goalposts just moved: we were talking about physics running at 1 FPS, which is a severe performance issue that is really obvious and does not take any particular skill to demonstrate. Now people are talking about jank, which lately has been more to do with Chrome's frame scheduling, which is unrelated to the physics engine. So if I'm right, that's not actually a physics issue.

  • Again, this is very frustrating, I still have no evidence at all of any slowdown with the Physics behavior. Mozilla have done benchmarks of the asm.js version that show it performs within 1.5x of native performance. Until I see evidence to back up claims that physics is slow, I can only assume you are either using physics so intensively that a native engine would struggle, or that really something else is the problem.

    Some people blame the Platform behavior for being slow too. Likewise, I have no evidence of this.

    I think there is a tendency to blame things for being slow without really understanding what is happening. If you think something is slow, use measurements to demonstrate, and share your results and the .capx you used.

  • I wrote a whole blog post on using lerp with delta-time.

  • It's not normally possible for web content to crash Chrome. It means Chrome is failing, not your game. I'd suspect a graphics issue since that is normally most common, is your driver up to date?