As for adoption trend, this might come sooner than expected : various monitors can already be compatible with just a firmware update, and new monitors are already available with this new design in mind. But I don't think it will be a "must have" until consoles and consumer TVs make it an actual standard ; which unfortunately means yet more configurations for developers to support : consumer TVs, v-sync monitors, and g-sync monitors, all of these are bound to overlap at some point.

Developing proper update rate-independent logic is the only way for developers to cope with all this in a sensible way. It's not more difficult, but it's got to be done right, and as this thread (and many others) proves, it requires to educate users to good practices.

Also, I see here and there various arguments stating things along the line of "but consoles cap their games at 30fps, why can't we make the same to make things easy and neat ?!" . First, capping at x fps doesn't ensure the game will run at a stable update rate ; many new consoles games have areas where things drop below 30 and the game still needs to work without time dilation. Second, having a main game loop with a capped frequency doesn't mean we don't need other systems running at different update rates in parallel internally (e.g. physics!). And third, on consoles we *know* the hardware in the machine, therefore it is possible to make low-level specific optimisation choices that are completely invalidated by distributing an application on mobile or PC/Mac where the hardware differs wildly from one use to the next.

Developers needs to learn and understand discrete integration, there's no easy way around it.

Aphrodite Correct ! Relying on a stable display framerate will not be possible any more. At the moment with v-sync the monitor has a fixed stable refresh rate and the gpu waits for the monitor to be in the correct state (i.e. between drawing two frames) to cycle the swap-chain and present the new pictures. With g-sync it's exactly the opposite ; a new image is still displayed between two updates to prevent tearing, but this time the monitor is the one waiting for the GPU. This is a bit simplified, but that's roughly the idea.

This means a g-sync monitor can display an animated image without tearing at any rate up to its maximum refresh rate (which is likely to remain 60 or 120). Therefore with g-sync the dt between two frames will change and is not guaranteed to be a multiple of 30/60, and applications and games will be expected to cope with update times anywhere between ~60ms and 16ms.

Just to add to the discussion regarding monitors and 60/120Hz, I am reminding people that very soon, with G-Sync monitors and similar technologies, we won't have 60/120Hz refresh rates enforced by the display hardware any more ; we'll have monitors that have refresh rates *up to* 60/120Hz, but that will wait for the GPUs to shows frames at lower rates without tearing (16ms here, 19ms there, maybe 22ms here, 17ms there, etc.)

Relying on specific magic values or capped dt is always a bad idea (just like it already was 20 years ago with PAL/NTSC/SECAM and the 50/60Hz difference), and very soon new hardware will completely invalidate these approaches. Given the adoption trend, people have a bit of time to make sure they understand all there is to understand about update frequencies, image frame rates, discrete integrations, and so on.

Also consider expanding the hitboxes of "fast" objects (relative to their size) ; you might not get accurate collisions, but you'll get collisions. It's good enough for hitchecks / damage, etc. but not necessary rebounds, localised damage (hard to detect front/back, etc.)

Hi !

Have a look at this thread, it might be of some help :

The problem you're facing is called tunneling, and it's a "non-issue" (as in, it can be a problem, but it works as designed, and it's not solved by forcing objects to update their data more often)

It's a reoccuring topic, but you might have specific questions !

I'll try that as well, in case that helps in my case too !

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.

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.