FPS Stats

0 favourites
  • 7 posts
From the Asset Store
Create a game inspired by great arcade classics as Operation Wolf
  • Hey all,

    I am fluctuating a lot with my view on Construct. I recently expressed my excitement from the news of a new Runtime beginning development at some point, I was impulsive with posting my enthusiasm... But I did start thinking about the time between the "start" of Construct 3's development and how that took a fair amount of time and caused a quietening for C2 updates whilst C3 was being worked on. I'm now presuming that rewriting a completely new runtime would take muchhh much longer than the editor did to develop, not to mention the whole maintaining two codebases now for C2 and C3 (unless C2 gets the axe, I'm not really sure what's going on there right now).

    So... with a growing impatience and curiosity of what's out there to support the type of game I want to produce (busy, fast-paced, action game, for Windows), I've begun to start peeking at other free software in the mean time, I wanted to get an idea of the raw performance from just having 1 thing going on in a game, which I'm unsure if it is the most best way to benchmark things, but I quickly smacked together some stuff just to see and thought I'd share with everyone. I did a test involving 1 sprite that you can move left and right with A and D... Nothing more, nothing less.

    I took a look at GDevelop, that software that looks similar to C2 albeit somewhat clunkier in my opinion, and a look at Godot, which is something I keep seeing mentioned everywhere and it's kind of like the layout editor but with coding (probably not something people are interested in, but I was curious about FPS strictly, even if it meant "learn 2 code heueh")

    Just for the record - I focus on Windows EXE support the most, that's my goal and aim, and also where I've recorded these FPS scores I have below.

    Right so, some points about these statistics, please read!:

    • I record 5 random instances where the FPS seems to essentially "float around", I wouldn't record a random performance drop if it dipped to a sudden 2fps for whatever reason.
    • I don't know the NWJS version I am using, it's sorta sitting there, most likely the most recent version offered from Scirra's website.
    • GDevelop doesn't preview in "HTML5 NWJS", I had to modify the package.json of my installation of NWJS to load the weblink that GDevelop generates, and the preview loads. Therefore, the exact same NWJS installation is used for both C2 and GDevelop.
    • FPS Counters work randomly depending on the software, but FRAPS and Nvidia Shadowplay were both constantly running throughout all of this, and one software may display Nvidia's FPS counter, whilst others display FRAPS.
    • I believe I unlocked my FPS in NWJS for Construct from a forum post somewhere in "Construct 2 General", thank you to who provided that topic! Interestingly, GDevelop has the option to disable VSync directly in the projects settings, and change the maximum FPS, which is something I remember being an issue in the past with C2 changing the max framerate? I don't get it. I haven't experimented at all though.
    • I did not go through the "Export to NWJS" and record results from C2, as I'm under the impression it's exactly the same as previewing except for spritesheeting and obfuscating the code.
    • I don't have any proof of these numbers, each project was quite literally a 64x64 square that you can move left and right (Pseudo code: two events, on "A" pressed, set sprite to sprite.x-1, and one for "D" pressed.), and then viewing the FPS from an external source (Fraps, Nvidia Shadowplay). I'm sure this is easily reproducible!

    Major point to consider: I am in no way experienced with benchmarking. This could all be completely redundant information, could be unfair in some way, do not take this as accurate findings and read replies below (if any) to see potential explainations to what I've posted. I'm posting because if I worry about making mistakes, then I wouldn't post at all and may not highlight any useful information for others.

    My Specs:

    Intel i7-3770 3.40GHz (8 core)

    8GB RAM

    Geforce GTX 760

    Windows 7

    Construct 2 - r243

    GDevelop - ? (couldn't find version number in software)

    Godot - v2.1.3

    Construct 2 - Previewed in NWJS

    NVIDIA COUNTER

    1940

    1927

    1911

    1942

    1932

    GDevelop "HTML5 Project" - Preview in NWJS

    NVIDIA COUNTER

    2158

    2225

    2215

    2182

    2193

    GDevelop "Native" Project - Exported

    FRAPS COUNTER

    2735

    2716

    2690

    2706

    2754

    Godot - Preview

    I don't really know what I'm doing since I've used it for literally 3 hours but I've setup a basic project to move a sprite with a texture left and right with the keyboard, and the FPS was strange when it came to switching between notepad to write the FPS and the preview. Switching to notepad seemed to permanently lower the FPS by a thousand, hmm.

    Godot Engine Preview (seemed to drop FPS whenever I focused on notepad to write stats)

    Floats around 6940.

    Drops to around 5140 when I go to notepad and back.

    My opinion on the results:

    The results aren't shocking, I mean it's pure native scripting with Godot that gives us the 5000+ FPS which is totally expected (Included just in case people were curious about the worth of learning coding/scripting).

    As for Previewing in NWJS with C2 and GDevelop, I was... a little bit surprised, I always saw C2 as the superior software when it came to HTML5 in every aspect, but a roughly 200fps difference was unexpected. I think this is what the Construct runtime rewrite would improve on.

    The GDevelop Native EXE export was more surprising, with GDevelop having around 800fps more than C2 NWJS.

    I guess maybe it's NWJS's fault?

    Perhaps others or maybe myself in the future, could provide stats for Android exports; C2 can export to Android through it's process (that I am not familiar with as of now), GDevelop seems to have this experimental "native" android support where you pick your Android SDK folder and it generates an APK right away I think, and Godot can export native too although I haven't looked into this nearly at all.

    This calls out a point that I'd love if anyone could provide any information on, but I have but I admit I may be very factually wrong since I only know Construct 2 and Scirra well, not so much GDevelop. I ask because I adore Construct and seek maximum performance out of its exporters:

    GDevelop, made by

    (I believe)

    1 guy, has made a Native EXE exporter (And an experimental native Android one) for a very similar product to C2, as well as building the rest of the editor alongside (I read it was made opensource too, not sure if that's relevant or explains where the exporter came from) AND gaining a strong FPS boost for the EXE one. I mean...how? It sounds like it would be astronomical work and would lessen the time for development with everything else in Construct when it's brought up on the Scirra forums in the past. I guess I just don't understand, maybe GDevelop uses some sort of shortcut in making these exports. If so, can't Scirra do the same method? I legitimately wish I had more detail on this.

    Share your own stats and experiments! Would be interesting to see exports from HTML5 from Fusion, Unity, etc. Could be very insightful for us developers.

  • Um, you need a real load to mean anything.

    It's a given that a C2 game with Nwjs is going to have slower fps than a regular exe. Its an interpreted language running in a browser.

    Also you need to take into account that the C2 renderer is capped at 60fps.

    Edit:

    I will say the difference between C2 Nwjs, and Gdevelop with Nwjs is a bit odd.

    It makes me wonder if the C2 export is actually slowing things down.

  • Like newt said, without a load this measurement is pointless. You're just measuring the performance of an empty project which is pretty much meaningless. It's not taking into account how things like the scripting engine, graphics, or collision engine scale. Similar to algorithms, the performance of the engine subsystems are xn+c where n is the size of the input (how much code, collision, sprite rendering etc.), x is some factor, and c is a constant. Right now you're just looking at c.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yeah I agree that this doesn't give a good overall performance insight, as it doesn't cover everything or a few features. There'd certainly be vast optimisations in things such as object picking and as you listed with collisions and stuff, but even when having a completely minimalist project that is practically empty, there is a 200+ fps difference between two different HTML5 software runtimes (Construct's and GDevelop) when in the exact same NWJS environment & version, with the exact same two events, and exact same image.

    Thinking more about why I felt driven to post this, I guess I wonder why this is the case. Are there things under Construct's hood that are permanently switched on maybe? Could we be able to have the ability to switch these off to squeeze out an extra 100fps or so?

  • I would love to see the tests like this with Fusion 2.5 and Stencyl as well. Both have free versions.

  • Could one major factor be that framerate is capped at 60fps for html5? I don't know if native is capped but i think this is the case for most htm5 games, that's why you were getting higher numbers with native, so I don't think this test says anything really.

    Whenever I try to optimize my Construct 2 projects, i always try to reach the somewhere close to the 60fps cap, if I'm a bit lower, even on midrange phones.

    I'm pretty sure there is some performance difference, but from my own tests it's NOT rendering that is the bottleneck. I believe CPU load can benefit greatly from javascript, instead of in an event sheet. For instance loops are way faster in javascript (approx 20 times faster) than loops in the event sheet. The overhead probably kills it.

    I think webGL rendering is fast enough. The event sheet is not very fast or efficient, so using plugins/behaviours will help out a lot here, giving you more CPU resources for draw calls etc etc.

  • These test numbers probably don't mean anything. C3 ships with some carefully designed performance tests in the tech demos section. The fairest test would be to re-produce those tests with other tools, but it's surprisingly difficult to make sure it's a fair test, especially in coding tools where you can easily take shortcuts to make something visually similar but without running everything C3 is doing.

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