C2 games and 120hz monitors (*dt problem?)

I wonder if perhaps a new expression for speed would be a good idea.

Something that would have dt applied, but be simplified to pixels per second, like say speed().

you mean like

a=speed(a, b, speedvalue)?

you should be able to do it with two min or max functions depending on where a is compared to b.

in a every tick logic:

a is inferior to b : set a to min(a+speedvalue*dt, b)

a is superior to b: set a to max(a-speedvalue*dt, b)

speed value being in value per seconds

I wonder if perhaps a new expression for speed would be a good idea.

Something that would have dt applied, but be simplified to pixels per second, like say speed().

I think that would definitely just complicate things. The current method of using dt appropriately is perfectly fine, so long as the programmer knows how to use it properly. For someone without a math/programming background it can be a hard concept to wrap your head around though, so more education would always be nice. Perhaps even include a section about dt in the Beginner's Tutorial?

Candid question.

Let's say 90% of the C2 users love C2 because it's simple, fast, and allow to focus on your game production while a brilliant mind/puppetmaster hides behind the scene. Couldn't something like this make sense to avoid beginner's mistakes with *dt and lerp?

Most of the users could use these presets, and if in need of more control, switch to the lerp expression.

When I see how crazy simple some C2 operations can be (the incredible save system, the shaders, the behaviors presets...), I really think it would completely fit with the core C2 audience. Without taking anything from the pros.

Stupid idea?

Aurel define smooth, slow and fast, and I would say it may be something to potentially consider (even though I see more this as an expression meant for that, rather than misusing lerp)

also the beginner error with lerp comes only from one thing: someone used lerp that way, he liked it, and so everyone did use it, whereas it just does not make any sense, and then they assumed adding dt to the detourned formula would work (spoiler: it does not really).which is why even the potentially correct ashley version I would be agaisnt as, it is not a linear interpolation between a and b that is done, it is another calcul that just is similar math wise. Lerping does not mean, and will never mean, going smoothly from a to b, it just does not.

just understand what something does before using it, it is as easy as that.

you want to do a transition? then just do it, make the value increase more or less with time depending on what you want, we can help find which expression is the best for that if you need, you want a linear transition? then a good use of lerp willdo it, something slower first then quicker then slower again? cosp can do that, something fast first then slower that never reach the goal but divide the distance each second by the same number? the bad lerp does that, but an exponential formula will do the job in a way you can control fully and that will work even if dt changes.

EDIT: oh new page. We were talking about this:

Aphrodite I fully understand what you mean, and I don't want to say you're wrong in any way. My brain even think you're very very right.

But I feel exactly like when I was on the GameMaker studio forums, learning how to script the surface system only to display a very simple shader.

I can learn that, I learned the surfaces. It's even very interesting and I'm glad I did.

And I'm sure I'll be interested in learning the lerp, cosp, and exponential formulas as well.

My point, and again I fully understand it doesn't make any sense for very advanced users, is the "good enough".

If set for specific actions ("slow" for angle different from "slow" for scale), I'm quite sure it can be done.

My English being average, maybe smooth wasn't the best word to use, but I'm sure you see what I want to say.

I had way more control on shaders when using GameMaker. Same on controls, handling, sound, etc... (Penelope started as a GMS project for 4 months).

But implementing a shader in GM takes one hour. In C2? 30 seconds.

If your goal is to craft a complete game, speed is the most important parameter, way over perfect control on expressions.

Damn, it took me 2 freaking years, full time, 7/7, to make the Penelope early access even always looking for the fastest way to do things.

So, at the end of day, I still think you're very right in your philosophy (learning things for real = way better), but also that both can coexist for maximum noob-friendship and speed.

Aurel I am not agaisnt not knowing something, but the lerp issue was not that people did not know it, it was that they used it even though they did not know it, I am not agaisnt simplification on some transitions effects for C2 (if there was a simple way to make a number X that will increase from a to b in a setted time by itself without needing to change any events,just with a "start increasing value" action, I am sure most of those would be completely solved by most users without any injuries), I am just saying that if you are using something, be sure that it works as expected, as quick does not mean broken, imagine if you did not saw the issues, it could have been far worse.

(actually, the start increasing variable action could be nice somehow, do you agree? it could correct most issues for transitions effects and movements I think).

Yep, that would be very convenient : )

EDIT: oh, and if you wonder why many are using lerp without fully understanding what it does, the answer is pretty simple.

(not excusing, explaining > ) You need a path system for your game, you look for tutorials, all of them use lerp. So, you use lerp. And it seems to work ok until you mix it with dt, then bam, we're back at the beginning of this thread!

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.

Refeuh so basically, games should work on a time-relative way rather than a framerate relative way as, if those techs catches up, relying on a stable display framerate would not work, right?

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.

G-sync sounds interesting - it does sound more sensible to have the monitor to wait for a frame than to have the system rush to produce a frame on schedule!

I love that too, refreshing only when a display change is transmitted, rather than refreshing constantly in hopes that something changes on the right times.

Not sure how that changes for browser vendors though thru their implementations.

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 The change should be almost transparent for higher-level apps like browsers ; this should be handled almost entirely at the driver level, though there will be some impact on the schedulers of multi-threading game kernels to maximise the efficiency of the frame structure (esp. pre/post-render stages and boundaries for animation/physics/rendering consistency)

I wouldn't worry too much honestly, I have seen games in development working on g-sync monitors with very little extra work.

Also this fits nicely with the philosophy of the new upcoming rendering APIs (MS/NVidia DX12, AMD Mantle, Apple Metal) which give more control of the rendering and GPU resources to the software.

As good as G-Sync is, make no mistake - at the moment it's a specialist resource, the only monitors I've ever seen with it are ones that come with powerful gaming rigs.

In my head it's akin to saying not to worry about performance issues because in 2 years time VRAM will be more common.