So What Is Your Second Impression of C3 And Will You Buy?

I can confirm what Havok has said about the "Weather Demo". On my iMac it runs very badly, yet no problems in windows under parellels.

I can confirm what Havok has said about the "Weather Demo". On my iMac it runs very badly, yet no problems in windows under parellels.

Thanks Ethan, but mine runs badly under Parallels as well.

Can anyone on a Windows machine run the weather demo and see if it runs smoothly? Don't even walk or move etc.

Looks like it's the reflection eye candy.

But then what does that mean? It's fast as long as you don't use effects?

Running some https://threejs.org/ demos, things are fine. Fast and running well.

Windows 7 Pro, Geforce GTX 970, x64.

Runs at steady 60 FPS until around 4000 objects then starts to drop to around 40-50 fps.

I have no performance issues on my iMac.

Editor is smooth, Preview is Smooth.

iMac - 3.4 GHz Intel Core i5 - 24 GB 1600 MHz DDR3 - NVIDIA GeForce GTX 775M 2048 MB

Rain Demo

Getting 60FPS until i hit like 5000 objects, then start dropping.

Just a heads up, I just checked out the Rain Demo and found out that C3 is not recycling objects properly.

If you try it in C2, you will see that the object count never really goes beyond 350, while in C3 it steadily goes up.

Edit: Fixed in the latest version of C3 (r17).

DiegoM Yeah I saw it didn't destroy and just carry on.

Now of course with only about 290 or so objects on it stays at 60fps.

I guess we know what the limitations are now for target platforms - safe to say no more than a 1000 objects on screen.

I suppose a bit less for PC's with no dedicated GPU.

I just read Ashley's new blog posting about Construct 3's memory usage. He seems to be happy with Constructs memory footprint?

Perhaps I am comparing apples with oranges, but... I loaded up Fusion 2.5 (Windows 7) and Godot (Linux Mint) out of curiosity, and compared memory footprints.

Linux Mint (harder to measure, I loaded each application and compared the difference in memory usage before and after loading)

Godot + platform demo game loaded up: ~135mb (game level visible in editor)

Chrome + Construct 3 + Kiwi project loaded up: ~600mb (game level visible in editor)

Windows Process Explorer

Fusion 2.5 + 39mb project loaded up: private bytes: ~72mb, working set: ~127mb (game level visible in editor)

Godot + ~180mb project loaded up: private bytes: ~308mb, working set: ~187mb (game level visible in editor)

Chrome + Construct 3 + Kiwi project loaded up: private bytes: ~890mb, working set: ~811mb (game level visible in editor)

With Chrome, 7 processes are opened in Windows, and although the Kiwi process's footprint by itself is 105mb working set, I think it is fair to add all Chrome processes together, because Chrome serves as the platform to run Chrome.

Take this as you will.

My personal opinion is that Chrome gobbles up unnecessary amounts of RAM even before loading Construct 3 - and in the case of Windows I loaded up larger projects in Godot and Fusion 2.5! It also explains why Construct 3 struggles on my older 4gb Windows machine: Together, Chrome and Construct swallow almost a quarter of the memory!

*Private Bytes – the amount of memory allocated to this program alone.

*Working Set – the amount of actual RAM allocated to this program by Windows.

Delenne - I opened Kiwi Story in C3 with Chrome Canary and it only used around 300mb of memory. It might be worth checking your browser addons, some can add a lot of extra memory usage, especially ad blockers.

Delenne - I opened Kiwi Story in C3 with Chrome Canary and it only used around 300mb of memory. It might be worth checking your browser addons, some can add a lot of extra memory usage, especially ad blockers.

Yes add ons can cause it (check Helper Objects on Mac in activity monitor - I've tested it, disabled adblock plus and https everywhere for instance, then the memory usage drops a bit). So now if someone is a Chrome user they will have to disable all addons etc to get the performance in Chrome. Not so bad if you use another browser for regular browsing etc, but irritating if you are a Chrome user. Unless get a beefier PC.

Not an ideal situation but we are beating a dead horse here.

C3 runs in the browser, with all the benefits that brings, but also with it comes all the negatives. i.e Construct 3 won't be as fast in performance as Fusion 2.5-3 , GameMakerStudio 2, GameSalad, Stencyl, Unity.

The question one should ask what is fast enough for your specific game you are trying to make. I think for most it will be fine. I really hope so. I like Construct and got along with it better than the other applications. However bad performance is obviously a deal-breaker if your game doesn't run well on a platform even though you did optimize it etc.

I suppose when you wrap it up so that Chrome runs on the desktop for the C3 editor it won't be submitted to the addons, ad blockers, cookie blockers etc and will get better.

C3 runs in the browser, with all the benefits that brings, but also with it comes all the negatives. i.e Construct 3 won't be as fast in performance as Fusion 2.5-3 , GameMakerStudio 2, GameSalad, Stencyl, Unity.

That's not actually exactly right: in some cases the browser tech is very advanced and can exceed straightforward native code. For example Chrome has a sophisticated parallel rendering architecture, so all WebGL calls are forwarded to another thread and run in parallel while the next frame starts rendering. This essentially lifts the performance overhead of the graphics driver off to a different core, which can actually result in improved performance vs. a native engine that does not implement such parallel rendering. It's a difficult and complex feature to get right, and we certainly didn't try for the CC or C2 editors. So this aspect is probably faster because it's in a browser. On top of that we moved from OpenGL 1.1 in C2 to OpenGL ES 3 (WebGL 2) in C3, and C2 has a lot of JS <-> native transitions which is expensive performance wise (and can more than undo any performance gains in the native code), and C3 has no transition overhead because it's all in JS.

So you can't just say "it's slower because it's in a browser". There's a lot of tradeoffs going on, and in some cases leveraging the browser tech brings improvements even over native code.

> C3 runs in the browser, with all the benefits that brings, but also with it comes all the negatives. i.e Construct 3 won't be as fast in performance as Fusion 2.5-3 , GameMakerStudio 2, GameSalad, Stencyl, Unity.

>

That's not actually exactly right: in some cases the browser tech is very advanced and can exceed straightforward native code. For example Chrome has a sophisticated parallel rendering architecture, so all WebGL calls are forwarded to another thread and run in parallel while the next frame starts rendering. This essentially lifts the performance overhead of the graphics driver off to a different core, which can actually result in improved performance vs. a native engine that does not implement such parallel rendering. It's a difficult and complex feature to get right, and we certainly didn't try for the CC or C2 editors. So this aspect is probably faster because it's in a browser. On top of that we moved from OpenGL 1.1 in C2 to OpenGL ES 3 (WebGL 2) in C3, and C2 has a lot of JS <-> native transitions which is expensive performance wise (and can more than undo any performance gains in the native code), and C3 has no transition overhead because it's all in JS.

So you can't just say "it's slower because it's in a browser". There's a lot of tradeoffs going on, and in some cases leveraging the browser tech brings improvements even over native code.

I hear what you are saying Ashley and yes there are benefits.

Real world usage looks different currently, although unfair since C3 is still in Beta.

It's one thing running benchmark set up for specifics. It's another when a "Non Coder Game Developers" starts using or comparing the engines back to back and make the conclusions based on what they experience first hand.

So far I'm feeling quite confident that it will be fast enough for my needs although I'm obviously not the only one with concern looking at some of the posts. I'm just wondering where the ceiling lies and if the memory usage are so high (Chrome + Content exported to a Runtime be it Desktop or Phone) that there would be a higher Minimum Requirement on end users to play our games.

Quote Ashley referred to in his blog post:

"And chrome is a hog. Its huge and complicated. It uses ram and CPU like nobody's business, and it totally thrashes your battery life."

This statement is absolutely true, at least on a Mac. I posted my findings in the now deleted Official C3 information thread about this. Chrome is no way optimized for use on a Mac, and it's even missing features the PC has. Google simply doesn't care. I'm surprised they have a Mac version at all, because Apple is not friendly to Google. Apple is all about protecting user's privacy, and Google is all about taking as much information from you as possible and then selling it.

Delenne - I opened Kiwi Story in C3 with Chrome Canary and it only used around 300mb of memory. It might be worth checking your browser addons, some can add a lot of extra memory usage, especially ad blockers.

I deactivated all the extensions in Chrome on my Linux Mint and Windows 7 - memory usage is now about equal on both platforms: ~450mb with the Kiwi project loaded up in Linux, ~520mb in Windows.

I have the following extensions on both platforms: Adblock Plus, and the Google applications (Docs, Sheets, Slides).

Much better now than the ~800-900mb on Windows.

When I preview the Kiwi game, memory usages goes through the roof again: an additional ~200mb is used for the preview window in Chrome!!! (Linux and Windows).

My view is that Chrome is a memory hog, and needlessly gobbles up memory, and that is bad news for anyone building a web app with Chrome as a foundation.

Not an ideal situation but we are beating a dead horse here.

C3 runs in the browser, with all the benefits that brings, but also with it comes all the negatives. i.e Construct 3 won't be as fast in performance as Fusion 2.5-3 , GameMakerStudio 2, GameSalad, Stencyl, Unity.

The question one should ask what is fast enough for your specific game you are trying to make. I think for most it will be fine. I really hope so. I like Construct and got along with it better than the other applications. However bad performance is obviously a deal-breaker if your game doesn't run well on a platform even though you did optimize it etc.

I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb. Needless to say Godot runs smooth even when in preview mode on the same machine. And I tested by far more complex projects in Godot on the i5 machine.

My advice for now: stay away from Construct 3 if your intention is to create action games that must also run smooth on lower spec'd machines. And it worries me that the performance of such a simple game like Kiwi is lacking on a i5 4gb spec.

Note: I could not test the exported version of Kiwi, because C3 does not allow me to export the game. I would be surprised if it made any difference, though. Ashley: maybe it is a good idea to allow export of the demo games, so users may get a better idea of published game performance? Or is a published version of Kiwi available online?

I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb.

Please provide actual benchmark numbers, otherwise this kind of statement is worthless.

My office machine can render over a quarter of a million on-screen sprites at 30 FPS in Chrome, so you can get great performance in a browser. A single actual measurement is worth more than an entire forum full of vague statements.

Ashley, and Tom, If you need any help with benchmarks, and or moderation of our little terrorist, Im more than happy to help.