[1] https://www.youtube.com/watch?v=ha3fDU-1wHk

[2] https://www.youtube.com/watch?v=sAkSHzR-P7M

Nintendo's boot code is under copyright and thus cannot be used. So the boot code distributed with Libdragon is signed by finding a hash collision with a brute force tool running on the GPU[1]. Fun stuff!

[1] https://github.com/DragonMinded/libdragon/tree/trunk/boot#bu...

But yes, the N64 isn't particularly well suited for this type of game (or anything 2D, really). I didn't know that when I started the project.

The cartridges from Modretro only work on NTSC N64s, though. I'm told the next production run should work on PAL, too.

It's kinda sad when you grow up in a period of rapid hardware development and now see 10 years going by with RAM $/GB prices staying roughly the same.

[1] https://phoboslab.org/log/2024/08/high_impact

I've been meaning to write a proper post-morten about all that, now that the dust has settled. But in the meantime, just quickly:

- I did not make billions. You're off by quite a few orders of magnitude. After taxes it was well below $500k.

- Nothing I did was illegal; that's how I got away with it.

- Coinhive was not ransomware. It did not encode/hide/steal data. In fact, it did not collect any data. Coinhive was a JavaScript library that you could put on your website to mine Monero.

- I did not operate it for "years". I was responsible for Coinhive for a total of 6 month.

- I did not organize a doxing campaign. There was no doxing of Brian Krebs. I had nothing to do with the response on the image board. They were angry, because Brian Krebs doxed all the wrong people and their response was kindness: donating to cancer research. In German Krebs = cancer, hence the slogan “Krebs ist scheiße” - “cancer is shit”.

- Troy Hunt did not "snatch away" the coinhive domain. I offered it to him.

In conclusion: I was naive. I had the best intentions with Coinhive. I saw it as a privacy preserving alternative for ads.

People in the beta phase (on that image board) loved the idea to leave their browser window open for a few hours to gain access to premium features that you would have to buy otherwise. The miner was implemented on a separate page that clearly explained what's happening. The Coinhive API was expressly written with that purpose: attributing mined hashes to user IDs on your site. HN was very positive about it, too[1]

The whole thing fell apart when website owners put the miner on their page without telling users. And further, when the script kiddies installed it on websites that they did not own. I utterly failed to prevent embedding on hacked websites and educating legitimate website owners on “the right way” to use it.

[1] https://news.ycombinator.com/item?id=15246145

The JavaScript engine had a lot of workarounds for things that are not necessary anymore and some things that just don't work that well with modern browsers. From the top of my head:

- nearest neighbor scaling for pixel graphics wasn't possible, so images are scaled at load time pixel by pixel[1]. Resizing the canvas after the initial load wasn't possible with this. Reading pixels from an image was a total shit show too, when Apple decided to internally double the Canvas2D resolution for their “retina” devices, yet still reporting the un-doubled resolution[2].

- vendor prefixes EVERYWHERE. Remember those? Fun times. Impact had it's own mechanism to automatically resolve the canonical name[3]

- JS had no classes, so classes are implemented using some trickery[4]

- JS had no modules, so modules are implemented using some trickery[5]

- WebAudio wasn't a thing, so Impact used

- WebGL wasn't a thing, so Impact used the Canvas2d API for rendering, which is _still_ magnitudes slower than WebGL.

- Touch input wasn't standardized and mobile support in general was an afterthought.

- I made some (in hindsight) weird choices like extending Number, Array and Object. Fun fact: Function.bind or Array.indexOf wasn't supported by all browsers, so Impact has polyfills for these.

- Weltmeister (the editor) is a big piece of spaghetti, because I didn't know what I was doing.

Of course all of these shortcomings are fixable. I actually have the source for “Impact2” doing all that with a completely new editor and bells and whistles. It was very close to release but I just couldn't push it over the finish line. I felt bad about this for a long time. I guess high_impact is my attempt for redemption :]

[1] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...

[2] https://phoboslab.org/log/2012/09/drawing-pixels-is-hard

[3] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...

[4] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...

[5] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...

[6] https://phoboslab.org/log/2011/03/multiple-channels-for-html...

[7] https://phoboslab.org/log/2011/03/the-state-of-html5-audio

Years back I wrote a standalone Canvas2D implementation[1] that outperforms browsers by a lot. Sure, it's missing some features (e.g. text shadows), but I can't think of any reason for browser implementations needing to be _that_ slow.

[1] https://github.com/phoboslab/Ejecta

Imho, that's fantastic! I love to see devs being able to adapt the engine for their particular game. Likewise, high_impact shouldn't be seen as a “feature-complete” game engine, but rather as a convenient starting point.

[1] https://youtu.be/4lZfnM9Ubeo?t=3215

This fixes some bugs and also adds the mouse invert option.

Naturally the web frontend is written in PHP, so are the cronjobs, shell scripts, message queues, WebSocket server, client software, statistics and the server automation (think Ansible, but imperative). Sharing my own libraries between all these parts is extremely valuable. Owning the whole stack means I never have to deal with black boxes or fiddle with dependency management. The language just gets out of the way so you can solve your actual problems.

The fact that PHP is reasonably good at all these things is a big advantage. The performance is certainly good enough (never became a problem) and the long running server applications (e.g. the WebSocket servers) are rock solid.

I just ran qoibench on the photos they used[1] and QOI does indeed fair pretty badly with a compression ratio of 71.1% vs. 49.3% for PNG.

The photos in the QOI benchmark suite[2] somehow compress a lot better (e.g. photo_kodak/, photo_tecnick/ and photo_wikipedia/). I guess it's the film grain with the high resolution photos used in [1].

[1] https://imagecompression.info/test_images/

[2] https://qoiformat.org/benchmark/