Ashley's Forum Posts

  • It would be best to ask Ludei.

  • No: we cannot write a better native engine than Google already do with Chrome. It really is an outstanding browser and we could probably not come close to the quality of it given Google have hundreds of the best engineers in the world working on it. Chrome also now can power Android apps using Crosswalk and of course the desktop apps for Windows, Mac and Linux using node-webkit where as far as we know it works very nicely.

  • C2 does provide JS execution in the Browser object, but you certainly should not use it in this case.

  • Folders and subfolders have exactly zero impact on performance.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Also already on the todo list!

  • Probably just missed v-syncs. It's still correctly measuring delta-time.

  • StatCounter has about 22% on XP or Vista, but both are trending down more quickly now. Remember Firefox is not affected so far as we're aware, so there is an alternative for players to use.

    This does suck, but those systems should disappear with time eventually, so it won't last forever.

  • We are aware of all bug reports posted here. Please allow us enough time to investigate. We are currently busy with multiplayer features which might increase the time it takes to investigate new reports.

  • Persist isn't supported on non-world objects. It's one of many things on the todo list...

  • delgado - the easiest thing to do is reproduce the problem in a new .capx that you are willing to share. Then everyone can help instead of 6 pages of speculation.

  • That's what node-webkit already is.

  • I had a quick look at your events. Your collision checks are done very inefficiently.

    You have a *lot* of collision checks that look like this:

    + On collision between A and B

    + Var = 1

    -> Do something

    + On collision between A and B

    + Var = 2

    -> Do something

    + On collision between A and B

    + Var = 3

    -> Do something

    + On collision between A and B

    + Var = 4

    -> Do something

    + On collision between A and B

    + Var = 5

    -> Do something

    etc. etc. This example does 5 separate collision checks.

    If you use subevents like this:

    + On collision between A and B

    ----+ Var = 1

    ----> Do something

    ----+ Var = 2

    ----> Do something

    ----+ Var = 3

    ----> Do something

    ----+ Var = 4

    ----> Do something

    ----+ Var = 5

    ----> Do something

    That does one collision check, then does a simple check for the variable. This is literally 5x faster than the previous way, and you do this again and again and again in your events.

  • Performance tips (notes points like the number of layouts does not affect performance)

    Optimisation: don't waste your time (you probably shouldn't worry about it already)

  • Aphrodite - ideally, end users shouldn't have to make a choice like that. Generally if you ask a non-technical user a technical question, they will give up, try to cancel it, or pick a random choice because they don't understand the consequences.

  • jayderyu - I don't understand your point about event sheets. If you put an event sheet in an object, how does that actually change anything? If it does not check the events every game loop, it's not remotely useful, because none of the events will work. If it does check the events every game loop, it's no different performance-wise to just having those events in a main event sheet anyway. Performance is just hard, period, and learning techniques to best optimise events can take time.

    With WebGL I am sure the engine will perform at around the same level as native engines. (Asm.js should do the same for heavily physics-based games.) The main problem with WebGL support is driver blacklists and reverting to software rendering, but that should recede over time - and it can actually be useful, since it works around severely broken drivers that would otherwise make the game unplayable. There are lots of other browser improvements in the works, like Chrome for Android gradually replacing the crappy stock Android browser, also getting asynchronous Javascript compilation, better garbage collection in Firefox, and so on. We also keep making performance improvements to the engine, such as with collision cells and segmented tilemaps to support extremely large levels like the OP describes.

    BTW the performance of groups in the debugger makes sense - the profiler will make extra calls to measure the CPU time of every group, which adds overhead that isn't there in normal preview or export mode.