Native Desktop Exporter for Construct 3

Discussion and feedback on Construct 2

Post » Fri Jan 30, 2015 11:28 am

How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.
I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)

lots_o_sprites.capx


[On a side note, I started adding Groups to the code to help profile, and I noticed when I added a certain Group the FPS dropped from 40 to 25. Just an empty group! If I remove or even disable the Group, FPS goes back up. Please see the "UpdateValues" group in the capx. BTW an exported version is unaffected this way.]
You do not have the required permissions to view the files attached to this post.
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Fri Jan 30, 2015 11:29 am

spongehammer wrote:It would be interesting to know the percentage of C2 users who write for desktop only and have no interest in mobile.

I have little to no interest in mobile.
B
42
S
23
G
18
Posts: 154
Reputation: 12,475

Post » Fri Jan 30, 2015 11:33 am

EVERYONE! EVERYONE! ATTENTION! ATTENTION!

I just had a magical epiphany.

Now, this idea may seem stupid since it's technically fueling Sccira's competition, but what if, and I think this is a win-win scenario for everybody so hear me out.

What if Ashley made Construct 3 as he intended, that is a Construct 2 extension.

And made a Unity2D asset that mimics Construct 2's event system for those of us what need/want need to export natively to PC and to export at all to consoles.

First off, we'd still be supporting Scirra by buying it, second, it would be great income since, imagine Unity's powerhouse with Construct 2's editor. Just holy sh*t you guys. Third, we'd have an improved Construct 3 for those of us who still want pure HTML5 fun, and those of us who need it could buy the Unity asset for consoles and native PC.

That way, Ashley doesn't need to bother with making a entire bloody engine, we don't have to nag him unrelentingly for native anything and he stills get more income! It's perfect! And he's also be getting into the entire Unity market, so that's a huge new potential customer base.


@Ashley, let me know what you think of it.

TL;DR

Ashley makes a Unity asset that is basically Construct 2/3's event system, thus pleasing our native and console wanting cherry pies.
Construct 3 gets to be whatever Scirra wants without backlash from pissed off users since they have the asset for any needs like console exports and native PC.

@Squiddster
@Aurel

What do you two think of this?


P.S. Also imagine if you could copy paste events between them? Not the code beneath the events, but the actual events, thus you could have insta-translation from Construct 2's HTML5 to C#, Boo and UnityScript.

Best idea I've ever had on these forums.
Last edited by Nesteris on Fri Jan 30, 2015 11:34 am, edited 1 time in total.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Fri Jan 30, 2015 11:33 am

codah wrote:How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.
I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)


Did you try DevilMark in the previous posts? native-desktop-exporter-for-construct-3_p879965?#p879965

Also sort-of built to be similar to their demo thing and it gets some rather good results. Notas good as pixi, but still makes C2 look good.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Fri Jan 30, 2015 11:36 am

Somebody wrote:
codah wrote:How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.
I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)


Did you try DevilMark in the previous posts? native-desktop-exporter-for-construct-3_p879965?#p879965

Also sort-of built to be similar to their demo thing and it gets some rather good results. Notas good as pixi, but still makes C2 look good.


Yea I did although it doesn't appear to behave just the same (although probably doesn't matter). Did you try mine? I copied their JS code as closely as possible. See if you can get that comparable in performance to theirs :) I'm talking mobile ...
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Fri Jan 30, 2015 11:38 am

When talking about performance, I think it's important to keep in mind that the most effective optimisations are always performed at the high-level, i.e. game logic and resource management, that is turning "naive" things into "less naive" things, and either doing something differently in order to achieve the same result faster or compromising on the complexity to find a better balance between user experience and performance. Assuming the developer knows what the target platform perf killers are, as abusing alpha blending on a mobile chip that performs poorly in that area will never fly well ; just an example.

Only then, when all the low hanging fruits have been collected, can the low-level optimisations become useful. Platform specific low-level optimisations, such as vectorised math libs and so on, will unlock the next ~20% of performance, but it won't auto-magically turn a struggling 10fps game into a smooth 60fps one.
Also, these optimisations are exponentially costly, i.e. the more a software is optimised, the harder it is to optimise it further, and the more costly it becomes to save another 1ms. Plus, at this level, what is beneficial to one set of devices is usually detrimental to another, therefore multiplying by a factor ~5 all the work (desktop computer, console, high-end mobile, medium mobile, low-end mobile)

What I'm getting at here is the "game dev time vs performance optimisation time" balance ; when working towards a deadline reducing game development time is always the most effective solution, as it gives more time to perform high-level optimisations which will give the best results in terms of performance. That's where the productivity of tools like C2 shines. We can get something working quickly ! And then if performance is an issue in my game, maybe I just spend a few days to rework some behaviours or levels and save 20ms ; where it would take months of programmer time to save 1ms on physic collisions maths. That's a complete different order of magnitude.

Know your game, know your logic, know your devices. Don't rely on low-level engine optims and exporters for performance ; it can help, but there's no silver bullet.


Additionally, a quick word on broken exporters. It can happen. It's always a risk. Every company or project, big or small, faces the same risk, e.g. when choosing an engine, a tool, a service provider, a manufacturer, a 3rd party contractor, etc. They can defect, and you're never left in a good position. That's part of the risk assessment process, and ideally there should be a mitigation plan for it.
But most of all, choose an engine for what it is, not for what you want it to become.


Anyway, all of that being said, from my point of view the future of Construct should focus on the productivity of the game development tools : more user-friendly IDE, better debugger (huge potential time savings here!), etc. ; not on trying to cater for every details of every project on every platform.
Last edited by Refeuh on Fri Jan 30, 2015 1:44 pm, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Fri Jan 30, 2015 11:49 am

codah wrote:Yea I did although it doesn't appear to behave just the same (although probably doesn't matter). Did you try mine? I copied their JS code as closely as possible. See if you can get that comparable in performance to theirs :) I'm talking mobile ...


Yeah, their performance for the same thing is just insane. And it really FEELS smooth, not just in that sometimes weird "high fps, clumsy feeling" that some C2 exports have. I wonder what they are doing differently.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Fri Jan 30, 2015 12:16 pm

Everyone ignoring my previous post?
#IdeaWasted
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Fri Jan 30, 2015 12:44 pm

@Nesteris I may be wrong, but I don't think you can apply the C2 logic to a 3D engine (even to export 2D games). It's very different.

Also, it kind of already exists. If you really want an event system for Unity, did you ever try Playmaker?
http://www.hutonggames.com/
It doesn't work like C2, but does a very good job for beginners wanting to jump in Unity + visual scripting : )
( should you need some games examples, it has been used in Hearthstone, The Forest, Dear Esther...)
Last edited by Aurel on Fri Jan 30, 2015 1:11 pm, edited 1 time in total.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Fri Jan 30, 2015 1:06 pm

Regarding pixi.js, the main performance difference is the overhead of the event engine. Bunnymark probably uses a line or two of simple JS code to move the sprites, whereas using events involves the use of the well-optimised but fairly significant general-purpose object-picking/action-running event engine. A fairer test is probably renderperfgl, which doesn't move the objects (therefore not needing the event engine), but also does handle rotation (which bunnymark doesn't and probably uses to optimise further). It's still not really a fair test since they are doing different things, but comparing those two I get approximately equal results. The C2 renderer is really pretty much as fast as it can be anyway: it basically copies numbers in to a big typed array and passes it to WebGL.

As for doing anything involving Unity I think that is completely bonkers. Besides it seems odd that on the one hand some people complain that we depend on third parties for browser technology, and then others suggest solutions that again involve depend on third parties (be it HAXE, Unity or some other intermediary technology). No technology is perfect, and we could be equally hosed by shortcomings in those. Browsers on the other hand are written by billion-dollar companies with thousands of expert engineers, so if we are to depend on any third party, that seems like a better bet.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Tinimations and 7 guests