Colludium's Forum Posts

  • Thanks radbrothers!

    Update to the WIP plugin and the demo: Now added raycast. Left click/drag to draw a raycast line.

  • Box2d+

    This is an ongoing project to port the emscripten/asm.js version of Box2d v2.3.0 to Construct 2. The performance is amazing - more stable than Chipmunk and much more stable than the standard asm.js physics. Plus there are some useful game-dev friendly features. It is easy for a beginner to use but powerful enough to keep the more experienced happy. At least, that's the plan. Of note, it doesn't play nicely with the standard physics plugin and will cause your browser to vanish into a singularity if both are used in the same project (the emscripten libraries interfere at runtime).

    There main demo has 4 parts:

    1. The start screen gives you an idea of performance and demonstrates one-event conveyor belts with kinematic bodies. Collision points and polygons can be selected to be drawn and objects can be thrown around.

    2. Bitmap / scan image. This is a demo with 2 objects - one fixed and one that will be re-spawned; when running, both types can be dragged. You can use the default images or upload your own into the demo. When you press Start the engine will scan the images and assign collision polygons from the image alpha.

    3. Stress test. A comparison with Chipmunk (which, from my previous testing, is the best non-emscripten physics library in JavaScript) and the standard asm.js physics behavior. The test creates a pyramid of boxes that you can interact with or just watch collapse....

    4. Draw objects. Draw some physics shapes, convex or concave, and watch them fall down. The shape vertices are stored in a c2 array which is loaded into the Box2D+ plugin to form the collision polygon.

    Here's the demo (v1.0.1.8): link

    Summary of features:

    Plugin features already completed:

    Scan image to create polygon from its alpha (uses adjusted versions of hull.js and simplify.js)

    Circle, polygon and box shapes

    Speed clamp

    Rotational speed clamp

    Collision point

    Dynamic, Static and Kinematic bodies

    Collision filtering (category and mask bits)

    Object gravity scale

    World x and y gravity values

    Load collision hull from c2 json array

    Get collision hull as c2 json array (create polygons outside your game and upload from string)

    Raycast world queries

    Assimilate Joint - demo: link

    All joints are demo'd here: link

    AABB world queries (find objects in a defined box area)

    Gravity attractor

    Polygon editor capx (demo: link)

    Platformer behavior capx. Demo (with one-way doors/floors and wall-climb): link

    Instructions!

    More joint helper expressions added

    Obtain collision impulse and collision impulse angle*

    Obtain pre-collision and post-collision velocity (x and y values)*

    Collision Pre-Solve trigger and an action to disable the collision.*

    Features to do:

    A platform behavior helper plugin, so you won't need to mess with complicated events to control the movement and doors etc.

    The test is just about finished....!

    Ideas and suggestions are welcome.

    Not included / what's been excluded:

    Mouse joint (no need, better done using events and hidden object).

    Friction joint.

    Rope joint. The box2d rope joint stretches and breaks far too easily to be useful. Work-around: use revolute joints.

    *latest changes

  • I am making a behavior plugin. All works well when the export is un-minified. If I minify the export then I receive the following error:

    TypeError: q is not a constructor[/code:37gsw7j8]
    
    The "q" corresponds to "behavior_ctor" in the c2runtime.js when un-minified:
    
    [code:37gsw7j8]Line 4420ish
    if (!behavior_plugin)
    				{ 
    					behavior_plugin = new behavior_ctor(this);
    					behavior_plugin.my_types = [];						// types using this behavior
    					behavior_plugin.my_instances = new cr.ObjectSet(); 	// instances of this behavior
    					if (behavior_plugin.onCreate)
    						behavior_plugin.onCreate();
    etc[/code:37gsw7j8]
    
    I hope that this is enough info.  If anyone has any idea where I should focus my efforts then that would be very much appreciated.  I imagine that I am missing something obvious here...  I am about to embark on a long process of rebuilding my plugin from scratch to see what causes the export to break.  But I need to sleep!   
    
    Edit:
    
    Solved.  Apparently you cannot preserve the name of your plugin like this: ["myplugin"].
  • C3 is reliant on Chrome, isn't it? Chromium is open source, but Chrome is not - just ask Mr Google. C3 is reliant on the product of another business, so the precedent has already been set by design...

  • Ashley

    I haven't set up performance benchmarks before. If you could link me to a good benchmark capx, I'd be happy to try and recreate those conditions in GMS to see how they compare.

    I think these were the performance tests discussed in this thread. I remember that Godot was roughly equivalent to slightly worse than the c2 exports and that Unity was a clear performance winner in every respect.

    I would be very interested if you could put together a GMS/C2 bunnymark comparison!

  • Shameless *bump* for great justice.

    Any more news on the latest status?

    ~Sol

    This is one thing that's keeping me tinkering with c2. The Kestrel Moon dev has updated the plugin, see here, and it looks to include all of the features you'd hope it would (animation blending, skin swapping....). I gotta say thanks to R0J0hound for his work on the first plugin that made this possible.

  • Nope. I've spent the last 5 months learning to code in Godot Engine and then in Unity. It was challenging at first, but now I've seen the flexibility in the alternatives I'm unlikely to return...

    For me, the simplicity and appeal of not having to code in c2/c3 is offset by their lack of an animation editor (one that's like having Spine built in) -and- not ever being able to use prefabs. Those are powerful tools that c2/3 architecture won't ever support (at least in the next couple of years). Then there's lighting effects and export options that don't jank with just 5 sprites on screen. I almost forgot the forthcoming runtime rewrite...

    If you've ever considered making a plugin then I suggest you could do the same work in c# and you'll never look back.

  • and this:

    http://www.goodboydigital.com/pixijs/bunnymark/

    gives me 60fps up to 20,000. I guess js isn't actually that slow?

    Amazing! I get 40000 bunnies before a slowdown in Chrome...!!

  • Jayjay - awesome results! Fascinating that your Godot tests ran better than NWjs - the opposite of mine - were you using the latest version of NWjs v22? I found that v20/21 performed far worse on my lowly machine.

    My Unity WebGL results:

    render: 3500

    no render: 9500

    PS - how did you render html5 using dropbox?

  • , TheRealDannyyy, happy to help. I did have the old apks on my phone (all but Godot's).

    30fps no render

    Godot: 1200

    C2: 1800

    Unity: 5500

    30fps with render:

    C2: 1600

    Unity: 2000

    The Unity version was smoothest because of the framerate lock.

  • Sure TheRealDannyyy - I'll take a look at Unity webgl as well. It'll be some time in the next couple of days, though. Work is hectic... I also wondered about why Chrome beat NWjs - I put it down to the NWjs engine dev being in lag behind Chrome.

    I think 30 fps stress testing won't give any good info - most players will have gone home by then, and it might just test aspects of the engines that are irrelevant for normal gaming.

  • Ashley - Godot compiles c++ from the user's GDscript (python) at export. It is run in a wrapper that's the same .exe as the editor runs from in windows (not sure about android export). It does show html5 can perform ok, but I think Unity is the only native engine in this group - which is why it's so much faster.

    Havok - Unity's graceful degradation from 60 to 30 fps was a clincher. No jank....

  • tunepunk, no, I didn't do an in-depth investigation. However, if pure draw calls were the limiting factor then each engine should have max'd out at the same value when rendering bunnies. Therefore, I think that there's an overhead that each engine carries when ascribing draw calls to the GPU, such that the final yes-render figure is a mix of a GPU and a CPU limitation. The test also didn't measure jank (because I couldn't be bothered to create an fps-waterfall graph for each one) - that would also be of value because it would represent a measure of the quality of the player's experience.

  • OK. This is not to become a c2 bashing thread (mods please lock it if it does).

    Yesterday I posted some performance stats in another thread, but they were misleading because I had used an inefficient sequence of events in the c2 part of the test (the test was a version of bunnymark). I felt that my results were unfair to c2 because of this misuse of events. Additionally, the test did not focus on the GPU or CPU, which meant that you didn't know which one was limiting and causing a drop in fps (CPU number crunching or GPU fillrate). The other thread was locked so I'm posting my results here instead.

    Results:

    Tested on laptop (i5, 16Gb, SSD, intel HD4000) and phone (nexus 5x: built using phonegap build webview for c2). c2 laptop export was tested on NWjs (v22) and Chrome (v58). I tested each with and without sprite rendering enabled - the no-render results are probably a good indication of the relative amount of data that each engine can compute, given the limited test parameters, and the yes-render results probably indicate where my GPU became stressed. As I said - these are just a taste of performance and not an absolute benchmark. Edit: I took 55 fps as the cut-off for the tests.

    Engine..............Render Images?..................No of bunnies

    .................................................................Computer.............mobile

    C2 NWjs.....................Y...........................6000

    ...................................N...........................9000

    C2 Chrome................Y...........................7500

    ...................................N...........................8500

    C2 phonegap............Y..........................................................1300

    ...................................N.........................................................1550

    Godot Engine...........Y............................3000........................800

    ..................................N............................5500......................1400

    Unity.........................Y.............................9300......................2500, 4700, 5200 **

    ..................................N..........................30000......................9300

    Cocos Creator.........Y............................13000**$$.................3000

    ** Gracefully degrades the fps from 60 to 30 to 20 (no jank)

    $$ Exported to .exe and also html5 in Google Chrome...

    All of the above tests are available here; you'll have to enable/disable drawing to make your GPU/CPU comparisons.

    What stood out for me? Well, c2 did very well but Cocos Creator won by far. Looks like JavaScript is the language to go for...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Ads and IAPs are beyond me for c2 (and Godot...!). I only learned how to program (I am still an amateur!) by making plugins for c2 - all of the concepts are translatable to other engines, and I only chose Godot over Unity because it's way easier to learn because the interface is simpler.

    I can only recommend you do a forum search for cocoon.io advice - it's almost the same as phonegap (zip up your export and import it into cocoon) but it's been a good while since I experimented there. If your games don't require moving action scenes then phonegap will suffice for mobile for sure.

    A cross platform alternative for NWjs can only be Electron (which I have never used and it looks complicated for a non-coder) - so you might be better off waiting for a stable NWjs branch (or use different versions for different platforms?).