phoboslab

Agreed! I used it to build the maps for my 13kb Quake demake[1]. Compared to q3radiant that I used back in the day, Trenchbroom is just so much more pleasant to work with. In hindsight it seems totally obvious that _this_ is the way a map editor should work.

[1] https://phoboslab.org/log/2021/09/q1k3-making-of

That[1] was James Lambert, who was also responsible for Portal 64[2] and is now developing a completely new N64 game. His Youtube channel is worth a follow.

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

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

Related to this, every ROM needs a "boot loader" that has to be signed and is verified by the lockout chip.

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...

All geometry is rendered as textured polygons. The raycasting step only determines visibility.

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.

Yes. The game was mostly developed with an original N64.

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

I just looked at the invoice for my current PC parts that I bought in April 2016: I paid 177 EUR (~203 USD) for 32GB (DDR4-2800).

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.

The WebGL game was build with my 2D game engine "Impact", which I previously ported to C[1]. The game has a 3d view, but logic still mostly works in 2 dimensions on a flat ground. The N64 version "just" needed a different rendering and sound backend.

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

Porting my 2014 WebGL game (https://phoboslab.org/xibalba/) to the N64: https://x.com/phoboslab/status/1982883072292069641

Updated the readme. Thanks!

You probably have an extension that hides the cookie banner? Scrolling is enabled after clicking through.

Googling your name reveals that you like to stir up drama. Please find another venue.

I don't know what your personal agenda is, but there's so much misinformation and hyperbole in your comment that I have to assume that this is personal for some reason!?

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 original JavaScript engine “Impact” from 2010 is at the end of its life; the C rewrite “high_impact” is new and will (potentially) be around for as long as we have C compilers and some graphics API.

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 <Audio> which was never meant for low latency playback or multiple channels[6] and generally was extremely buggy[7]. WebAudio was supported in later Impact versions, but it's hacked in there. WebAudioContext unlocking however is not implemented correctly, because back then most browsers didn't need unlocking and there was no "official" mechanism for it (the canonical way now is ctx.resume() in a click handler). Also, browser vendors couldn't get their shit together so Impact needed to handle loading sounds in different formats. Oh wait, Apple _still_ does not fully support Vorbis or Opus 14 years later.

- 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

It does, but the main speedup comes from using WebGL instead of Canvas2D. Sadly, Canvas2D is still as slow as it ever was and I really wonder why.

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

To be fair, they modified Impact _a lot_. In some of their development streams[1] you can see a heavily extended Weltmeister (Impact's level editor).

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

I assume you're talking about the pack_map.c used during build? That just was written in C because I had the .map parser already lying around from another side project. If I had done it from scratch for this project it likely would have been JS or PHP, too.

Please play the post competition version: https://phoboslab.org/q1k3/

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

For the past few years I've been building a B2B SAAS. Naturally I've chosen my "get shit done" language PHP to do it. While the product itself is as boring as it gets, I've had stretches of good fun with it by building _everything_ myself.

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.

Kinda related, I was exploring how much complexity you really need with https://qoaformat.org/ - compresses at 278 kbits/s, but is much simpler than even MP2.

Archived: https://web.archive.org/web/20220203133132/https://something...

Thanks, I missed that.

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/

As far a I understand this benchmark JXL was using 8 CPU cores, while QOI naturally only used one. If you were to plot the graph with compute used (watts?) instead of Mpx/s, QOI would compare much better.

Also, curious that they only benchmarked QOI for "non-photographic images (manga)", where QOI fares quite badly because it doesn't have palleted mode. QOI does much better with photos.

Romhacks are typically modifying the compiled binary ROM image. Kaze' work is based on the painstakingly disassembled code from the n64decomp project[1]. He's working in C, modifying the game and compiling it again for the original hardware. Not sure I'd call that a "romhack".

Great videos though!

[1] https://github.com/n64decomp/sm64

I love PHP. It's been my "get shit done" language for 20 years. It sustained many of my projects and not once became the bottleneck.

Wordpress however is still a hug pile of garbage. It might be functional and has all the features you'd ever need, but I could never trust it to run even a simple blog.

Edit: just looked at the some random Wordpress sources to check if source quality improved. It didn't. Who could ever be productive with something like this?: https://github.com/WordPress/WordPress/blob/master/wp-admin/...

I was very confused about your comment (because the obvious answer is to use a JOIN), but then I realized you're talking about using a sharded database. To which my response is: don't. Just buy more RAM.

I realize that this doesn't scale indefinitely, but for the 99% of us who just need to manage a few billion rows, it's the right answer.

I'd argue that if you have an IN() with more than a dozen values, you're doing it wrong. Especially so if that's something that your app does often and it needs to be fast (as opposed to one-of analytic queries where you don't care about performance).

The unlicensed source makes this difficult. My current plan is to trim the game to a demo with one race track, compile it to WASM, put it on my website and get Sony's attention (maybe through Nightdive Studios?) for a proper re-release.

In the likely event that this fails, I'll just YOLO it and put it on Github. After all, Sony didn't care that I published[1] all of wipEout's assets seven years ago.

[1] https://phoboslab.org/wipeout/

I've been working with the leaked wipEout source code for a while[1] and I can assure the quality of the Quake source is absolutely stellar in comparison. While Quake's source may not be up to modern best practices, the overall architecture certainly has a lot of structure and thought put into it.

Modifying Quake to run on the Occulus Rift was a breeze[2], compared to the mountains of garbage I have to wade through with wipEout.

[1] https://twitter.com/phoboslab/status/1653707447586922498

[2] https://phoboslab.org/log/2016/05/quake-for-oculus-rift

You assume that the quake maps were built sequentially, but that's not the case. Since this was all new technology, the "best" maps were conceived at the end of development, after the team was familiar with the tech. You want those maps to be at the start of the game, as it's the first thing the player sees.

Also, the distinct style of the last episode is easily explained by the fact that all of its maps were built by Sandy Petersen. E3 was mostly American McGee, while John Romero and Tim Willits worked on E1 and E2.

I'm not a fan of Petersen's maps either, but they are regarded (and liked) as quite unique, compared to the rest of the game.

In Germany you can pay 35€/mo for 5GB of data traffic (t-mobile) and then enjoy the bandwidth of 5G for a full 40 seconds. It's a total joke.