Native Desktop Exporter for Construct 3

  • The Z-sorting on C2 was definitely much slower than CC and so I've stopped using it

    I would love to fix this or improve it if possible, but again, I need an example of it.

    [quote:1v4ss2tx]Also with Node-Webkit: We're having issues with changing resolution and monitor refresh rates in-game

    What issues, specifically? Have you filed bugs for them? We don't officially support any way to actually change the monitor resolution by the way.

    You can improve C2's engine to resolve all the performance deficiencies all you like, if wrappers like Node-Webkit just release more broken builds like with the jank that's still not fully resolved...

    I'd point out that this is one bug in the 0.11.x version of Node-Webkit, it should already be improved in the 0.12 alpha which I posted to the forum recently. The main problem is that we did not previously have any way to roll back node-webkit updates, and due to changes to the exporter we can't support versions older than 0.11.x in the current version of C2. The timing of this bug badly coincided with the changes we made to C2, so everyone was stuck with that version.

    Anyway, I guess this is a little overdue, but our NW.js download page now lists older versions:

    https://www.scirra.com/nwjs

    So this won't happen again. You won't have to be stuck with the latest version of NW.js only. If there's a problem you'll be able to roll back to an older version.

    [quote:1v4ss2tx]What would you have done if, after Google release the Node-Webkit with the jank and all the horrible performance, they shut down and stopped making new Node-Webkit builds and fixes?

    We'd hire someone to continue development. But as far as I can tell, the NW.js project is getting stronger with a bigger community.

    Gotta agree that Classic was WAY more efficient when it came to sprites

    I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • As for the slowness. My game rely on array for its movements (so that many things can happen at same time at same timing and not getting "behind") and it can have lots of movements per "game round" (0.2 sec) and the array is 600 entries big, and it is still a relatively small level for its type of game.

    The bottleneck is the searching the whole array for some certain values and it is done often.

    If Ashley would like you are welcome to take a look at my game but then it has to be sent privately.

  • I'll try and dig up examples/make suitable ones to show our issues, and okay the refresh thing I can understand.

    I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.

    This is actually why the Javascript + HTML5 + WebGL troubles me, because C2 is fighting harder and yet games made with CC are still faster, I love the optimization that C2 has very much but I think that power could really win with DirectX 9 export (or even OpenGL if you want multi-platform).

  • I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.

    Perhaps it's because most of my projects are less games and more generators of things - so we deal with objects on the screen and almost none off-screen. I'll try to make a "real" example, and perhaps something drastic has happened since I last tried that sort of thing, but C2's output felt slow the moment a couple of thousand bullet behaviour objects came up. Meanwhile CC doesn't break a sweat until tens on thousands.

  • My two cents on this : )

    (pretty important: Please don't jump to conclusions before the last sentences)

    Around me, in small or huge game studios, C2 is considered as the best tool for prototypes.

    But absolutely not as a real game engine with which you can stick for your full game.

    Other devs and me are pushing C2 to Steam releases, major gaming news websites, +150 000 views on some youtube videos, etc...

    But this doesn't change anything: when I'm asked what will I do for consoles, I'm answering I'm looking for someone to recode the game from scratch using Unity or Gamemaker. The key word is "from scratch". A port asking for some efforts is normal, having to redo all again, quite depressing.

    Publishers are sending emails with big money for Penelope on Sony consoles, and I can't say yes because of html5. With an exporter in any other language, I would be rich now (no kidding). So, I'm stuck, and I know I won't use C2 for my next project (and you can't imagine how it breaks my heart.)

    C2 will always be the most brilliant engine I know, I'm in love with it, but due to the "team" size, ressources, and its audience (mainly hobbyists with no need for consoles export), it will stay, indeed, the best tool for prototyping. Nothing less, nothing more.

    Now, should I ask again and again to Scirra to do something about it? I'm not that sure anymore. Using C2 to make deep, full games is kind of a hack.

    This software is made for people to craft their first games. This is not sold as a pro framework for studios. The tone of the last promotion video is very clear on this.

    I sincerely wish the best to Scirra, and I really want them to live long.

    The step between GM and GMS has been to hire many, many, so many people. Last time I checked, they were nearly 50 people in there. You can't ask Scirra to do the same if they don't want to. There is nothing in the middle, it's either you're an army and can provide support for all platforms, or you're a few guys and stick to your niche audience.

    Making a niche game for a niche audience myself, and not wanting to grow a bigger company, I fully understand the Scirra's choice to not produce and support complex, expensive native exporters. Even if it makes things complicated sometimes.

  • C2 is fighting harder and yet games made with CC are still faster

    I just showed an example that demonstrates C2 is faster than CC in one case. Again - I need examples, benchmarks etc. to comment otherwise on top of all the other optimisations C2 has I have no reason to think it's not as fast *based on measurements*.

    Aurel - console support is a different question really, I viewed this thread as talking about desktop exporters. But that may change too, especially considering Microsoft's recent comments about getting Windows Universal apps to run on the Xbox One.

  • Desktop exporter and console exporters are closely linked. If C2 was able to export in C, C++, or C# for desktop, companies I'm working with would have the sony port done already.

    Also, even with partial WiiU support and full XboxOne support, It won't change things that much. We can't make games for the only console which can get you some audience and money (sadly, sales are really, really low on WiiU and XboxOne for indie games)

    But again, and I hope it was super super clear, I'm not asking for native exporters anymore. Being ready to quickly export for new systems would mean to make exporters for every single system having a chance to become a standard a few months later. Every one of them is a bet, and you really need to have big money in the bank to afford this try, error, and often waste strategy. I don't want Scirra to explode on this mine!

  • [quote:29rxzgnp]I just showed an example that demonstrates C2 is faster than CC in one case. Again - I need examples, benchmarks etc. to comment otherwise on top of all the other optimisations C2 has I have no reason to think it's not as fast *based on measurements*.

    Ashley

    Using your tests :

    Native : I got 137000 (137430) sprites fps

    [attachment=1:29rxzgnp][/attachment:29rxzgnp]

    WebGL : 73000 (73444) sprites fps

    [attachment=0:29rxzgnp][/attachment:29rxzgnp]

    On WebGL it stopped at 47K hung, then 53K, 61K, 65K, and finally 73444

    Native is 2x faster for me.

    Sys specs:

    Xeon E3-1230 3.30GHz

    32 GB ram

    Nvidia GTX650 Ti

    Win 7 64

    Chrome Version 40.0.2214.93 m

  • facecjf Aren't all of the effects WebGL only though?

  • As for the slowness. My game rely on array for its movements (so that many things can happen at same time at same timing and not getting "behind") and it can have lots of movements per "game round" (0.2 sec) and the array is 600 entries big, and it is still a relatively small level for its type of game.

    The bottleneck is the searching the whole array for some certain values and it is done often.

    If Ashley would like you are welcome to take a look at my game but then it has to be sent privately.

    You got to do it differently. 200ms is quite a bit of time, so what you do, you make a loop for X and Y that every tick tests only certain part of array, like from 0-50, from 50, 50 to 100,50 etc. You can use any values that work best.

  • damainman

    Aren't all of the effects WebGL only though?

    As far as I know, yes.

    These tests are provided by Ashley. I'm just posting my benchmarks of these tests based on a post about the performance difference between native and WebGL and how they are close... FX or not. I see 2x the performance (native) just on sprite objects, unless I'm missing something here.

  • megatronx hum. hmm. Maybe it is better discussed elsewhere as of not hijacking the topic. *nods*

    Did the performance test just for fun on a freshly started browser.

    Got up to 26k objects then it hung. 30fps.

    I have a few years old computer but I am not considering it as too slow generally. For my uses it is still performing well. I also play some games. Intel Core2quad cpu 2.40 GHz. 8Gb memory. (I wish I could have more but I have maxed the board) Nvidia Geforce 8800 GTS.

    I do not really plan to buy new computer until I really feel I have to, as said right now it is performing well for me.

    Then I ran on Ipad 4:

    Poor Ipad started to hack at 7500 objects already. then 7801 it hung.

  • The test is also with the exact same sprite image and if any FX are applied, the same FX to each sprite, I wonder how it would work with more variety.

  • [quote:c08k7zav]Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.

    You have to remember that Construct Classic was made in 2007, with it's last update in 2012. It's like comparing a computer from 2007 to one from 2012, of course it's not going to out perform it for any number of reasons, old software and bottlenecks or the new software being able to better use hardware, etc.

    Also there's a post just now with CC getting better results than C2.

  • [quote:2omnj66a]Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.

    You have to remember that Construct Classic was made in 2007, with it's last update in 2012. It's like comparing a computer from 2007 to one from 2012, of course it's not going to out perform it for any number of reasons, old software and bottlenecks or the new software being able to better use hardware, etc.

    Also there's a post just now with CC getting better results than C2.

    Where's the post?

    helena

    Basically you need to spread single array loop in to several ticks. So you use 'for each' system loops for X and Y and check with positions on the array. Don't know how to explain it better... create region within array would be best explenation, and then check each region per one tick. You will need couple of variables that will count current region and when both are eqal to final region, you reset them.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)