An alternative would be to make it just a visual effect. Once the tree wood resource is at 50% (or something), play the falling animation and make it a trunk. No behavior change. The animation is very cool anyway.

It looks like this patch is not enough to fix build in latest Ubuntu, more info here:
https://bugs.launchpad.net/ubuntu/+source/0ad/+bug/1918179

Hi, here are my comments! (Sorry for the delay :) )

Reference to S3TC may as well mostly removed altogether, just quit with an error if not detected. See https://trac.wildfiregames.com/ticket/4803

Ok, so just commit the second hunk?

I said system, which got removed from Linux times ago, as I wrote here:
https://trac.wildfiregames.com/ticket/4362#comment:26
And which is removed in the second hunk of the patch.

Why not? system was already removed from Linux since it is no longer used, OS X should follow...

Looks Good To Me
:)

Untested, but LGTM.

Some comments.

D86 also has some cleanups for hwdetect.js that are related and worth checking.

You should also have a look at this file, where some options are dynamically enabled based on detected hardware:
https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/mod/hwdetect/hwdetect.js

Committed the 32 kbps version. We may use higher bitrates for the standard musics.

Here are 3 versions of the wav coded with aotuv at quality 0 (64kb/s) ,-1 (48kb/s) and -2 (32 kb/s).
Feel free to try them, if the 64 kb/s is not enough I can try with a higher setting.

I am away now, I can do the encoding tomorrow, I suppose.

Try:
ldd /usr/bin/oggenc
to check if oggenc links to newer libvorbis.

In D1097#43717, @elexis wrote:

I have tried oggenc with the quality parameter only.

For quality 0 I get a nominal bitrate of 64kbps. I believe to hear a difference at 25 seconds.
For quality 4 128kbps, quality 6 192kbps.
Maybe ogg is much smarter than mp3, but when listening to mp3s I'm really dissatisfied with 192kbps. Indeed people should hear the music on youtube or download it if they really want to however.
Since this is an 8bit track and only an easteregg we can justify reducing the quality and have a diffeent bitrate for this file to save that MB.

Also the fixed rate is inefficient, and intended for fixed size channels, e.g. ISDN were you can't go higher and you don't benefits from saving during silence, we should use vbr instead, uses higher bitrate where needed, save space on easy zones.
IIRC ffmpeg encoder is also broken with vorbis, I suggest using official oggenc on Linux or oggdrop on windows, with aotuv encoder library.

In D1097#43524, @elexis wrote:

The phrase play-custom-tracks is slightly misleading, because the tracks itself aren't custom. I'd say play-tracks should be sufficient and the custom part is only needed in music.js.

I suggest that we use the parameter argument, so that the player can type retro me to play and retro me 0 to switch back.
We can do this (possibly together with the cleanup mention in the inline comments) in a separate patch, or not at all, or all in this patch if you want.

About the ogg file:

Weird that it starts with 0_, but I won't make it inconsistent with the audio repository.

ogginfo reveals me:

Vendor: Lavf58.2.100
Channels: 2
Rate: 44100
Nominal bitrate: 112,000000 kb/s

mplayer -identify 0_8Bit_Bonus_Track.wav tells me however

ID_AUDIO_BITRATE=2116800
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2

112kbps is not the best quality. Arguably it doesn't matter for an 8Bit track, still.
The other tracks in that folder are in 160 kbps, so that should be fine for this 8bit track too then for the time being (the other tracks might be nice to have in 320kbps eventually).
I have set a fixed bitrate using ffmpeg and -b:a.

Is it just me that I found the low quality with its blurred edges more realistic? Maybe very low it is too much blurred, eventually something between the two extremes.

No idea if this is possible, but having the compression happens in its own thread would not slowdown the game, either PNG or JPEG.

I found the JPEG blockiness around text a bit annoying on the main menu screenshot. Obligatory humour image:

I am not a fan of lossy image compression, jpg also isn't great with non photographic material (e.g. GUI elements).
Also if the screenshot is edited and then resaved again as jpg this introduces a double lossy compression with visible artefacts.

Any idea why enet dlls are so much bigger in size?

There is at least a link with http that should be changed to https (the first screenshot one).

You may want to update most URLs with https rather than http where available.

In D474#24778, @vladislavbelov wrote: