Ashley's Recent Forum Activity

    • Post link icon

    we'd still have more options if we'd roll with native engines.

    No, I think in many ways it would be likely fewer. For every feature you'd have to find libraries that are compatible and work across all platforms (from iOS to Xbox One). For example, can you find a native WebSocket library that runs over all those platforms? Even if you can, should we depend on the possibly buggy third-party code and face the same criticism when something doesn't work? Or do you expect us to do the laborious work of writing cross-platform libraries which we maintain ourselves, when we get this for free with a browser? The key point is as a small company, we don't have the resources to maintain all those libraries ourselves - and I believe we got to where we are today specifically because we didn't get dragged down in to all that extra work. I'd point out there are several similar-sized, or even larger and better-funded, competitors who appeared over the years and maintained multiple codebases, who are more or less irrelevant now because they couldn't keep up. That could've been us.

    No. Otherwise Unity and UE4 devs would think native export is overrated then....?

    Well, I could change the comparison: most Unity devs write in C#, a garbage collected managed language. C++ may well be faster, closer to the metal, and smoother since there is no GC. Generally though, the difference doesn't matter, the higher-level managed language is good enough and the increased productivity is more important.

  • Scirra may be unable to fix it themselves at all, but to be concerned and using its large(r) industry standing/PR power and fanbase as leverage to apply pressure to the NW.JS staff to apply pressure to Chromium developers (officially as a company, not just "C2 users individually requesting"), is what Scirra's paying customers would expect from the developer of the product they purchased.

    The screen recording issue is nothing to do with NW.js or Chromium either. It's a problem with the screen recorder.

    I don't understand what you even expect me to do about this? I can't fix the screen recorder apps, it's not our software and many of them are closed source. All I can do is ask them to fix it. You can do that yourself, and the more people who do it, the more likely they are to take it seriously as an issue. Don't overestimate our influence, even browser makers shrug us off unless there is a tide of users behind us.

    What more can we do? What is your best-case scenario here? Do you expect me to disassemble a screen recorder and fix it from the assembly code or something?

    • Post link icon

    Html5 wrapped export will never run as efficiently as a 'native' export, in the same way that a windows / virtual machine OSX will never run as quickly or smoothly on an i5 laptop as an installed version would.

    You could probably say the same about hand-writing assembly vs. compiling code. Beyond a certain point, the difference doesn't matter any more.

    I like to go with examples, so I'd like to get back to this quite old report also known as the "30fps cap"

    No platform has all features. If we went with native engines, you'd probably lose support for browser-provided features like WebRTC, probably anything based on Web Workers (since they make multithreading so much easier to use), some service-backed features like speech recognition, probably user media features since they require a lot of cross-platform media support, you'd open the graphics driver bugs can of worms (browsers do a lot to sanitise WebGL), and so on.

    Judging by the fact the 30 FPS cap feature only has ~30 stars despite the fact I always link to it, I think it's fair to say it's a niche feature. Everyone will always have their favourite feature they want which is difficult to do, regardless of the platform. For example users of native engines still want things like networking, including things like loading web-hosted images, which browsers do really well.

    I'm sure someone will now say "but you could use libraries/frameworks to help", without realising the paradox that creates given others criticise us for depending on third-party code!

  • You do not have permission to view this post

    • Post link icon

    > That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way.

    >

    I understand your point, but there are the cases where those companies wouldn't take our reports as serious as yours.

    Good developers respect a good bug report regardless of where it comes from. The important thing is the report is clear and identifies a real problem.

  • The screen recording problem is categorically a problem with the screen recorder program. I would still say that even if we made our own native engine and a screen recorder app could not record it. I have nothing further to say. You will get nowhere trying to persuade me to fix someone else's app. Go and report the issues to the authors of the app which doesn't work. Please don't use this specific case to pile in any other complaints you have, they are not related to this specific case of a screen recording app not working.

    BTW if you have issues with the latest version of NW.js, we provide the older versions specifically so you can roll back to a working version if the latest version has any issues. I'll get a 0.18.5 release out soon anyway.

    Also, our old native engine with Construct Classic also depended on tons of third party libraries, including some official DirectX components that hard really bad bugs and caused big headaches. So you will never get away from this, all software depends on third parties.

  • This is another case of other software not working. It's up to the DRM wrapper to support multi-process applications correctly. I think you can force NW.js to run in a single process still, but it's not really anything to do with C2 or NWjs, the problem is with the DRM wrapper. It actually sounds like a pretty straightforward bug, they just need to tweak how the timer measurements are made.

    • Post link icon

    no, they take the information they got and report it there for you. This is the behaviour I'd like to see from Scirra

    I routinely do this already, sometimes several times a week. However users can get their bugs reported quicker if they cut me out of the process and report it directly, especially if they have a good report (in the best case you can more-or-less cut and paste the report to a different project). That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way. If users don't want to do that, I can and regularly do report issues on their behalf.

    • Post link icon

    My stance on native engines is detailed here: https://www.scirra.com/blog/ashley/28/the-case-against-native-engines

    I think "make native engines" is everyone's knee-jerk reaction when something doesn't work. For example, sure, we could make changes to make publishing easier. But that can be done anyway. You don't need native code to solve that. I also have direct experience of working with a native engine for Construct Classic. That had enough problems to make me move away from it. It is certainly not perfect. Do not imagine it will magically fix everything!

  • Can you reproduce the problem without any third-party plugins? This is part of the standard bug report requirements to prove the problem is not caused by that plugin.

  • Safari on iOS has never supported the fullscreen API, so "request fullscreen" won't work. Hopefully they'll add support for it soon.

    Safari has flip-flopped on how hiding the address bar works in pretty much every iOS update since iOS 6 that I can remember. Generally if anyone figures out how to hide it then spam websites start abusing it and then Apple change it. Chances are if you figure out how to do it, the next iOS version will break it again. Eventually I gave up trying to keep up.

  • Closing as it's a NW.js bug.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,776,705 followers

Connect with Ashley

Trophy Case

  • 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
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs