Native Desktop Exporter for Construct 3

Discussion and feedback on Construct 2

Post » Wed Jan 28, 2015 7:51 pm

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?
"It's done when it's done"

Shadows of War
Buy on Steam ;)
B
24
S
10
G
7
Posts: 253
Reputation: 4,931

Post » Wed Jan 28, 2015 8:54 pm

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?
Scirra Founder
B
402
S
238
G
89
Posts: 24,628
Reputation: 196,023

Post » Wed Jan 28, 2015 9:33 pm

Ashley wrote: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! :D 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.
Image Image Image
B
63
S
19
G
6
Posts: 325
Reputation: 7,994

Post » Wed Jan 28, 2015 10:32 pm

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.
Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
127
S
43
G
18
Posts: 2,240
Reputation: 20,592

Post » Wed Jan 28, 2015 10:57 pm

Aurel wrote: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.
B
18
S
7
G
1
Posts: 783
Reputation: 4,247

Post » Wed Jan 28, 2015 10:59 pm

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.
B
51
S
16
G
9
Posts: 1,098
Reputation: 11,252

Post » Wed Jan 28, 2015 11:12 pm

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+
B
43
S
11
G
4
Posts: 428
Reputation: 7,459

Post » Wed Jan 28, 2015 11:14 pm

@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.
B
18
S
7
G
1
Posts: 783
Reputation: 4,247

Post » Wed Jan 28, 2015 11:17 pm

@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.
Last edited by Aurel on Wed Jan 28, 2015 11:43 pm, edited 1 time in total.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Wed Jan 28, 2015 11:23 pm

Tokinsom wrote: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.
B
33
S
4
Posts: 57
Reputation: 1,575

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: bp6, Google [Bot], TheRealDannyyy and 5 guests