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

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.

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().

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?

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.

— 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

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

Thanks for the link, I'll check that article !

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

Refeuh

— 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

[attachment=0:uz2wapky][/attachment:uz2wapky]

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..

—

Thanks for the details ! It is an interesting case indeed. Having re-read the whole thing, I understand much better know. I initially missed the fact that we're lerping from the current pos for a chase-behaviour.

And no need to apologise ! I hope I didn't make you feel you had to, because I didn't mean to be hard or aggressive or anything. My apologies, instead

If you don't like the lerps, why not breakdown the computations and do something you understand and you're comfortable with ; something you can re-use and tweak in future projects, and not rely on black-voodoo-magic. Is it important that your gun catches up exactly in x frames ? If not, maybe something like :

Every tick, if the Gun.pos is far from Player.ImagePoint

compute direction dir towards the destination : dir = Player.ImagePoint - Gun.pos

compute normalised vector v towards the destination : v = dir/dir.length (so that this vector has a length of 1)

move Gun along v depending on its speed and dt : Gun.pos = Gun.pos + Gun.speed*dt*v

for good effect, add a clamp() to make sure you don't overshoot if the gun is already close to the mount point

It's a bit less fancy, but if that makes more sense to you, maybe it'll be easier to get it to work the way you want. This ensure uniform speed, but doesn't guarantee the time for the Gun to catch up with the destination.

(for people interested in this kind of problems and modelisation, a spline arc-length reparametrisation would be a good fit. Out of the context of C2 built-in behaviours, but maybe a useful plugin )

Refeuh

No worries and no need to apologize! I just want to let you know my level of understanding

Every tick, if the Gun.pos is far from Player.ImagePoint

compute direction dir towards the destination : dir = Player.ImagePoint - Gun.pos

compute normalised vector v towards the destination : v = v/v.length (so that this vector has a length of 1)

move Gun along v depending on its speed and dt : Gun.pos = Gun.pos + Gun.speed*dt*v

for good effect, add a clamp() to make sure you don't overshoot if the gun is already close to the mount point

This definitely helps for my understanding. Though with this approach I assume I will have to create 2 vectors for vertical and horizontal positioning?

Thanks for the infos!

— Correct, I just wrote Object.pos , but you'll need to apply this to both dimensions, x and y. That would remain true in 3d where you'd only need to add z component to your vectors as well.

But make sure you don't dissociate x and y components, you *need* a (x, y) vector when normalising what I called vector "v". If you move separately on each axis independently, you will move along a non-normalised vector, the speed non-uniform and the simulation breaks horribly.

Check the C2 maths expressions, there might be some helpers to save time with vectors, with norms, length, etc. Maybe.

Let me know if you get stuck, I'll try to put a quick capx example together !

Alternatively if that makes things even simpler for you : use a bullet behaviour on the Gun ; if the Gun is far from the destination (using an arbitrary small threshold value), enable the Bullet behaviour and every tick set it's direction toward the Player.ImagePoint. When close enough, disable. Done !

— great art work, btw, I checked the links in your signature, very nice !

Unrolling the x & y you end up with :

dir.x = Player.ImagePoint.X - Gun.Pos.X

dir.y = Player.ImagePoint.Y - Gun.Pos.Y

dirLength = sqrt(dir.x^2 + dir.y^2)

v.x = dir.x / dirLength

v.y = dir.y / dirLength

Gun.pos.x = Gun.pos.x + Gun.speed*dt*v.x

Gun.pos.y = Gun.pos.y + Gun.speed*dt*v.y

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.)

Wow, that's really interesting...I had no idea such a thing was in the works. Such tech would do wonders for the apparent smoothness of games, as a game 'only' running at 40/50fps could still look really good if screen refreshes were synced up with it. Would be great on mobile where good framerates are less of a sure thing.

Ok, so my next monitor has to:

1. Be OLED. 2. Be 4K 3. Be ~30 inches 4. Have G-Snyc up to 120hz. 5. Not require me to sell any more internal organs. I think I should hold on to that last kidney.

Nesteris

/Start: Massive Geek Digression

I actually have a plasma, and while they have a vast litany of drawbacks, there is one thing they are uncontested at: TV and movies. In a dark room they beat the pants off any LCD display.

ULED is interesting, but frankly it sounds like it's just a souped-up local dimming + Quantum-Dot solution.

Quantum-Dot TV's have better color saturation than LCD, but can't compare to plasma/OLED on contrast. Local dimming...don't get me started.

The article I read said that the ULED tech was shown off in a brightly lit showroom where the superior contrast of OLED (and, likewise, the blooming caused by local dimming) would be impossible to spot.

I'll agree: 4k movies/tv are pointless for screens that aren't wall sized. But 4k for coding/graphics? Yes please.

OLED blue element lifetime has improved significantly since 2008. At this point: only an issue for monitors running 24/7. Burn is still a concern though (not near as much as with plasma).

The sticking point? Price. OLED is still too damn expensive. 50 inches has to get <$1500 to be competitive, and that's a way off.

/End: Massive Geek Digression