Quicksand's Forum Posts

  • Ok, well I was the one who came up with the workaround and as far as I know it was working up until the v14 upgrades. In that case I think the problem is that the way I referred to the NW gui in the workaround script has been changed/deprecated in the newer versions. Should be a simple fix, someone who knows Javascript (like Ashley) just has to rewrite my simple script's syntax to fit the new requirements.

    I've incorporated that workaround for the next beta. That should paper over the cracks for existing projects, and new projects should not be affected anyway, since I think this stemmed from upgrading a NW.js 0.12 app. Closing.

    It's possible that the workaround is reportedly not working in the newest new versions of NW because, as I saw when researching that fix, the documentation said they were in the process of changing and deprecating some of the old syntax requirements for the NW gui.

  • Some people have been having trouble with NW and Avast Anti-Virus, do you use that?

  • Some people have been having trouble with NW and Avast Anti-Virus, do you use that?

  • I dunno if this is possible with C2, but if not maybe look into Ventrilo as an external alternative?

  • Looks like you can submit programs to Avast for white-listing. Maybe we can use that process but ask them to white-list C2 exported games in general?

  • I've had a couple of players reporting this issue with my recently released game. Anything more we can do about this?

  • Does C2 now supports 3D? or was that some kind of plugin?

    Not really. Some people experiment doing 3D with it but its still not really made for that.

    Example: https://twitter.com/HandsofSight/status ... 9659421697

  • The game was running pretty great actually(most of the time) but every few secs there was some kind of lag for no reason and the frames dropped only for an instant, and I found this very annoying, and after many weeks trying I gave up.(some users tried to help me, but there was simply no solution... they believed it had something to do with the platformer obj)

    AFAIK that was a problem with old versions of NW.js (which may have been called Node Webkit back then) which has since been fixed.

  • It uses NW.JS for Windows, Mac, and Linux.

    Downloaded separately: https://www.scirra.com/nwjs

  • Here's what Ashely has said on the matter in the past:

    [quote:fshnqw17]Vulkan is only supported with certain drivers on certain systems with the latest hardware. It's promising, but I doubt it will be on a majority of systems like OpenGL is for a long time to come. If waiting for technical improvements is unacceptable, then Vulkan doesn't fix that. There's also a huge pile of other issues, graphics certainly isn't the only significant component involved.

    (The above quote was in the context of the "Time to move forward?" thread).

    [quote:fshnqw17]I guess the "higher" reason is OpenGL is kind of a mess, the API is an early 90s design that has aged badly against modern tech. The new generation of graphics APIs like Vulkan, DX12, Metal etc. are all redesigned to work better with modern hardware and allow the drivers to be much simpler, so I guess that might go some way to helping, but that will probably take a few years to start having an impact...

    (That one is from 2015).

  • Probably not at all. I mean what would most users do with such source code? It won't look very readable since a lot of things would have to be done in c to match the events. It's kind of like manipulating the js of an exported project if it wasn't obfuscated.

    Yeah, you can do this if you export to NW without minifying and I've actually found that pretty useful in a couple of situations. It would be kinda cool if Construct 3 let you manipulate the underlying code at will before export, but not necessarily worth it for the devs to add that functionality within the program.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I had the same question. Very happy to find this thread. One more question...

    If you don't plan on having your game scroll at all should have the dotted line dimensions match those of the layout or should you not bother with that and just work within the dotted lines and ignore the excess layout space?

    Thanks.

    You should probably change the layout to match the view-port dimensions. That way you can use behaviors like "bound to layout" properly.

  • This is an annoying problem, yeah. I think you can change the NW.JS manifest file so that the window initializes at a larger size, but we shouldn't really have to. For my game I just had it add padding to the window size at the start of the first layout, but that's not really an elegant solution.

  • As far as I can tell there was a change in how NW handles the windows when it migrated from 012 to 013. For my game I've just left a bit of extra padding in the window size compared to the view-port size, then stopped the window from being freely resizable.