Refeuh's Forum Posts

  • While exposing more of the internal update mechanisms can sometimes be useful, I would argue that all the physics-related issues should be considered a separate problem.

    The tunnelling effect people encounter when using physics behaviours and collisions is a well-known problem, and fiddling with timesteps is not the best solution to it. It might help in certain situations, but it's not a robust approach. The "proper" way to deal with this is to have continuous collision detection, with swept surfaces (point > raycheck, sphere > capsule check, box > swept box, etc.), and broad/narrow phases.

    I haven't used the physics in C2 yet, but if the built-in functionalities are not satisfactory, that's what we should be asking for. Which doesn't conflict with the idea of having more control over the game timesteps.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Not really a C2-specific question ; there are some tools that let you convert Kinect "moves" to actions to emulate user interactions, but I am not aware of any plugin that let you use Kinect features directly without interfacing with the MS SDK. It's quite low-level, what you get is access to some image buffers, depth buffers, some skeleton-related info, etc. So it really depends what you mean by "play" games with Kinect. If you're wondering if there's a built-in simple input controller like gamepad or mouse, but for Kinect, the answer is no.

  • Hi all !

    I've been here for a bit but never took the time to introduce myself. I've been working in the game industry for a while, and I use tools like C2 in my spare time to work on some personal ideas and projects.

    Have fun

  • Have a look at these 2 threads, they might answer some questions :

  • There are lots of simple physics-related simulations that are unstable at low- or variable-frequency (spring compression, rotational fields with correcting factors to compensate for discrete integrations, etc.). Using the semi-fixed time-step also helps with the underlying implementation, as we know the simulation will not need to try to cope with certain degenerate cases, which helps with collision detections, computing swept surfaces and volumes, etc.

    That might have little impact on small games that don't actually need any of these features, but it's usually good practice to prioritise stability of the simulation under reasonable assumptions when implementing a physics engine. Therefore there's no real reason not to do it, even if you don't need it. It might feel a bit over-cautious, but it ensures some form of consistency.

    Also, it is NOT realistic to expect a physics simulation (or any mathematical computation, for that matter) to be deterministic across multiple platforms. While a physics simulation can be made deterministic on a given platform, it relies on the low-level math hardware for that platform. While a recent desktop CPU will provide fast vectorised maths with high precision, a mobile chip will certainly offer much less precision. This difference will cause inconsistencies. When using native code, even a compiler switch (fast math, etc.) can modify the behaviour of math/physics computations.

    When it comes to math/physics and computers, determinism is a very tricky requirement and should be considered a major technical risk for any application. If a game relies on deterministic physics, you're likely to need specific libraries for every category of platform, as a recent i7 and an old iPad2 have little in common in terms of electronics. Obviously, this gets easier if you target a limited set of platforms only ; which is quite hard to do if you have "mobiles" in mind.

  • Yep, much better !

    Though you might want to change the "set timer to 0.2" to "add 0.2 to timer" ; otherwise you might be accumulating a small error every time it is time for fire a bullet, meaning the overall shooting rate will differ slightly depending on device performance.

  • Hi !

    Don't use a "every x seconds" trigger condition for this ; if the actual framerate is slower, or not a multiple, of your time, it's not guaranteed to run at regular intervals. It's not a flaw in the "every x seconds" block, it's just bad logic.

    Use a timer you update every frame with dt to make sure events like that happen at a fixed frequency.

    E.g in pseudo logic :

    every tick >

    timer -= dt

    while (timer <= 0.0)

    {

    dostuff();

    timer += interval

    }

    (this version ensures that if the frequency of the event is much higher than the actual framerate, the logic can run multiple times every frame ; this may or may not be desirable depending on the case ; change the "while" to an "if" depending on the requirement)

  • [quote:3u2ngezv]"I wasn't aware that the tint effect would impact performance"

    Anything can affect performance ; whilst tools like C2 are quite high-level, in terms of abstraction, understanding how it works internally can be useful to explain why things are the way they are.

    Basically, by having unique sets of shader attributes per instance, you prevent the system from batching similar objects. The hardware is very efficient at processing large amount of identical data ; the more you make the data unique, the more the objects have to be broken down into smaller groups, each generating drawcalls with specific render settings and shader parameters.

    It's much faster to render 10.000 triangles with the same attributes than 1000 triangles with unique attributes ; in the second case, you spend most of your CPU/GPU time in the pre-render stages and the driver overhead.

    There's always a trade-off between CPU/GPU time and memory/video memory, and a balance to find between these. If you don't need to dynamically colour sprites, just bake predefined colours into texture atlases ; you'll burn a bit of memory, but the geometry will be quick to process.

    There isn't a universally "better" way of doing this, it all depends on the application and the external requirements.

  • I guess the context is that it's being used in front-end logic ; if that's the case, 'just use the UIDs to know which element (button, sprite, etc.) is being pressed.

  • No need. [...] Far more versatile this way.

    This.

    Personally I'm all in favor of less built-in behaviours, and keep/request only what is really saving time. The more generic, the more constrained ; and the more automated, the more limited. Therefore if people rely too much on default behaviours, they ask for new features as things never exactly fit their needs, to a point where the behaviour becomes too complicated and counter-productive to use.

    Continuing with the example of the directional movement, some people might want crouching, some might want dashing, some might want double-jump, some might want animations for jumping at specific angles, etc. Or any combination of the above, e.g. dashing while jumping at specific angles. Should all these become attributes of a default behaviour ? I don't think so, as some of the requirements are likely to be conflicting.

    It's much easier to use the building blocks and create the logic required for each game specifically. It's much more flexible, and reusable.

  • Also, if a similar structure is used anywhere else ("every x seconds..." with very short time steps), they should be converted to dt logic as well, otherwise the game is likely to have some imbalanced elements depending on platform performance (shooting faster/slower, moving faster/slower, etc.)

    Few things should run at fixed timesteps, if any, and these should always be at a lower frequency than the minimum game framerate to guarantee you don't accumulate delays and errors.

  • Maybe... if you have animations for moves like dashing, falling, etc. use larger hitboxes specifically on these to counterbalance the movement speed. Assume a minimum framerate of 15fps, and given the size and speed of your object, and the size of other entities, you should know the size of a hitbox that can never tunnel through enemies or environment bits.

  • [quote:3k8y5269]it only happens on my iphone. On my desktop, it didn't happen a single time and i checked that a lot of times

    There is a correlation between framerate, object size and object speed that explains when tunneling can or cannot happen. What I meant when I said the framerate was "irrelevant" is that 30 or 60fps, or even 120fps, doesn't guarantee consistent collision detection ; if you had smaller or faster moving objects at 60fps, you could see the same issue.

    Commercial games use solutions that work decently in all situations ; for example a bullet in a first person shooter, a small and fast moving object, is never actually a bullet from a physics representation point of view, it's a line, and physics raychecks are used to compute collisions so that bullets don't through thin walls.

    As for doing this with C2... No idea, honestly. But the problem is well-known.

    'Hope that helps a bit !

  • Tunneling is an inherent problem of collision detection using discrete timesteps ; the framerate is actually irrelevant, as this can always happen as long as an object is moving "fast enough" (compared to its size).

    I haven't used the physics module of C2 yet, so I don't know any good solution from top of my head, but see if you find anything that relates to continuous collision detection (CCD, raychecks, extrusion, etc.) ; otherwise you might have to do some linecheck or swept surfaces manually.

    Alternatively, maybe use an additional bigger hitbox that's big enough given your level design to prevent tunneling ; knowing that when your larger box detects a collision but your smaller one doesn't, a collision *might* have happened, and you'll need more computations to know what actually happened

  • 'Just to add to the WiiU performance discussion -

    WebGL is a JavaScript API ; while some consoles have built-in support for WebGL, no console is expected to run games in a web browser. All modern devices have support for either DirectX9/11/12 (PC, XBO, etc.), OpenGL (Mac, Linux, etc.), OpenGL ES (mobiles, FireTV, etc.) or OpenGL variants.

    Usually consoles are powerful enough so that exporting a non-native simple game and using a wrapper to map compatible layers of abstraction is a viable option as the performance overhead is negligible for small applications.

    WiiU supports OpenGL ; but the GPU is based on an old-ish R700 (custom AMD, HD4xxx, very close to a HD4770) and the architecture is a bit exotic (little video memory, shared pool, etc.) meaning it's imperative to have low-level programmers optimising for eSRAM use to get anywhere with performance. Also, publishing on WiiU has some unique certification constrains (using the gamepad display, etc.)

    As a result, all of these together mean that porting to WiiU is usually a non-trivial task, the console requires lots of specific work and optimisations ; which also explains why it's usually left out when games are published on PC/Xbox/Mac/PS or mobile platforms iOS/Android.