Passed the kata in Go but I didn't implement any ordering, only counting. The tests can't be very thorough.

Same test case in Go.

How the hell does this get all the "Best Practices" votes?

I passed all the sample tests in 500ms. But timed out every time on the real attempt. Is this an optimisation/performance kata? It could be tagged "performance" if this is the case...

Ok, I agree that there are a few methods that will work, e.g. using plain numbers or hashes. I think building up big 2D arrays and looping them every turn causes performance woes unless optimised, and I expect plenty of people to use that method.

For now I suggest going to your profile page, clicking the solutions tab, scrolling down until a good amount are loaded, then manually copying the solutions you like into your own text files (or file). Personally I save the good ones in a git repo.

It would be a nice feature if we could filter by language on that page.

Eventually passed by creating new empty rows as needed, not at the start. Fair enough.

It ought to say somewhere that performance is required though.

I was not expecting to have to write a "performance" solution to Space Invaders. I just wrote it the obvious way using arrays. I can pass the example tests in 150ms but the actual tests take over 12000ms. What kind of crazy numbers of aliens are we battling here? Might be good to put a note in the description if the tests are that big.

Your ship's (x,y) coordinates seem flipped from what I would expect (comparing to similar katas I've done). I.e. you've placed him at aliens[x][y] instead of aliens[y][x]. I don't think it's a convention you've broken or anything, just giving a heads-up in case any other players trip up on this.

I divided [0, 765] by 76.6 to map the values linearly onto [0, 9.99], which seems like a fairly accurate way of getting 10 equal bands of grey out of the full input domain (well 99.9% of it) and also means you can floor those bands onto [0,9] for your 10 array indices. There may be another way of writing it mathematically, but sticking in a value like 80 just means you are mapping the domain unevenly onto the intensities array.

I can't figure out how the kata expects it to be mapped though.

Perhaps a "fuzzier" way of testing would be to sample 100 random pixels and require an 80% match rate?

I'm outputting decent faces, but can't pass the tests. Here's one example (Left: expected; Right: got):

https://www.diffchecker.com/bQL273ni

Now, obviously there are a fair few different characters, but surely it comes down to the intricacies of how you convert from 765-0 to indices 0-9. Is it completely linear?

I think for that one I used Math.floor((765 - rgbsum) / 76.6) to make the index. I had other math variants but none of them passed.

Also, is ctx.imageSmoothingEnabled supposed to be off or on?

What else could make the difference between mine and yours?

Can happen if you were handling length 2/3 and after ASCII-conversion it only had length 1.

Check at what point you test the length, to avoid accessing a non-existent position.

Zero is included in the continuous range -3 to +1 (expressed in the output string as "-3-1", where the first dash means "negative" and the second dash means "to"). No need to treat zero differently from the other numbers.