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

Discussion and feedback on Construct 2

Post » Sun Jan 25, 2015 6:02 pm

@facecjf

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 :-? )
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Sun Jan 25, 2015 6:11 pm

@Refeuh

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

Refeuh wrote: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!
Image Image Image
B
63
S
19
G
6
Posts: 325
Reputation: 7,994

Post » Sun Jan 25, 2015 6:19 pm

@facecjf 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 !
Last edited by Refeuh on Sun Jan 25, 2015 6:24 pm, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Sun Jan 25, 2015 6:23 pm

@facecjf 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
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Mon Jan 26, 2015 2:34 am

Refeuh wrote: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. :|
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Mon Jan 26, 2015 2:43 am

@TiAm

Please avoid OLED displays, they have problems with ghosting which is worse than Plasma TVs. Try ULED instead, which is basically the same thing in terms of colour, expect it doesn't degrade since there are no organic components (One 2008 technical report on an OLED TV panel found that "After 1,000 hours the blue luminance degraded by 12%, the red by 7% and the green by 8%.").

Also, 4K isn't worth it at all. All movie releases are currently in 1080p, only a handful of games can do 4K and that requires what might as well be a render farm to play. To be honest, 4K is just going to be the same thing that "3D" was a couple years ago. Also, forget watching TV on a 4K tv/monitor, there's a delay that can be anywhere from 16 seconds to a full minute. Honestly just stick with a 1080p monitor.


On another note, does anyone know if Events that use speed need to have dt included? E.g. Bullet Behaviour or Platform behaviour?
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon Jan 26, 2015 4:15 am

@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
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Mon Jan 26, 2015 5:50 am

@TiAm

Well in any case, you might find this interested and hilarious to read before going out to buy a new TV/monitor.

Here's a quote from the article:
There's also ULED, an ultra LED (whatever the hell that means) that also uses Quantum Dots. When we talked to Hisense, one of the smaller TV manufacturers with way less market share at stake to risk by answering honestly, we were told that ULED and OLED are completely identical, despite the fact that OLED costs more.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon Jan 26, 2015 8:59 am

@Nesteris normally, if there is a unit like "in pixels per seconds"or "in degrees per seconds", that means that dt is not needed (as one pixel per second is still one pixel per second, regardless of the framerate, due to the clear definition of a second on a fixed timescale)

mostly, all behaviors related to movement should not need dt.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Jan 26, 2015 11:15 am

@Refeuh

Thank you very much! I appreciate that :)

Refeuh wrote:@facecjf 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


I don't fully understand this but, I think once I apply it and see it in action my visual brain will begin to grasp it.
Image Image Image
B
63
S
19
G
6
Posts: 325
Reputation: 7,994

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Nemega and 11 guests