Ashley's Forum Posts

  • 1 - Start treating arrays as a proper type, instead of an object. We have string, number and bool, why not array?

    IIRC, Classic had some support for arrays as an expression type, but it was difficult to get right. One of the main problems was whether to use copy or reference semantics. Copy is easy and convenient, but if you're dealing with a 10mb array will quickly hammer performance and bloat memory. References were very difficult to get the memory management right for in C++. This would be easier in JS, but then makes for some gotchas - for example if you put an array object's array in to an object's instance variable then change it from there, both get updated, and that might not be what you wanted.

    [quote:3rgsnepg]3 - Pointers as a type. This means you can store references to an object inside another object, as a property. Right now you can do this by storing the object's ID, but you can't do stuff like player.weapon[1].destroy() in a single event

    The event system is very different to programming languages, so when you suggest a feature and give a line of programming code as an example, I'm not sure how exactly you think this would really work! UIDs already allow this, and as per the way events usually work, you need the condition to pick the instance to run the actions on, so there needs to be a condition involved either way...

    [quote:3rgsnepg]4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?

    Again, if you just throw out a programming language feature, how would that really look in the event system? And why would that be useful?

    I'd add most of the other suggestions in this thread have been suggested several times in the past - we have a very long todo list, and a finite amount of hours in the day. So if you really want a feature suggestion to be taken seriously, you should go in to detail about how it would work, give several examples of previously difficult things that become a lot easier with the feature, and some reasons why it's important enough to do before all the other feature requests we have!

  • IIRC, that's because you've set "high quality" downscaling mode, and the last row of pixels needs to be extended to a power-of-two size box in order for the mipmaps used for downscaling to display with optimal quality.

  • To export to Android, you choose the "Cordova" option in the export dialog, which covers both iOS and Android. There's no dedicated icon for each, but that doesn't mean it doesn't support them. With Crosswalk Android export should work well on Android 4.1+, and you don't need it for Android 5.0+.

    • Post link icon

    This thread was for asking what to do next back in 2013, it's long past its due, so closing. (Thought I had already!)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's an improvement, but I still think it's an awful lot for one dialog to do. What if it took a compromise: have the "object" and "condition" panels in the first dialog, and then the parameters and expressions in the second step? In other words, like taking the current three-step approach and merging the first two steps?

  • Is it the same in desktop Chrome? Both are based on v47 now.

    Are you sure you haven't disabled vsync in nVidia control panel/Catalyst control center/any other graphics settings? Changing settings there has been known to cause problems in the past. By default Chrome should have pretty good v-sync by now.

  • 100ms is an extraordinarily long jank, suggestive of some kind of fault rather than GC. Usually a GC pause means at most a dropped frame or two (16-32ms jank), and it should be especially unlikely to jank given Google's recent work on improving the GC so it only runs in the idle time at the end of a frame.

    Also, are you seeing the same result in the Chrome browser? Both alpha7 and Chrome stable are now on v47, so it's very useful to check that to identify if the problem is in the Chromium engine, or a result of some modification of NW.js.

  • Over the past year Google did a lot of work with the compositor to reduce the fillrate, which I think might explain the improvement on Intel GPUs. I think previously it might have done something like rendered everything to a texture, then copied that to the window, whereas now it can render directly to the window. Still, good to hear the performance is better!

  • Download NW.js 0.13.0-alpha7 for Construct 2 here: https://www.scirra.com/nwjs

    This requires r217 or later (currently only beta releases).

    Alpha 7 is updated to Chromium 47. It looks like NW.js updates to new stable Chromium versions very quickly now, which is great. Alpha 7 also includes more missing features which are gradually being added back with the alpha releases. The status of supported features are listed by the NW.js developers here: https://docs.google.com/spreadsheets/d/1fy0-BBZaslqsEhgC0pFZmAloqRUSw3yO0taucskSCj8/edit#gid=0

    Let us know if there are any issues with this release. It may also fix some bug reports if the report was simply that a NW.js feature hadn't been ported yet.

  • You can ignore that.

  • You do not have permission to view this post

  • Multiplayer works well for most people over the internet. The design of some routers mean that they block some peer-to-peer connections though. It's not the fault of C2 or WebRTC, it's to do with the architecture of the Internet and is related to IPv4 address exhaustion. It's not broken, it's probably just your LAN configuration is not letting connections through.

  • It looks like a bug in the Windows Universal app runtime. I reported it here: https://connect.microsoft.com/IE/feedbackdetail/view/2101345/fullscreen-api-broken-in-windows-universal-apps

  • I can't guarantee that changing the origin at runtime is actually ever going to work. The entire engine has been designed with the assumption that origins do not change. In particular you may end up getting strange results with the collision cells optimisation and render cells. There is a lot of non-obvious engine code that depends on this stuff as you appear to be finding. So why do you need this anyway? Can't you work around it with events?

  • Answer your own performance questions with measurements

    I would guess that you will not be able to measure a difference either way.