simstratic's Forum Posts

  • Why not include C3 test project at least? I think bunnymark test usually does not use wrap, they jump up and fall down.

    SnipG yes the traditional bunnymark bounced off the screen edges instead of wrapping. The reason why I used wrapping is because Construct and GameMaker both have an inbuilt wrap function/behaviour, so I wanted to test the performance of the inbuilt functions (engine) vs manually coded wrapping (scripting).

    I cleaned up the C3 project and uploaded, there is a separate layout for each approach, so preview the appropriate layout (not the whole project). Link:

    drive.google.com/file/d/1TpfYWE-WsrfsGgfDEVDzQUWep7X216fB/view

    Credit - The sprite wabbit_alpha.png is taken from the Raylib repository:

    github.com/raysan5/raylib/tree/master/examples/textures/resources

  • This Twitter thread from the developer of Celeste shows some of the things they implemented to help the player/make the controls feel better:

    twitter.com/MaddyThorson/status/1238338574220546049

    A talk on difficulty balancing from a developer of The Witcher:

    gdcvault.com/play/1020846/Fun-or-Frustration-Game-Balance

  • I thought the else condition operates the same way, but with the downside of still having event block overhead unlike the conditional expression. This is interesting, thanks again for these experiments.

    I could be wrong, somebody correct me if I am, but I think the ELSE condition still checks every instance (not only those that failed the prior condition).

    To give credit, it was eleanorjmorel who showed me how much faster conditional expressions can be.

  • The only problem I see is that the browser just doesn't offer a viable monetization method. At least not in any way that would rely on being performant.

    Windows Wrapper would most likely return equal results since it was done using Edge, but the wrapper is not a great option... yet.

    Yes, I am more interested in desktop publishing, not browser or mobile, so the new Windows wrapper definitely perked my interest, but for me it needs some Steam integration first (at least achievements) to be a viable option.

  • 1) I think part of it is because the GML scripting language is not typed, so even when it's compiled to C++ code, it probably has to do a lot of inefficient type checking/casting. And if I remember correctly, certain types of variable lookup can also be slow, which is why GameMaker people will often copy them into a local variable first. So it's not as fast as a C++ engine could be without a scripting language.

    2)

    a) Behaviours was simply assigning the Bullet and Wrap behaviours to the object. Wrap was set to wrap to viewport. In the create object event, the Bullet actions were used to set a random direction and velocity to the Bullet behaviour for that instance.

    b) For the events, I deleted the behaviours from the object and I added two instance variables - sx and sy (speed x and speed y). Then in the event sheet - on create object I set sx and sy to random values. Each step I use actions to apply movement - i.e. set sprite x = x + sx*dt, set sprite y = y + sy*dt. Then there's a series of IF events to handle the wrapping:

    if sprite x < 0 set sprite x to 800 (800 being viewport width)

    if sprite x > 800 set sprite x to 0

    if sprite y < 0 set sprite y to 450 (450 being viewport width)

    if sprite y > 450 set sprite y to 0

    c) Avoids all the if statements by putting it into a single conditional expression when applying movement to the object, i.e. each step:

    action - set sprite x = x < 0 ? 800 : x > 800 ? 0 : x + sx*dt

    action - set sprite y = y < 0 ? 450 : y > 450 ? 0 : y + sy*dt

    These expressions allow you to 'short circuit' the evaluation, i.e. if the first part (x<0) is true then the rest of the checks will be skipped. This is what I wished the ELSE event would do...

    Hope that makes sense...

  • Hi all,

    I ran a benchmark across various 2D engines to check rendering/processing performance - no Unity or Unreal sorry. If you're familiar with the bunnymark benchmark, it's similar - spawn a lot of instances, give them each a random direction/velocity, and wrap their positions to the screen. The result shown is the number of instances the engines could handle before FPS dropped below 30FPS. Tested on Windows 10 PC with Ryzen 3600, 16GM RAM, Radeon RX 570. Construct 3 was tested with Edge (Chromium) but the other engines were all exported to native applications.

    Gamemaker Studio 2

    Gamemaker has several export options - VM (C++ engine but running interpreted GML code) and YYC (everything is compiled into c++) - and for both of these there's a 32-bit option and a new 64-bit option. Results:

    VM 32-bit: 37,000

    YYC 32-bit: 39,00

    VM 64-bit: 48,000

    YYC 64-bit: 67,000

    YYC 64-bit Delta Time*: 55,000

    *Note that by default GameMaker used fixed step timing (no delta time), so to make a fairer comparison I ran another test incorporating delta time.

    AppGameKit Studio

    AppGameKit Tier 1 uses a C++ engine to interpret AGK script - this seems to be the option used by most developers. There is AppGameKit Tier 2 which is basically using their API to help write the game in C++ but I didn't test this. Results:

    AGK Tier 1*: 21,000 - 36,000

    *Note the range of values - it dropped to 30FPS at 21,000 but was able to hold 30FPS up to 36,000 - I suspect this is related to how they handle frame timing or report FPS.

    GDevelop

    The only other JavaScript based engine on the list. Was curious given it's 'similarity' to Construct. Results:

    G-Develop: 15,000

    Godot

    Godot uses a C++ engine to interpret GDScript - again this seems to be the option used by most developers. There is the option to write in C# or C++ (with a lower level API) but I didn't test this.

    Godot GDScript* - 21,000

    *Note that this was a debug build because I had issues trying to compile a release build, so performance is lower than it should be, but based on past experience it is slower than GameMaker VM, so my guess would be 25-35,000 in a release build.

    Defold

    Defold uses a C++ engine with LuaJIT scripting (generally considered the fastest interpreted language). Results:

    Defold*: 16,000-25,000

    *Note this another case where the engine drops to but then holds to 30FPS.

    Raylib

    Raylib is a pure C engine, very light weight and very low level, more framework than engine, similar to SDL, SFML etc. Also worth noting that this benchmark was programmed somewhat differently, it doesn't use instances, but a large array of positions, velocities etc., and then uses those array values to draw the texture - it is very performant in terms of memory access/CPU caching etc. - it would be more similar to how Construct 3 handles particles VS sprites.

    Results:

    Raylib: 230,000

    Raylib with rotation*: 150,000

    *Note that there are different rendering commands depending if the sprite is rotated. As you can see having to apply a rotation transform has a significant performance impact.

    NOW WHAT YOU HAVE BEEN WAITING FOR!

    Construct 3

    The Construct 3 benchmark was programmed in multiples ways; (a) using the inbuilt bullet and wrap behaviours (b) using events instead of behaviours (c) using a conditional expression instead of multiple IF events. Results:

    C3 behaviours: 72,000

    C3 events: 60,000

    C3 conditional expression*: 85,000

    C3 conditional expression with rotation*: 58,000

    *Construct 3 seems to have an optimization which allows it to render non-rotated sprites more efficiently.

    Final Thoughts

    Hats off to the Construct team. These results had me triple checking my Construct code to make sure I wasn't cheating.

    Apart from Raylib, which was expected to easily win and isn't really a fair comparison, Construct 3 shows better performance than the other engines. Construct even manages to beat the fully compiled C++ native export of GameMaker, which was really surprising actually.

    There is some overhead to events (about 20% in this case), however I feel like I could have optimized the events version a lot more if ELSE conditions in Construct worked like in other languages, i.e. filter a smaller and smaller subset of instances to subsequent conditions.

    The fact there seem to be inbuilt optimizations for rendering non-rotated sprites etc. is nice. And the boon is that Construct performance was better while at the same time offering more inbuilt functionality than most of these engines.

    Not to end on a downer, but keep in mind benchmarks are benchmarks, and don't reflect a whole game. I know there are certain things like tilemaps and collisions which are faster in other engines. But on the whole, a very impressive showing by Construct.

  • I don't know about web audio to answer that sorry. Maybe if it can't process the HRTF fast enough it has a backlog of audio commands that it's still trying to process? But that's a completely wild guess...

  • Were you using the HRTF option? If so I wouldn't call this a bug per say...

    HRTF is a very very computationally expensive method. Back in the day PCs required specialist hardware on separate audio cards to handle it. Some modern devices like the Microsoft Hololens still have dedicated hardware for it. Sadly great positional audio somewhat died out with dedicated audio hardware, if you ever played something like Thief 2 with the hardware support, it was amazing.

    True HRTF is still relatively rare even in modern AAA games on PC/console, and often they'll only implement it for selected sounds, i.e. short sounds that are important for positional awareness, like foot steps, gun shots etc. I wouldn't think of using it on mobile. My guess is the crackling/popping is because the CPU cannot process the HRTF audio fast enough to fill the audio buffer - and this is why it's more noticeable on mobile than PC.

    If you still want to use positional audio, the equal power option should be much cheaper to process. I believe there is an even more lightweight stereo panner node in web audio but not in Construct 3, that is something I would really like to see implemented to help mobile performance.

    As to why the old iOS versions didn't display this issue, my guess is they only had limited web audio support, so maybe positional audio support was only recently added, i.e. on older iOS it probably detected it wasn't supported so reverted to normal audio.

  • Another question about inner workings of the engine. The only information I could find on this seems to imply that SVG will initially be rasterized to largest size needed in the layout, but they can be re-rasterized automatically by the engine as needed. So my questions are:

    - Are SVG objects re-rasterized only when the size of the object is increased?

    - Are SVG objects re-rasterized with small changes in size? Or only when it hits some threshold like 50% or 200%?

    - Do layer zooms, Z-elevation or resolution changes also trigger re-rasterization?

    Basically I'm trying to avoid constant re-rasterization, if for example I'm tweening slightly the size of SVG objects for 'juice'.

  • I found plenty of information on upscaling, but not so much with downscaling. If I'm using a 4K viewport (3840 x 2160) and displaying fullscreen on 1080 monitor, how is the downscaling handled?

    a) Is everything rendered at 100% to a 4K canvas and then downscaled together 50% to 1080?

    b) Or are the objects individually downscaled to 50% and then rendered to a 1080 canvas?

    Or some other way...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi all,

    Mostly for a bit of fun, I have a few questions to ask you, my answers are included below and I would like to hear yours.

    1) What's a small thing you appreciate about Construct 3?

    You can download the manual as a PDF and easily print it. It's crazy to me how rare this is for game engines. Maybe I'm getting old, but I like to work with a paper reference in front of me, especially because I'm working on a single monitor.

    2) What's a good thing in Construct 3 (or handy tip) that people might not know?

    I just discovered this today - the 'Recreate initial objects' action. When I saw the name I thought ok I guess it could be useful. Today I realized it can load objects from different layouts with region and offset. That's huge... that's Spelunky type procedural level generation made simple.

    3) If you could choose one thing from the Construct 3 suggestions list to have next - what would it be?

    This was a really tough choice but I chose: construct3.ideas.aha.io/ideas/C3-I-1409

    The ability to rotate timelines (I would also add scale timelines) - I feel the current implementation is good for platformers, SHMUPs etc. - but not as useful in games the involve rotated movement like a top down shooter.

  • Just to offer some thoughts, I would prefer save/load/delete scene graph actions, instead of a 'clone' action. To further elaborate, the downsides I see to a clone action are:

    - The scene graph would have to exist in the layout at the time it is cloned.

    - There would be no simple way to share the scene graph across layouts.

    - The scene graph would be cloned with non-inherited transformations that have been applied to children after the scene graph was created, i.e. it would difficult if you wanted to re-create the scene graph in it's original state when it was first created.

    I would like it if we could 'save' the scene graph data to JSON or memory in it's current state using a string based 'tag'. The scene graph data would be saved at the global level so it could still be accessed when switching layouts. In the editor we could also store this 'tag'. The 'load' action would take the 'tag' as an input to create a new copy from the scene graph data. Finally, for memory management, a 'delete' action to remove the scene graph data corresponding to the input 'tag' (not ones created in the editor).

  • You do not have permission to view this post

  • To contribute my own experience so far...

    I think subscription is pretty much the norm now, the few commercial engines that still charge a one time premium, still require you to pay for major upgrades every few years, so to get the latest features/bug fixes, it is effectively a subscription, just one you pay more sporadically. I suspect these engines will move to a subscription basis in the near future anyway... I'm from SEA too, and money is tight, not sure in Vietnam, but here I can subscribe for a month when I can afford to, sometimes I can't so I focus on the art etc. for a while, until I can afford to buy another months subscription.

    Every engine has some reliance on third parties, at the very minimum the operating system and hardware drivers. At the lowest end, would be low level frameworks like SDL, SFML, Allegro and raylib, in the middle engines like Unity, GameMaker, Heaps and Defold, and then engines with a greater dependence on third parties, like Construct, Cocos and RPG Maker. The extra third party dependencies are Chromium, which I really don't see as an issue with companies like Google and now Microsoft invested in it, Cordova for mobile and nw.js for desktop which are potentially a greater concern to me, but for now, they are still actively developed and I don't see them as an issue for a game currently in development.

    As Ashley mentioned, every engine will encounter bugs or issues, but I will say that in my experience the Construct team has been very, very responsive to issues they are able to fix. I think in my short time here I have submitted 4-5 issues and they were all fixed within 48 hours. This is invaluable in my opinion and was a major reason why I decided to switch to Construct. I still have a 'blocking' or 'business critical' issue in another paid engine that was submitted 2 years ago and still hasn't been fixed.

    As for native vs web/hybrid app, it's going to come down to the individual game, in my case performance is good enough for the games I'm making, not light casual games, but not ultra-heavy simulations like Factorio, more on the level of Heroes of Might and Magic or Panzer General. A deciding factor for me, along with the responsive bug fixes, is the sheer speed that the Construct team has been adding new, thoughtfully implemented and useful features to the engine. For a relatively small team I think they are leading the pack, and I believe a large part of that is thanks to the web based engine. Some other engines I have used and paid for, have fallen into stagnation, but now I feel excited because every week or so there is a beta release of Construct with something I actually want to use in my games.

  • You do not have permission to view this post