Shadownox's Forum Posts

  • 9 posts

  • For a slightly more efficient approach, you can at least start by checking the easiest blocks, that fit into the other shapes: for example, if the small 2-block line does not fit, everything else definitely will not fit either.

  • As a 2D-Engine everything related to 3D should mostly be about small effects or visual fidelity, not about 3D-logic. Physics in 3D go in line with different types of collision bodies, raycasting, 3D shadows, lighting, etc. These are things that belong to a 3D-engine, which Construct 3 is not. Although it is a great engine, most developers would not develop a 2D game in the Unreal-engine. It is obviously possible, but it is clearly not made for that purpose, so a lot of things feel hacky and overcomplicated. Also, it is lacking a lot of pure 2D functionality, because - obviously - it is not the focus there. Similarily for Construct 3, if a game needs more advanced 3D logic, there comes a point where switching to a native 3D engine is just a better way to go. There are enough things that can be improved for 2D games, where the ressources are better spent, instead of extending a set of features for something that is not the main focus anyways.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I would actually really look forward to an additional mode besides fixed and framerate independent, which is similar to fixed updates in Unity. There, the physics update does not have to be executed each frame (or even multiple times). The latter might be a problem for weaker devices, but I think a hybrid that behaves like fixed below 60fps (or another fixed step size), but does not necessarily update every step (so it accumulates the dt until the fixed timestep is reached) would be nice. Similar to the LiquidFun physics, a trigger "before physics update" could provide the control to apply forces synchronized with the physics. It could look janky when combined with objects that are not controlled via physics, but as it would only affect refresh rates > 60, it would probably be not too bad. Theoretically, this could even be worked around by having visual interpolation (either built-in or done with dummy objects).

    I think sacrificing a bit of smoothness for consistency would be a good option to have. A lot of physics games need a almost deterministic behavior design-wise, as they rely on more complicated contraptions. It is possible to work around this by adding tons of fallbacks and fail-save mechanics, but then you might as well just create your own physics. The biggest problem is the increased level of testing necessary (as well as having the respective displays).

  • For me it is also the physics. While it is mostly fine, in more complicated scenarios (multiple joints, constant forces like wind) it is hard to ensure that everything works (especially if the contraptions are more complicated). Often, it can be ensured that the target devices are able to do 60fps, but fixed mode is still not an option, because 90hz/120hz devices exist. In these cases it would be awesome to ensure that the maximum is 60fps.

  • I hope you can figure it out, the fixed step rate is awesome, as it saves a lot of time when dealing with 120-240hz which made physics a pain. Sadly, r237 is quite a while back, but I think I will have to use the older version for now.

  • I also encountered the bug. I think it has something to do with destroying objects.

    Steps to reproduce:

    1. Use assimilate joint to bind some objects together

    2. Destroy the objects, restart the layout

    This results in the following errors:

    TypeError: Cannot read property 'DestroyFixture' of null

    or

    TypeError: Cannot read property 'GetFamilies' of null"

    Interestingly, when I remove the joints first and then restart, it sometimes works (but after some time/collisions?) it will also crash.

    I also built a minimal example here:

    dropbox.com/s/6yxc80kgjd0nm00/LFJS_bug.c3p

  • In version v1.0.0.20 the Joints does not work for me (all examples are stuck on loading with error "TypeError: Utils.b2JointType is undefined"). When debugging I saw that it is there, but prototype seems to be missing. When defining it myself everything seems to work, so it is probably not a big problem.

    Another small thing that is not really a big problem, but was confusing: When setting the X-velocity, it is written as "LFJS Set Velocity Y:".

    Otherwise it is great, thanks again for the great addon!

  • The moment I realized the difference was when working on a new monitor with 144hz. When connecting object with joints (e.g., building chains with revolute joint), they behave like smooth strings/chains and are completely stable. The same project 60hz behaves similar for low forces, but can easily break at obstacles (get disjoint for a short time) when applying higher forces. This is definitely fixable by preventing these forces and write additional code around it, but this in turn changes the behavior on the faster refresh rates to feel a little bit 'overtuned'.

    Increasing the iterations helps to reduce the differences, but the lower latency still had a superior result. Also, the higher accuracy affects the performance on devices with higher refresh rates, even if they would not need it. The problem is that devices with fast refresh rates are not neccessarily better - they just have a faster display. This means that the best solution would probably be to adapt the accuracy according to the framerate, to find a tradeoff between CPU usage and 'reliable physics'.

    Some devices (like some laptops) start getting ridiculously high refresh rates like 360hz, where these smaller differences in physics behavior might build up. This unfortunately means that one has not only to consider the weaker devices, but also the more powerful ones. For these it would propbably be the best to just cap the updates to a level that is considered 'save'.

    However, I can definitely see the problem with independent clocks, especially if the system can't keep up with the updates. That said, I realized that often devices are powerful enough to manage the higher update rate - they just wont do it because of their display (especially when targetting stronger/newer devices). Especially when targetting PC and laptops, the refresh rate is probably not really tied to the specs of the CPU. This leads to the undesirable situation that weaker devices might ask for high framerates, while much stronger devices are held back by their display.

    I agree that the update rate should never be set anywhere near the limit, but I would think that the cap introduced by the refresh rate is not the best option for all cases anymore.

  • As devices with higher refresh rates (120hz, 144hz, etc) are quite common, it is neccessary to use framerate independent physics most of the time.

    The problem here is (obviously) that the physics are not deterministic anymore. While you can design around this problem, it gets increasingly bad with different refresh rates. While some occasional jittering due to changing dt is something that can be worked around, it is much harder if the average dt is much lower or higher than intended.

    The differences between the physics behavior can be quite big in some instances, with (unsurprisingly) a better and smoother experience on 120hz (compared to 60hz).

    However, the interesting thing is that most of the time the display is the bottleneck - the devices would easily be able to update with 120 ticks per second and have the advantages of lower latency and smoother physics.

    As we can already test the games with unlimited ticks (while still rendering at vsync speed), is it be possible to set the update indepently from the renderer to a fixed rate (e.g., 120 ticks per second)?

  • 9 posts