newt Thank you! That I can understand, super helpful : )))

(Sorry if I sound like a dumb 8 years boy. It must be super irritating for you guys, really sorry. But picture someone who never did any math at school due to a cursus only focused on arts. I'm wayyyyy behind you all.)

Thanks a billion for all your answers. This is really kind of you all to take the time to have a look at this.

Like Kamizoto, you got me lost pretty fast, but I understand the most important:

• the game goes crazy only because I used *dt in events where I shouldn't, and I couldn't notice it before because 30-60 fps is a low variation compared to 60-120 tick per second.
• You can't code a game if you suck at mathematics, even with C2. I have to learn what I skipped at school as I was making fun of the geeks. Payback time, I guess!

I don't know if it makes sense, but here's a sincere feedback from a regular C2 user who sucks at math.

The dt guide is very well written, and when you read it, you think(*dt) you understand it. I've read it, I don't know, maybe 50 or 60 times.

But when you have to write tons of events, it would be so nice to have charts you can quickly reference to. Here on the forum, or even better inside C2.

Something like this:

lerp to an angle, use this:

lerp to a position, use this:

lerp to speed, use this:

lerip to scale, use this:

lerp to variable value, use this:

every tick events: don't use if this and this. Use if this and this.

every X second: don't use.

I must sound super lazy to most of you, and I definitely understand this, but for average users it would be a freaking life saver.

Kamizoto is explaining things way better than me : )

But yeah, basically that's it: all +60*dt events don't make any sense on 120hz. And then... game broken : /

This is my very first game with C2, so me making something wrong with DT is ***HIGHLY*** possible!

That's why I'm asking, to know if every C2 games behave this way, or if have to work harder on some of my *dt events : )

Streaming is causing problems on the game if perfs are too low (the usual frameskip visual issues with janks if you get <40fps), but also when the perfs are too high.

I'm sure I can do something for case 2!

There's this event where I never could figure how to put *dt correctly in it:

" lerp(layoutscale,0.65,4*dt) "

Any professor to teach me? : )

I read the *dt guide many, many times, but I'm never sure how tu use *dt when it's not only related to X and Y. It's like the rules change for every case.

Do you guys tried your games on 120Hz monitors?

Some people are reporting how my game goes bananas on it, it's like "every tick" events are executed twice, even with *dt on it.

If they switch the monitor back to 60hz, everything's fine.

Thanks : )

EDIT: as written below, the point of this thread is to know if I'm making something wrong or if 120hz monitors are incompatible with C2 games.

SPOILER: As mentioned later in this thread, C2 games should work ok with 120hz, if you handle your delta time operations correctly.

As very useful post for beginners can be found here:

Thanks! Much appreciated : )

Ah ah, It's so nice to see people playing it at last : ))))

I'm so happy right now.

I'm eager to start to work on the addtional missions and multiplayer. I have a few bugs to fix before that, but fantastic launch so far.

Ashley Tom I can't thank Construct2 enough for making this possible! Love you guys!!

PC and Mac available day one!

Linux is still complicated, be sure I'll bug the C2 community and cry for help pretty soon, ah ah : )))

This would be super useful indeed! : )

— That's super kind of you. To be really honest, aiming way higher than I was comfortable with is exactly what I've done. And to be even more honest here, I still don't how the code is actually working. It still was buggy as hell one month ago, now it's pretty stable, it's a freaking miracle. I really have to thank many people in this community for the great help. Thanks guys, really.

Also, I asked to 80bit to share his secret sauce as well. I won't have time to implement the cloud saves now, I have to freeze the code, but I'll try to do it shortly.

Oh, fantastic news then, because ignore gpu blacklist is already there by default in package.json.

Problem solved, thanks a lot — ! : )

After reading again the comments on the Greenworks dev page, it seems that having a .bat is blocking the chromium arguments.

Overlay works fine if I remove it (yeah!), so I'm doing it this way for now.

But I'm a bit worried to not have the .bat featuring the "ignore gpu blacklist" tag ...Does this sound dangerous to you guys?