Ashley's Forum Posts

    • 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!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • It's not our problem if a screen recorder doesn't work. It's obviously a bug in the screen recorder app. I don't know what else to say. It's unreasonable to expect us to fix problems in other people's software.

    Imagine if I made a microphone that could record most things, but not the sound of birds singing. Obviously I need to fix the microphone. It is crazy to suggest the birds are singing wrong.

  • As ever, this will be at least ten times easier to fix if you can provide a minimal .capx that demonstrates the problem right away. I can still look in to this without that, but it can end up semi-impossible to do anything useful with large projects.

  • Closing, see the bug report guidelines and note that if the sine behavior is controlling the size then it will override other changes to the size (and mirror/flip are implemented as set negative width/height).

  • It's true that XDK is not the only one build system we can use, but it's - if I'm not mistaken - the only one officially supported at the moment?

    No, we always have, and still do, support PhoneGap Build. I actually prefer it myself because it's simpler than the XDK - just upload a zip and download an .ipa/.apk back - but for some reason it doesn't seem to have gained the same popularity as the XDK (guess because the free version is limited to 1 app, but you can replace it with different ones!)

    Canvas+ was never a real browser engine, and we dropped it as part of dropping support for the non-browser engines which were always incredibly painful to work with. Ludei have other platforms which are based on browser engines now.

    • Post link icon

    Godot's visual scripting appears to be one of those 2D flowchart type systems, which are very different to events. They also quickly turn in to a mess, which they seem to have already noticed themselves

  • Closing as not a bug.

  • I think the screen recorders are fine ane Construct 2 is the problem.

    I don't understand at all why you would think that. If a program's stated purpose is to record an app, and it doesn't work with a certain kind of app, then that is the program failing to fulfil its stated purpose. It doesn't mean it is wrong to be a certain kind of app.

    Not to mention there could be dozens of screen recorders out there that all work differently. Which is more sensible: we modify our software to work with all possible screen recorders (which may be impossible, if two happen to work in opposite ways), or should screen recording software make sure they actually work with all apps?