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

Discussion and feedback on Construct 2

Post » Sun Jan 25, 2015 1:38 pm

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.
B
57
S
19
G
9
Posts: 639
Reputation: 9,533

Post » Sun Jan 25, 2015 1:43 pm

@Elliott the difference being, telling not to worry about performances is not a good idea, whereas here, it is telling to worry about the fact a stable fixed framerate is not something you will find even in the long term and is still a better idea anyway to consider that fact as it helps for now too.
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 4:27 pm

@Aphrodite
speed=pps-0.5^dt
At this point I'm not even sure if thats the proper formula.
It would:
A: Simplify things for non coders, in an engine made for non coders.
B: Get a decent approximation of pixels per second without having to guess.

To be honest I have a hard time remembering every little trick without writing every formula down.
When we didn't even have lerp I looked "x = A + t * (B - A)" up, just like anybody else can.
Don't even get me started on anglelerp(), or distance(), or angle().
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Sun Jan 25, 2015 4:48 pm

I'm less confused, and curious...

If using lerp like this is a no no. (in most cases) lerp(a, b, x*dt)

I'm currently using lerp to set position of the gun to my character in this form :

Set Positions to X | lerp(self.X,player.ImagePointX(1),26*dt)
Set Positions to Y | lerp(self.Y,player.ImagePointY(1),28*dt)

If I try the correct route a = lerp(a, b, 1 - f ^ dt)

It seems I'm having to add a bunch of zeros to my number to replicate similar behaviors

Set Positions to X | lerp(self.X,player.ImagePointX(1),1-0.00000000026^dt)
Set Positions to Y | lerp(self.Y,player.ImagePointY(1),1-0.000000000028^dt)

Is this correct?
Image Image Image
B
61
S
19
G
6
Posts: 325
Reputation: 7,944

Post » Sun Jan 25, 2015 4:59 pm

@Elliott G-Sync monitors are a novelty, and it's pushed forward by NVidia (with competitors having alternatives in the starting blocks already) ; it makes sense that they are the one promoting their new tech as differenciation factor, and it's good marketing and com to associate this with their most powerful GPU products, i.e. "our stuff is what you need for the best gaming experience". They also provide gaming rigs for shows, conferences, demos, etc. to showcase their hardware and innovations.

But for the end-user, there is virtually no difference ; g-sync monitors are not more expensive to manufacture, and lots of devices can be made compatible with just a firmware update if they already have the right controllers on-board. It's novelty, but it's definitely not exclusive to people with powerful desktop rigs and high gaming budgets. As @Aphrodite said, all that it means is that we're moving more and more away from the idea of a fixed refresh rate, and learning "now" to design applications with this in mind is the only way to be ready when it will be the standard. Just like with multi-threading a decade ago when multi-core and virtualised CPUs started to become common consumer products.

@newt I'm not sure what the formula refers to, but x^dt would seem fishy in any kind of discrete integration approach. But why work in pixels per second ? This couples your logic tightly to a specific type of devices ; say you run your application on a normal device, and then on a Retina display - how does it remain consistent ? I would argue that we should always work in arbitrary units (whatever fits the projects, "1 tile = 1 meter" or something like that), except for specific situations e.g. aligning a HUD to safe zones, to abstract the world representation from it's rendering.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 5:14 pm

@facecjf If setting an object like a weapon to an image point of another sprite, why lerp-ing at all ?

And unless I'm missing something, lerp(x1, x2, s) with s = 26*dt doesn't make any sense ? "s" being the interpolation value, at s=0 we are at x1, at s=1 we are at x2. At a framerate of 30fps, 26*dt = ~0.87. That's a fixed position, fluctuating a bit back and forth around that position due to dt varying between frames

With this :
Set Positions to X | lerp(self.X,player.ImagePointX(1),1-0.00000000026^dt)

you end with (very small magical number)^(1/fps) ; at 30fps, that's the 30th square root of a magical number, which is another magical number

I haven't followed the full example, so I might be getting this wrong, but I fail to see the math logic between these formulas :-?
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 5:15 pm

You have to pick some unit to work with, and I don't see vectors, or vexels becoming viable any time soon.
Perhaps we could use the refresh rate somehow...

Edit:

Also:
https://www.scirra.com/blog/ashley/17/u ... delta-time
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Sun Jan 25, 2015 5:22 pm

Thanks for the link, I'll check that article !
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 5:39 pm

OK, 'read the article, I got the example and maths, but ... something bothers me ; the question is :

Why would we ever want to interpolate from the starting value ? (accumulating the progress made as the new starting position). I fail to see a case where that's useful :-?

I see mainly 3 scenarios :

1. Pinning an object to an other - no interpolation involved, just static offset in the local object's frame

2. Moving between two known positions ; pos = lerp(pos1, pos2, s) , with s updated every tick based on speed (and therefore going 0 -> 1 over the course of the movement). The known positions can be static or represent other objects

3. Moving from the current position towards another position, e.g. chase or catch-up behaviour. lerp(pos0, pos1, whatever) will always give a (pos1 - pos0)-aligned vector. Just use that with : pos += (pos2 - pos)/|pos2 - pos|*speed*dt (= normalised unit-length aligned vector*speed*dt), or just let velocity_dir = (pos2 - pos) and let the discrete integration update the position

I don't see what we're trying to solve by lerp from the current pos every tick :-? @newt can you please explain what you're doing with weapon, for example, so that I can understand the desired behaviour ; I'm clearly misunderstanding the use case here
Last edited by Refeuh on Sun Jan 25, 2015 5:45 pm, edited 1 time in total.
Image
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Jan 25, 2015 5:45 pm

@Refeuh

Refeuh wrote:@facecjf If setting an object like a weapon to an image point of another sprite, why lerp-ing at all ?

And unless I'm missing something, lerp(x1, x2, s) with s = 26*dt doesn't make any sense ? "s" being the interpolation value, at s=0 we are at x1, at s=1 we are at x2. At a framerate of 30fps, 26*dt = ~0.87. That's a fixed position, fluctuating a bit back and forth around that position due to dt varying between frames

With this :
Set Positions to X | lerp(self.X,player.ImagePointX(1),1-0.00000000026^dt)

you end with (very small magical number)^(1/fps) ; at 30fps, that's the 30th square root of a magical number, which is another magical number

I haven't followed the full example, so I might be getting this wrong, but I fail to see the math logic between these formulas :-?


everytick.png


I'm sorry I should have explained for what I am using it for... I'm not using it for absolute fixed positioning, rather it's to create a bit of (smooth) fast delayed movement. Essentially creating a catch up effect. When the player moves the gun positioning is delayed and then catches up.

I guess I'm asking if using lerp & *dt in the manor of the screen shot I posted, is correct?

It's been brought up before (I'm an art guy) that us simple minds see forum posts for using lerp & *dt and then use it, get good results, and don't understand why. I have been following this thread closely and it has me questioning my usage of lerp altogether because, I don't fully understand it. It just seems to work. I'm sure this pisses off you math guys. :/ I'm just trying to understand better, so that I am not doing things incorrectly even if they visually appear okay..
You do not have the required permissions to view the files attached to this post.
Image Image Image
B
61
S
19
G
6
Posts: 325
Reputation: 7,944

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Colludium, jefftrier, unicornspitfire and 5 guests