[alfon]

You beat me to it, haha, This is what I just did:

function intersectRect(rectA, rectB) { return !( rectB.left >= rectA.right || rectB.right <= rectA.left || rectB.top >= rectA.bottom || rectB.bottom <= rectA.top ); }

const arc = document.getElementById("arc"); const ball = document.getElementById("ball");

setInterval(() => { if (intersectRect(arc.getBoundingClientRect(), ball.getBoundingClientRect())) { window.dispatchEvent(new KeyboardEvent('keypress', { keyCode: 32, })); } }, 10);

My code seems to go on forever, closed the tab after it reached 60K

[nathas]

Oh neat! You did the Harder version and didn't use the game's own code to check it. I find that with JS games it's better to imitate the game's exact logic and call it's functions to make sure the state is working/updates correctly.

Of course, for how delightfully simple this one is, your approach is definitely faster/better!

[capableweb]

Definitely seems like alfon's solution is faster/better, as it's more accurate when the game speeds up. However, it's also more resource intensive! getBoundingClientRect (used to at least, long time I go I did browser performance stuff) forces a new layout calculation each time it's called, which is one of the most expensive things you can do in the DOM, and can lead to jank in the website. Some more information here: https://developers.google.com/web/fundamentals/performance/r...

Just adding this information for the ones who don't know and like to know more about browser performance :)

[ehsankia]

It is a bit of a slippery slope, because at some point, you could just do "GameApp.AddScore(10000)" which is clearly not playing the game. The line of what's "fair" and what's not isn't too clear. I do think staying out of the game code is actually a fairly good line though.

EDIT: Looked down thread and basically saw a bunch of examples of just that!

[afiori]

I believe that getBoundingClientRect does not force a layout calculation by itself, it only forces queued recalculations to happen synchronously.

So calling it 100 times in a loop should be fast, but calling it 100 times in a loot that also updates the DOM should be cripplingly slow.

[alfon]

Thanks for the note!

[brtknr]

What the hell is happening past the point of 2k where the ball remains in the centre? Is it all happening too fast for my tiny brain to comprehend?

[mhio]

This overwrites the games internal `arc` variable so the arc no longer updates, hence the forever-ness.