Jayjay's Forum Posts

  • Plus one to what digitalsoapbox said.

    Looking at the PROS only we saw:

    Construct 2(/3) - Nice editor and events

    Unity and custom coded C# - The game actually runs, plus consoles support, plus compatible with a lot more PC's

  • Seems a good comparison now then would be Unity particles and also optimizing the Construct 2, Godot, and Unity sprite benchmarks for retesting

  • Mobile test:

    -PixiJS: 3800 bunnies at 29 - 30fps on Chrome browser LG G4 (6000 at 26fps)

    -C2: 630 bunnies at 26 - 32fps on same device as above

    -Unity WebGL: does load after warning, does not scale to fit, does not recognize touch, 11fps in portrait with starting bunny count

    PixiJS Bunnymark desktop:

    Firefox 76200 bunnies at 50fps

    Chrome 75400 bunnies at 44fps

    Allowing Unity native to hit as low as 30fps I get 28761 bunnies, so it seems PixiJS has some great optimizations either in sprite batching or in the code behind it (I haven't tried optimizing the Unity version at all from the OP's git account)

  • Also just out of curiosity, since Unity also offers WebGL exporting.

    Would you mind providing performance stats for that as well?

    Might be interesting to see how Unity's WebGL export performs, compared to C2's.

    Good question! Here's my results:

    Unity WebGL in Chrome

    Bunnies: 5501

    FPS: 57*

    *That's not the constant FPS though, it would fluctuate between 54 and 65 quite a bit, with the occasional HTML5-usual jank, especially when spawning more.

    Unity WebGL Build export: https://dl.dropboxusercontent.com/u/471 ... index.html

    Out of further curiosity I gave Firefox a try with the Unity WebGL and got these results:

    Unity WebGL in Firefox

    Bunnies: 8331

    FPS: 55 - 56

    The same C2 bunnymark test in Firefox gave me some crazy (good) results:

    Bunnies: 11370

    FPS: 55 - 56

    So, it seems that Firefox is the only browser / browser engine right now getting *close* to Unity speeds on my PC, which tells me that probably Firefox is falling back to DirectX / ANGLE, Unity is using "real" DirectX calls, and everything else is using OpenGL? (mega-guessing here <img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Surprised"> )

  • Here are my results (desktop only, always displaying sprites):

    (typo on the GPU, ram is GDDR5 not DDR5)

    Proof:

    Chrome -

    NWJS 32bit -

    NWJS 64bit -

    Godot -

    Unity -

    Built files: https://dl.dropboxusercontent.com/u/471 ... esults.zip

    C2 HTML5 Bunnymark test: https://dl.dropboxusercontent.com/u/471 ... index.html

    Direct X Diagnostics:

    So in plain text:

    C2 on NW.JS v244 - 3500 bunnies 50 or 55 fps (32 bit vs 64 bit)

    C2 v244 on Chrome - 3500 bunnies 55 - 57 fps

    Godot Engine v2.1.3 stable - 8470 bunnies 55 - 60 fps (heavier dips when spawning, settles back out to roughly 60 fps)

    Unity Engine v5.6.0f3 - 16321 bunnies 56 - 58 fps

    Oh I fully understand and agree with you. We were left pretty high-and-dry when we were promised Mac OSX, Linux, and WiiU when we purchased our business licenses and then barely managed to make our Windows version of the game work (we had to downgrade our C2 and NodeWebkit just to export working exes and support Steam). It sucks even more when you have to answer to investors / clients / crowdfunding backers.

    But I have learned two things talking here about it:

    1. Nobody here saying "just give your source" seems to understand the legal NDA and copyright issues of doing that. It's not like we can ask Scirra to give us their C2 source when Construct crashes.

    2. This stalemate between people who actually make games and encounter issues and people who think thats entirely the fault of the game creators seems to never end. Even when other engines actually demonstrate better performance.

    I wouldn't call all those years with Construct wasted just yet. Construct was started as a free open source clone of Clickteam products and their newest one in development looks like its returning the favour (minus the HTML5-only export).

    Might be a very viable alternative for you.

  • it's the graphics drivers, which are native technology. As I repeatedly have to say to people who don't seem to believe this, graphics drivers are widely accepted to be terrible and can even completely ruin game launches. Here's two links to back this up:

    Batman: Arkham Knight had such poor PC performance it virtually ruined the launch - it ran fine on console, where the drivers are good quality and predictable

    "How to delay your indie game" specifically calls out struggling with GPU drivers: "Despite claiming to, their drivers just don’t properly implement the OpenGL specifications... Then a new OSX update will hit and everything will change again, yet at the same time I will need to still cater for the previous releases and older machines... it’s unbearable... Would I support Mac again? No."

    I always laugh at this argument. "Graphics card drivers are bad!" so you decided to use possibly the most unsupported and experimental platform (other than Vulkan, which seems to have better performance already), I.E. Web GL ?

    That still runs on graphics card drivers! You're still facing the same issue, just hiding it as "not my fault now!" when it's Chrome or Node-Webkit/NodeJS that's blacklisted it instead.

    The simple bottom-line is:

    1.) Most desktop graphics cards today are optimized specifically for DirectX (at least to 9.0c), and have varying degrees of OpenGL support, both integrated and dedicated

    2.) The same graphics card issues that occur in a native engine will still occur in HTML5 + WebGL, because you're still using the GPU to render graphics unless you're blacklisted and running software I guess?

    3.) Aside from a few neat tricks to convert native C++ to JavaScript like ASM.JS, JavaScript will always be slower than a majority native code by some amount. Sometimes by a very large amount, as we have noticed with collision and physics.

    3b(onus).) If you're someday going to be using ASM.JS why not also export actual C++ code that could be used in another game engine that supports lots more platforms and actually allows people to make viable/sellable commercial desktop and console games? It could be charged per export and still make plenty of cash for Scirra!

    To the people saying "You just event bad!" well if the engine is designed that way and I optimize my events as best I can to still have the functionality I need, and it's slow, but I code fairly averagely in some C# and Unity and it runs blazingly fast + with better compatibility on Steam than our previous Construct 2 title, is that not proof enough? It wasn't even a GPU limitation because we added MORE effects to our game!

    It's nice when that last argument is made by people who don't have titles selling commercially on Steam, who don't see the issues that occur and have to hear "Give me your source code and/or report it to Chrome or NodeJS !" every time they have an issue in the engine they purchased to make commercial games.

    Personally, I'd rather pay $100/year for Scirra to make a commercially sold large 2D pixel-perfect retro platformer in their own engine and then release and troubleshoot it on Steam, than to further invest in HTML5 with C3, and it sucks, because I really like the way Construct does game making (it still has an editor I love very much, which is what keeps me still fairly interested in the developments of Scirra ahead). I just need C2/C3's export to be a lot better for playing, and preferably sooner than "the future" where PC's drop in price to the point where everyone runs basically an Intel i7 CPU + NVIDIA GTX 960+ GPU and the problems "suddenly disappear now" magically.

    Triforce The arguments made above have been my experience, and the experience I have seen from other prominent Construct 2 games on Steam. You can listen to the people who haven't made large games if you want, but we have all roughly come to the same conclusions: C2 is great for hobbyists, educators, and personal or small games. But when you need to get larger, make some prototypes and test a LOT before deciding to stick with it.

    With C3 you can get on Steam and iOS. That's more than enough exporting features for you to make money and get exposure with. I think the major problem with developers is phycological. There's a mindset that "if you are not coding you won't ever get the flexibility you need".

    You need to minimize your game development problems and C3 does that.

    While Steam alone is okay for sales (but not really "enough" to run an indie studio on without being extremely popular), I would say iOS / Android are both very hard to make any commercial success on without falling back to in-app-ads or token-purchase systems and free-to-play models.

    The console export options that became available to us after switching engines had made a substantial difference in both the success of our crowdfunding campaign, and the global press that our game has received so far.

    For other benefits that switching to code gave us check out my post here:

    However, Scirra can't control when and where a 3rd party wrapper will be available, so it's best to assume that the only true export of Construct 3 is HTML5. Console support so far has been unsuitable for commercial titles to rely on, and that might continue on indefinitely if console makers don't wish to enable full HTML5 + WebGL.

    Basically: Don't try to minimize the other options available, they are tools for a purpose, and if you want to make large and/or commercial games for consoles and mobile they're a safer bet.

    Construct 2/3 is great for hobbyists, web games, educators, and freeware, but having released our previous Construct 2 game on Steam we have learned the hard way that most computers buying 2D games are still not ready for HTML5 + WebGL.

  • Scirra is sticking to their plans on Construct 2 and Construct 3: All exporters will be HTML5 + wrapper based for the long-term ahead.

    There was talk very early in the development of Construct 2 for other exporters way back when it was starting (which is why HTML5 is in a folder called "exporters" in your Construct 2 folder), but that was cancelled equally long ago.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    After the many posts and the locked thread, it seems the best option for Construct users now is to wait and see how the subscription turns out. Scirra really wants to try it, and if it works out then that's great for them (and us) !

    If not, they'll hopefully have a backup plan ready in time

    But, I would say it will be one or two years from now before we know for sure (eg: many people might try one or two years before trying something else, so it's still pretty risky for Scirra if big/long-term projects aren't being made).

    That's okay though, we've all been waiting many years already for HTML5 to be the high performance multi-platform export format of choice for 2D gaming anyway, what's the harm of waiting a few more?

  • Top-down games seem to work pretty will in Construct 2/Construct 3, but I would say it comes down to this:

    1.) Is your game CPU heavy? (eg: lots of line-of-sight, and maybe physics stuff going on?)

    2.) Is your game targeting a wide variety of desktops, and is it commercial (eg: do you want to release on Steam?)

    3.) Do you want console export? (eg: anything beyond "Wii U and Xbox One", which are themselves in quotes because they don't have full performance on the hardware that a native engine would)

    If you answered yes to any of those three questions, especially the commercial one, and you really are making a "large" game, I would advise looking elsewhere.

    There are many who are happy to say there's "virtually no" difference between native and HTML5, but having made the switch ourselves we can say:

    -We gained FPS after re-coding in C#, this makes sense since JavaScript is inherently slower in most cases

    -We could use fancy effects that didn't seem to slow down as much as WebGL did, even if we used more of them

    -We now support consoles, and for that matter, a much greater variety of desktops

    -The game in general "feels smoother", it's hard to explain but as a long-time Construct Classic user I can say that (to me) C2 never felt as smooth as CC did, and switching to native again with our latest title seems to re-confirm those suspicions.

    Otherwise? Construct 2 / Construct 3 should be a great option

    Hope that helps!

    Didn't you finally want to leave the good people here alone?

    Tom we really need a Block function in the new forums.

    But how would a block function work?

    Does the owner of a thread have the ability to block someone from posting in their thread?

    Does it just hide the other users' posts from you? Or have a button to see it when you want to know what they said?

    Does it stop them from being able to reply to you / quote you / tag you?

    Being able to choose what information to see or ignore is yet another reason why arguments start, I don't think it would make things better.

    However, for hateful posts you can surely report them.

    Whatever I, and other developers here, may have said about Construct. It doesn't mean that Scirra's team isn't working hard, just maybe not towards the outcome that we would like (again, I'd like for Scirra to take a stance on that moving forward with C3) and the mods are also great at responding quickly.

    Construct has a great community, these arguments are growing pains as Construct morphs into its next evolution. Right now, to me, it's looking like it's going more the way of "Scratch" with hobbyists and web and educators having the best time with it, and some mobile/"light console" as optional bonus features.

    If Scirra advertised the tool that way, I would never have a problem with it, although I would see partially missed potential for console export from Construct's awesome editor, that's just personal opinion.

    At the same time, threads like these serve as a "canary in the coal mine" for other developers, so they know when it's time to move on from their prototypes and free games to other engines if they seek commercial and console content (or to let them know if they even have to change engines at all, which currently the consensus from showcased and other "serious" devs seems to be: yes)

    Yeah, I think the response Lamar is looking for belongs in his other thread which was locked. Lock this one and unlock that one maybe?

    How would you like us to deal with bug reports that don't meet the minimum requirements to investigate? Do you have a link to some of them that concern you?

    Ideally I'd like for Scirra to try recreating the described situation, work with the paying customers to reproduce what it is they assume they are trying to do, and spread knowledge about how to do that properly, rather than closing as won't fix.

    For example, here's some in the past 6 months:

    Graphical issues NW.js: Closed for using a third-party addon and not being "minimal" (how do you do that when you have a full sized game and might not know if it's merely a size-of-the-game issue?)

    Platform jump height variation: Closed as won't fix (so no pixel perfect games allowed eh? too bad Retro is the most common 2D game people like to make)

    Issue with platform behavior: Closed as won't fix (A jump command should be received that tells the platformer to only check for being on ground once the velocity Y is below 0 again)

    Pin behavior position lag: Closed as can't fix (why not give the user some means of control over the order in which behaviors will be executed?)

    Choppy/Jerky Frame Skips: Closed as another Google issue / "can't fix" (Great, says every customer expecting decent mobile export)

    Also R0J0hound I think it's safe to say that those passmark results are comparing against other users who are into "passmarking"/benchmarking. The Steam HW survey is even slightly biased as it is probably has more gamers who play 3D games than 2D.

    For a strictly-2D sense, the average hardware we're seeing does dip down into Windows XP and Vista users, and they do still get very vocal when our game doesn't work (and we told them in requirements that it wouldn't, not even marketing to them as possible or "functional" on their OS !).