Ashley's Recent Forum Activity

  • There isn't always a simple example snippet to show. A realistic example of static conditions might involve hundreds of lines of code for a niche use-case that most people don't even need. It's kind of a complicated escape-hatch for when the usual picking algorithms aren't appropriate. My point is Unity can throw dozens of staff at such things, but it's difficult for us to justify. The other alternative for us is just to not document stuff like that and leave it as unsupported engine internals. Then at least people won't wonder what it means or how to use it, but I'm not sure that's preferable.

    If I download the full Construct manual it currently comes in at around 900 pages. It's a huge body of work, and "just sprinkle some examples all the way through" is probably a major project that would take weeks.

    Being a smaller company I think we have to rely on our community more than huge companies that can just throw loads of staff at something. For example there's no way we can possibly do our own Construct integration for all the third-party services out there - it's year's worth of work. So we have an addon SDK so third-party developers can potentially do it themselves without having to wait for us to get round to it. I think it's a similar situation with documentation - if you want tutorials for specific kinds of games, useful code snippets for specific features, demonstrations of useful approaches and algorithms, then we have a public tutorials system for that too, so the community can share their knowledge rather than relying on our already-stretched team to provide everything. To be clear, that's not an excuse for us to have inadequate documentation - I think we do a good job with the resources we have available - but when it comes to samples, guides, tutorials etc. there's just an endless array of things to be covered, it all takes a great deal of work to do well, and the fact is we're a small team.

  • I'm not sure what more there is to add to that documentation - normal conditions are run once per instance, static conditions are run once only regardless of the number of instances, and that's about it. Normally you don't need them, so you can probably just ignore that they even exist most of the time.

    A billion-dollar company with thousands of staff can probably afford to have hundreds of people working on documentation alone, which is many times more than the entire size of our company dedicated solely to documentation. So while we want to have good documentation, I don't think "why aren't you doing well as Unity" is really a fair point to make. In fact I think it's a sign of how extraordinarily well we've been able to leverage web technology that you can even mention us in the same sentence as them with a straight face.

  • I just checked and Alpha Ramp is there in Construct Animate r366.

  • Try disabling any browser extensions you have installed. They can interfere with and break Construct.

    Otherwise try pressing F12 and check the browser console for a more detailed error message.

  • Shadow Caster will draw over anything below it in Z order. If something still appears over the shadow, make sure it's below the Shadow Caster in Z order.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you need maximum performance at all other costs, choose pure JS then. Surely you can have the performance sensitive parts in pure JS and the general purpose stuff in event sheets or mixed event blocks/JS.

  • I just released a Greenworks plugin update for v0.82.0 using Greenworks v0.15.0, which supports a universal binary for macOS.

  • Once you export with nwjs and disallow chrome dev tools, can a player force chrome dev tools back on?

    Yep: just edit package.json and delete --disable-devtools, and dev tools works again.

    You can't really disable dev tools. If someone wants them they can get them. Disabling dev tools is not really a security measure, it basically just disables the built-in shortcuts. Still, even if you have dev tools, it's not necessarily easy to make any useful changes, especially if you advanced minify the export.

  • look at the global variable timetocomplete to get the duration the test took.

    Your project does not display this variable. Are you looking in the debugger? Because debuggers have performance overhead. And so then your test is basically measuring the debugger overhead. Normal preview is faster. 

    for (i = 0; i<=1000000; i++)
	runtime.globalVars.NumberA = 
		Math.sqrt(runtime.random(100) + runtime.random(100));

    Code like this is still an unfair test: an optimizer may be able to identify that the same value is overwritten 1000000 times, so it can skip the first 999999 calls; then since the 'i' variable is unreferenced, it is OK replace it with no loop and just one assignment. I don't know if it does or doesn't do that optimization, but in theory it can, so you shouldn't write a test like that. Usually at least summing a number every iteration and then displaying the result (so the sum is not dead-code eliminated) is a better approach.

    I profiled the empty JS block case. Given an empty loop does nothing, then adding something in to the loop - even an empty async function call - means you're measuring nothing vs. something, so the numbers will be big. I don't think that by itself means the result is meaningful. Still, it seems to spend most of its time in GC; perhaps the fact it's an async function call means it has some GC overhead and so you end up measuring that.

    I don't think that's a sensible thing to do if performance is important though. Crossing interfaces always has a performance cost. For example in some C# engines, calling C++ code is expensive. So if every time you call a math function in C# it has to jump in to C++ code, and you benchmark it, it'll be slow as it's all overhead for jumping between interfaces. The same thing is happening here. So high-performance engines tend to do all their math stuff in C# so there is no overhead and only call in to C++ for more expensive things (which then have all their own C++ math functions, so there's no need to jump back to C# for that).

    The obvious thing to do is if you need maximum performance, write the loop itself in JavaScript, and avoid mixing interfaces (in this case event blocks and JS). So why not just do that?

  • The issue is this: (JS blocks have a surprising overhead, functions unsurprisingly have overhead, and must be inlined when used frequently)

    The overhead to call a JS block in the event sheet is: "call an async function". So this does not really make technical sense. It should be a minimal overhead. Hence my assumption the benchmark was wrong (especially since you talked about doing things which would qualify as an unfair test, as a good JIT would replace or delete the code you are running).

    If you have a concern about performance, it is 10x more helpful to share an actual project file demonstrating a realistic situation, than just talking about it.

  • Picking is a concept that only applies to event sheets. There is no notion of picking in JavaScript code. So that code operates on all instances of Character and has no involvement in picking whatsoever.

    However from a code block in an event sheet, you can use pickedInstances() to iterate just the instances picked in the currently running event block. You could then also pass these to a function in a script file. But that doesn't mean JavaScript understands picking - from the perspective of JavaScript it just means you're passing an iterator (or array) with some specific subset of content.

    Whatever the case, doing the above 1000 times with only 1 Character in the scene adds 10% cpu load, which makes it feel like I'm doing something terribly wrong with that.

    Ignore such measurements, for the reasons I described here.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,535,170 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
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x69
    Educator One of your tutorials has over 10,000 readers
  • x3
    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
  • x38
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs