phoboslab

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.

Good catch! That's likely an artifact of the LMS state being quantized[1] at every frame border. I will look for ways to improve this.

[1] https://github.com/phoboslab/qoa/blob/master/qoa.h#L324-L336

Curiosity mostly. As stated in the article, Opus is excellent and better than QOA in every way except in complexity (and as a result, performance). A possible application for QOA is games, where you need to play dozens of audio files immediately.

I haven't done any formal benchmarks, but with a simple `time` on the command line QOA encodes 10x faster and decodes 7x faster than Opus.

QOA should be quite suitable for SIMD optimizations, which would improve performance even more. Still on my todo list.

Traditional ADPCM is not terrible, it's just "meh". Compare:

- Original, 4039kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/orig.wav

- MS ADPCM, 1022kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/ms_adpcm....

- QOA, 812kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/qoa.wav

IMA ADPCM is in the same ballpark as MS ADPCM. ADX (not listed) comes close to QOA, but at 1136kb is also larger than those traditional ADPCM flavors.

While what you're saying is true - QOI performs badly with some types of images - I want to push back on the notion that the demo images have been "carefully selected" to tell a narrative. TFA alleges the same. This is absolutely not the case!

The benchmark suite[1] I compiled contains many different types of images. The "industry standard" sets like the Kodak and Tecnick Photos, texture packs and icons are complete. No images have been removed from these sets. Some of the other collections (photos and game screenshots from Wikipedia and those from pngimg.com) are a random sample. I did not remove any images just because they compressed badly.

Also, the fact that some images compress badly is a non issue, if the whole set of assets that you need for your game/app combined have an acceptable compression ratio. If that's not the case, by all means, chose another image format.

On average, for a lot of assets types, QOI usually performs quite ok.

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

I first encountered this in the Flac source[1]. They do the bit twiddling a bit differently than in this article:

    uval = (val<<1) ^ (val>>31);

Variations of this have probably been used countless of times in other libraries.

[1] https://github.com/LordJZ/libflac/blob/master/src/libFLAC/bi...

Very true. Apple has removed several of my games (all working perfectly fine) because, well, they felt like it:

> Since this app hasn’t been updated within the last three years [...] it has been removed from the App Store

True. I'd put it on the same level as connecting XLR cables. MiniDiscs (and to a lesser extent) UMDs were maybe the last examples of such satisfying mechanics.

We are moving towards a solid state future where no user interaction directly drives mechanics. Physical media has largely disappeared, few cars are sold with a manual transmission and everything is wireless.

Maybe folding phones will fill the gap. For now, at least my toaster remains!

> What is Krebs' false positive rate?

You only ever hear about it when he gets high profile cases wrong.

When my project was targeted by him, he ended up going down some conspiracy rabbit hole and doxed all the wrong people. This forced me to issue a correction - mission accomplished, I guess.

During his "investigation" he accidentally sent an email that was meant for his business partner to some of my friends. It offered a glimpse into his sensationalist mindset. I don't have much respect for that guy.

Pardon my ignorance: Are messages sent through this guaranteed to arrive in order?

This repo says how it relates to other implementations but curiously fails to mention what "expect" actually is.

So for everyone as ignorant as myself, I guess it's referring to this[1]:

> Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc.

[1] https://core.tcl-lang.org/expect/index

You can get some IDE support with a simple preprocessor macro[1].

It's a crutch, but at least you don't need to stuff the shader into multiple "strings" or have string continuations (\) at the end of every line. Plus you get some syntax highlighting from the embedding language. I.e. the shader is highlighted as C code, which for the most part seems to be close enough.

[1] https://github.com/phoboslab/pl_mpeg/blob/master/pl_mpeg_pla...

> MPEG is not free. A license is required for using MPEG.

For MPEG-1 this is not true anymore. All patents have expired. It's also far less computationally expensive and easier to implement/integrate than more modern codecs. This makes MPEG-1 a "good enough" solution for (e.g.) short video clips in a game.

Disclaimer: I wrote pl_mpeg[1], so my opinion is biased.

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

> Square Enix says the transaction (which was only $300 million) "enables the launch of new businesses by moving forward with investments in fields including blockchain, AI, and the cloud."

~ https://twitter.com/Wario64/status/1521017861803704321

Doesn’t seem like an official release, but really cool either way. Time to dig in and see what I got wrong in my 2015 reverse engineering[1] of the data format!

[1] https://phoboslab.org/log/2015/04/reverse-engineering-wipeou...

Sorry to rain on your parade, but this looks seriously over-engineered. There are 71 files in this github repo (6914 after `npm install`) for something that requires ~100 lines of code.

Related: here's some PHP code I wrote 14 years ago that does something similar, but tries to generate aesthetically pleasing avatars:

https://phoboslab.org/log/2008/12/instant-avatars

Co-founder of https://topchef.de here (bootstrapped whitelabel online ordering provider, focusing on the German market). We felt the same. It's truly amazing how bad the UX of many competitor apps is and how little business owners think about it.

Sometimes it's an uphill battle to even explain to business owners why being on takeaway.com is stupidly expensive - after all, at the end of the month they _receive_ money from them, instead of paying a monthly subscription fee.

Congratz to your unicorn status :)

A while ago I published pagenode[1] which powers my own blog[2] and some of my other sites. It sits somewhere in between a CMS-"library" and a static site generator, with all content stored in markdown files. It comes in as single .php file.

Note that pagenode is not a ready made blog system, but rather a library to build a blog, portfolio site or anything else that does not have user-generated content.

[1] https://pagenode.org

[2] https://phoboslab.org

Don't expect too much of QOI.

I wanted a simple format that allows you to load/save images quickly, without dealing with the complexity of JPEG or PNG. Even BMP, TIFF and other "legacy" formats are way more complicated to handle when you start looking into it. So that's what QOI aims to replace.

There's a lot of research for a successor format ongoing. Block based encoding, conversion to YUV, more OP-types etc. have all shown improved numbers. Better support for metadata, different bit-depths and allowing restarts (multithreading) is also high on the list of things to implement.

But QOI will stay as it is. It's the lowest of all hanging fruits that's not rotten on the ground.

After trying a lot of different calculators, I just settled on this little shell script to launch/raise a nodejs repl with FN+Backpspace:

  if [ $(xdotool search --name "calc repl") ]; then
   xdotool search --name "calc repl" windowraise
  else
   xfce4-terminal \
    --title="calc repl" \
    --color-bg=#123 \
    --color-text=#fec \
    --hide-scrollbar \
    --font="Deja Vu Sans Mono 14px" \
    --geometry 40x14 \
    --execute node -i -e "$JSREPL"
  fi

($JSREPL just contains some extra functions that I want in a calculator)

I can easily go back to previous calculations and results, define vars, run loops whatevs. Having it on a key combo and launching the terminal with a distinct text/bg color really makes a difference. It also launches faster than most other calculators I tried. For my purposes (non-scientific, mostly programming stuff), it's been great.

What exactly do you mean with "edge cases"? For what it's worth, the decoder has been fuzzed[1] and the benchmark suite[2] with 2800 images en-/ and decodes without losing any pixels, as checked by qoibench[3].

[1] https://github.com/phoboslab/qoi/blob/master/qoifuzz.c

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

[3] https://github.com/phoboslab/qoi/blob/master/qoibench.c#L440...

Sorry, I see how my previous comment was misleading. To clarify: No, QOI is not doing that. QOI stores RGBA as R,G,B,A because it is big endian.

Little endian would imply that RGBA is stored as A,B,G,R. Which was my argument against using LE for a file format.

Well, it's easier to read in a hex editor and seemed like the right thing to do for a "wire format".

The only places where it matters is the header's width/height and order of RGB(A) data. Storing RGBA as ABGR is not a great choice, imho. If you want to be endian independent, you have to read one byte at a time anyway (or swap).

No, the encoder checks if the color at the hashed value really matches before storing the QOI_INDEX. There's probably better ways to hash it, but this just seemed "good enough".

I should probably fix that. Is there a clever way to unpack a 5bit signed int other than treating it as unsigned and subtracting 16?

Thanks, fixed!

I'll probably investigate "resetting" the stream to allow for multithreaded en-/decode when I try to roll this into a video codec.

Fair points. I would argue that for most people a simple master-slave setup with manual failover will produce far fewer headaches than a "serverless" architecture.

When you are big enough to worry about the other issues, you surely are big enough to handle the requirements in-house. I see the dependence on some specific companies as the bigger threat to reliability.

> If you’ve created a database before, you probably had to estimate how many servers to use based on the expected traffic.

The answer is "one". If you have less than 10k req/s you shouldn't even start to think about multiple DB servers or migrating from bog-standard MySQL/MariaDB or Postgres.

I will never understand this obsession with "scaling". Modern web dev seriously over-complicates so many things, it's not even funny anymore.

The linked vsync-tester[1] is very cool. But it's sad to see that (at least on my system) nothing has changed since 2012[2] - Firefox still misses frames; Chrome consistently lags an extra frame.

[1] https://www.vsynctester.com/

[2] https://phoboslab.org/log/2012/06/measuring-input-lag-in-bro...