Native Desktop Exporter for Construct 3

0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • I only read the last few posts in this topic so dont mind me if this is completely off-topic.

    Personally I normally thought Native Exporters for C2 (C3) would be a good idea, however the points Ashley made are quite good and so I changed my mind.

    However a thing that C2 (C3) would benefit hugely from would be the option to use multithreading in games. To utilise more than one core.

    In theory this may not bring that much of a performance boost, I personally had to use some workarounds to achieve better performance, but I still think for a really physics intensive or large RTS game for example multithreading could be a good thing. On the other hand the percentage on games that actually would benefit from that would be so low that it may not pay off for Ashley to implement it.

    Maybe on Mobile phones it could be a good thing to have multithreading as most phones have at least 2 cores nowadays?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • The latest version of the test is here, the blog one is out of date and may be using an older/slower version of the engine: http://www.scirra.com/demos/c2/renderperfgl/

    For a fair test the browser window should be the same size as the CC window so the GPU fillrate is the same. It's not actually a fair test though, since the WebGL test uses larger and rotated sprites and the CC test uses smaller unrotated sprites, so it does not have to compute any rotation and uses less fillrate. Despite that my desktop gets pretty much identical scores between CC and WebGL (~110,000) and my laptop is close (~51k WebGL, ~57k CC) with native being only about 10% faster. I think this demonstrates a good browser and WebGL implementation *can* reach native-like speeds. Rewriting the entire engine N times over for N native platforms , holding off all other features in the mean time, and having ongoing portability headaches, all for a 0-10% performance boost on the two systems I've tested... how is that worth it?

  • The latest version of the test is here, the blog one is out of date and may be using an older/slower version of the engine: http://www.scirra.com/demos/c2/renderperfgl/

    For a fair test the browser window should be the same size as the CC window so the GPU fillrate is the same. It's not actually a fair test though, since the WebGL test uses larger and rotated sprites and the CC test uses smaller unrotated sprites, so it does not have to compute any rotation and uses less fillrate. Despite that my desktop gets pretty much identical scores between CC and WebGL (~110,000) and my laptop is close (~51k WebGL, ~57k CC) with native being only about 10% faster. I think this demonstrates a good browser and WebGL implementation *can* reach native-like speeds. Rewriting the entire engine N times over for N native platforms , holding off all other features in the mean time, and having ongoing portability headaches, all for a 0-10% performance boost on the two systems I've tested... how is that worth it?

    Beat me to it.... I had a feeling about that so I created a current stable C2 capx with the same dimensions as the CC example. Results were a lot closer this time around! I agree a good browser & WebGL can reach it but for desktop publishing... it's like wrapping a sandwich in a tire. Especially when that good browser is having issues. I think mostly, people are venting due to the recent issues with Node. Great they updated it, but it still hasn't fully resolved the jitter/jank issues and many of us are still effected by it. Plus it makes it hard to optimize and troubleshoot when jittering could be a cause of either node or ill formed events. And this leaves many of us waiting around until a node update or using older node versions.

  • Using the new demo, with a window-frame (including the shell) resized down to 686x583px in Chrome I get: 29 to 30 FPS with 15042 objects in WebGL, it started to have some stuttering after 10k objects.

    With the CC native demo I reach 21k objects at 32FPS (window-frame is 1040x807px), and don't get down into the 29-30 range until 23010 objects, and based on a long time of using CC I'm betting that even rotation wouldn't hurt it too badly. By 24k objects I'm still at 27FPS, in fact sometimes it even reports 30FPS at that amount.

    64-bit Windows 8.1 with Pro Media Center

    AMD Athlon II X4 645 Processor (quad-core) 3.1GHz

    8GB DDR3 RAM

    Nvidia GeForce G210 1GB DDR3 VRAM

    I know my GFX card isn't great, but it can run a lot of newer games at decent enough framerates, especially combined with the CPU. The only software I'm running at the same time with any web capabilities are my browser (Firefox), Steam, and Dropbox.

    The sad part is, my PC seems to run HTML5 + WebGL games much better than a lot of (very vocal) customers of my game who have similar/better specs but have horrible framerate, latency on input, and so on. That's why the "small difference" matters to me.

    Edit: Tried the HTML5 + WebGL (newer) one again with a Chrome window-frame size of 1032x801px, this time I got 29-30FPS at only 6963 sprites! That's only 33% as good as CC for me, and yes that was the only tab on Chrome. I ran it in the exact same environment as the native and first html5 test, and yet a small increase in resolution dropped my object count by nearly half.

    Based on Steam's recent Hardware Survey results ( http://store.steampowered.com/hwsurvey ), these are the most popular specs they have for Windows users:

    Windows 7 64-bit (>49%)

    8GB RAM (<29%)

    Intel (>75%) dual-core (>48%)

    Intel HD Graphics 3000+ (most popular for all DirectX 10.x+, by around 5% to 15%)

    1GB VRAM (< 34%)

    1920x1080px Resolution (>33%)

    Of course that's just an average, but it's either equal or lower than my PC in every area, which means I can't afford to benchmark for a super gaming PC with my 2D "indie" titles anyway.

  • 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.

    +1

    Thanks for your honest post.

  • Personally i dont think the fact that native does or doesnt perform better is the real question. As it stands Scirra have no control over the output to desktop or mobile. Ashely has constantly said to publish to the web and let players play that way. Thats fine if you dont want to sell your games but i think most users want to do exactly that. I dont expect Scirra will produce a native desktop exporter but there should be some way in which they control the wrapper if thats what it has to be.

  • C3 should consider going the MonkeyX way... convert internally the exported code to C++ & OpenGL (depending on the platform) and compile natively on the target platform.

    Otherwise C3 is just C2+

  • spongehammer

    C2 is mainly used by newbies, so Ashley knows that 99% of C2 users will not release anything serious. And if they release then... well... they can wait a few months for 3rd party fix of some critical bug

    In case of Unity or Game Maker they have different target: real developers with real expectations and real money. So they pay more, but they also expect taking responsability.

  • szymek To be fair, I have to add no Steam user is complaining about the perfs on PC or Mac. NW seems to do the trick for now.

    I'm worried Scirra has no control on this third party solution, but nw10.5 works just fine.

  • It's not necessarily performance or features that make a native exporter desirable, it's the reliability. As stated earlier, NW & Chrome (the most popular platform afaic) often introduce game breaking bugs in-between updates and there's literally nothing anyone here can do about it. We just have to wait. Every time. Frankly it makes people hesitant to use C2..at least for medium/large-scale projects. I know native exporters are not practical though so I stopped asking for them. Makes me wonder how many other people just decided to use a different engine though.

    Ashley: I completely agree with your thought process. It does make a lot of sense and also it's clear that nowadays the difference between native and webgl is really minimum.

    What would probably help here is for Scirra to take into their hands the situation with wrappers a bit more.

    On the NW side, just take control of which version you present for C2 users.

    Is there a breaking bug in the new Chrome? Simply don't update until that is fixed. Going for the latest and greatest is not always a good approach.

    Android? Same thing. Maintain your version of Crosswalk!

    iOS? Create a webview project and maybe even access native things like camera or gamecenter hooking it to Javascript.

    This way you won't have to recreate a whole browser, but you'll have major control over what is done behind the scenes in that part of your engine.

  • > 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?

    It's on the very page your post is on, how did you miss it? There's also this one.

    C3 should consider going the MonkeyX way... convert internally the exported code to C++ & OpenGL (depending on the platform) and compile natively on the target platform.

    Otherwise C3 is just C2+

    I've been saying that currently C3 is just C2+ but obviously nobody is reading my posts. At this point, Construct 3 is essentially just Construct 2 with DLC.

    szymek

    [quote:3slhy69h]In case of Unity or Game Maker they have different target: real developers with real expectations and real money. So they pay more, but they also expect taking responsability.

    So Aurel , who developed The Next Penelope is not a real develpoer with real expectations who spent real money buying Construct 2 like everybody else on this forum who has a license?

    I think Ashley has to realize that Construct 2 is getting more and more attention as a viable game creation engine yet doesn't want to add in important additions to the engine because they're too much work. I remember a couple months back he made an update which improved C2's performance when destroying objects. And that 10% increase in performance of Native over current can make a huge difference. A lot of games can rely on split second decisions and player reaction time that is in the tens of miliseconds (ms), every bit of improved performance counts. Imagine if nobody optimized their games, it'd be ridiculous. Every game ever released would be another Crysis.

    People want to make games, and that's it. A lot of users here, me included don't have money. We spend what little money we earn on Construct 2 because of expectations that it most of the time lives up to, but then on some of the bigger ones just hides.

    If Construct 2 and Construct 3 hope to be serious engines, they need to adapt. There's a common logical fallacy where people for example, have a car they spent a total of 7000$ on so far. It breaks down and it costs 1400$ to fix it, but they can buy a better car for 1600$. Yet they fix it because "they've already invested the 7000$, so lets not make that go to waste". Sometimes you simply have work from the ground up again.

    Construct 2 targeted portability, and it's done exactly that. So far it's only good for phones and desktop computers if Node-Webkit decides to be merciful (the fact that I can make that joke shows how bad it can get).

    Construct 3 needs to target actual full game development, from idea to exporting native PC and console applications. We do not need two versions of the same engine. Make the numbers mean something.

    1 was the time of Direct-X and was experimental, it succeeded and blossomed into 2, which is more powerful in some aspects. Construct 3 needs to be a major improvement of both, not an extension of the second.

    To be honest, I'd be happy with Construct Classic getting Construct 2's interface and all it's bugs fixed (and maybe its languages changed to C++).

  • >

    >

    > Where's the post?

    >

    >

    >

    I thought you might have been referring to another post. No worries. thx

  • On a similar note, imagine previewing natively! Currently, I am getting audio that is not playing in Node-Webkit preview, but it works fine once I export.

    I thought the point of preview was to see exactly how it would play without exporting. Kind of self-defeating purpose if you guys ask me.

  • On a similar note, imagine previewing natively! Currently, I am getting audio that is not playing in Node-Webkit preview, but it works fine once I export.

    I thought the point of preview was to see exactly how it would play without exporting. Kind of self-defeating purpose if you guys ask me.

    I used to have audio on preview ( 2 years ago, in one of the old very small project that I've got far enough with to have audio ), but didn't try it out since. On the contrary, when I recently played Areoscape demo on steam, I had no audio at all. Thing I couldn't even play it at first because game was showing me message that webGL is not supported, which is not true. I did check it out. And you can see my specs below. So I replaced nodewebkit with 0.11 and game worked, but no sound.

  • megatronx

    Strange isn't it? I used to have all my audio functioning normally in preview, sound effects and music files.

    Now that's gotten completely broken, half the time it doesn't work and when it does it doesn't load all the files which breaks my game since some events need a sound file to finish to return the time scale to 1.

    Now, the only way I can preview my game is to export it. I only ever use Preview for simple stuff like animations, anything more gets exported.

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