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

Discussion and feedback on Construct 2

Post » Sun Jan 25, 2015 8:46 am

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

Image


@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.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Sun Jan 25, 2015 9:00 am

@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).
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sun Jan 25, 2015 9:02 am

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!
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Sun Jan 25, 2015 10:19 am

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.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 10:36 am

@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?
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sun Jan 25, 2015 11:11 am

@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.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 11:44 am

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!
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,250

Post » Sun Jan 25, 2015 11:50 am

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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sun Jan 25, 2015 12:00 pm

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.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 12:08 pm

@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.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 7 guests