This reverts commit 9b25e1447a.
The first level of the game is very prominent and I'm not convinced that
this had sufficient debate on the original PR. Opinions on the original
PR seemed mixed to lukewarm.
I'm also not convinced that this is an improvement over the previous
E1M1 but that is just my personal opinion. If we want to make this
change then we can, but it should be discussed more first.
The previous text was couching its words a lot ("don't emulate...
exactly", "this is a tough call"). Let's be more explicit and emphasize
that work should be original and not a clone of Doom. Besides being
safer from a legal standpoint, it's a better goal for the project in
general.
The previous wording ("but Freedoom by itself is just...") read like we
were putting the project down a bit. Let's not do ourselves a
disservice.
A second paragraph further down was framing us in terms of being a "free
alternative" to Doom. Let's ditch that; we are our own game. We can also
leave out the technical jargon about IWADs etc.
This moves the paragraph about compatibility further down the page into
its own section. I am *not* doing this because we are deemphasizing
compatibility as a project goal; rather, I'm doing this because I want
to *emphasize* the idea of Freedoom being its own independent game. The
idea here is to try to get away from the misconception some people have
that the goal of Freedoom is to be a "clone" of Doom.
This PR adds a LANGUAGE lump based on the lump from GZDoom in a classic format, which makes it possible to translate Freedoom into other languages. The Spanish translation was done by Discord user a19684361
This include reduced vertexes and wadptr compression, in the case of MAP03 it's actually quite of a hell to compress the vertexes as the maps has alot of unnecessarily high amount of vertexes with little to no reasons, this also alters the gate texture in MAP03 to replace the DOORSTOP texture with SUPPORT2 texture instead as it could cause visible seams in vanilla.
* sprites: simplify FCAN.
(also update the flame, apparently)
When the current fire can sprite was first introduced it came with a small, straight blue flame, in keeping with the appearance of a pressurized canister full of flammable gas: https://github.com/freedoom/attic/blob/master/sprites/raymoohawk/old-fcan/fcana0.png
It made perfect sense internally, but broke a lot of maps that used this actor (including FD's own Map16) as a generic rough yellow flame effect.
This was amended so that the flame's shape looked more like the slanted id one, but stayed blue: https://github.com/freedoom/attic/blob/master/sprites/raymoohawk/newer-fcan/fcana0.png
Eventually it was decided we could differentiate from id enough by doing the exact opposite - keeping the colour but changing the shape, resulting in the current yellow flames going up. Unfortunately by this point it was clear that the pressurized canister had long stopped making sense, but I'd already done the flickering lighting animation effects on it and didn't feel like making any changes.
This bugged me for years until today I decided to splice together something from the nukage barrel's bands and here we are.
* sprites: update new FCAN offsets.
The new flames don't throw particles quite as far up.
There's no need for us to recompile deutex every time we build Freedoom,
since it's already in Github Actions. In a comment on #671 it was
mentioned that this was done to work around a crash in the version of
deutex in bionic, but that bug is long-fixed now.
The MD5 hash algorithm has been deprecated industry-wide for many years
now and we should stop using it. As a replacement, add SHA3 and BLAKE2b.
We keep the MD5 hash for now but with a TODO to remove entirely it in a
future release.
More specifically, the use of `is` here appears to be a bug, since that
operator tests for operator identity. The correct operator to use is
`==`, but in this context using `.startswith()` better expresses what
we're actually checking.
I'm still stuck with grossly subpar recording gear right now, but this is urgent (or rather *long* overdue) as per discussion in #1486.
DSPUNCH is just me punching myself in the arm run through a *bunch* of stuff in Saucedacity until it started to sound like a punch ingame instead of a weird tinny click.
DSSKEPCH is that same sound remixed with a bit of DSSWTCHN for a vague impression of a metallic echo.
Since these will be printed on real dead paper and sent out in the
world, it seems like it may be a very good idea if we can identify what
version they were built from.
Without this it looks a little bare. Note that this is not an actual
heading, because otherwise the Table of Contents will appear in itself,
which is weird.
This bigdoor texture is weird as the patch is off center, then used twice in the texture to re-center it: once offset by -4 (-5 in id), then once again to fill in the gap on the right.
The id skulls are miscentered: they're in the middle of the *patch*, but get shifted off center on the *texture*.
The Freedoom skulls overcompensate, as though the offset were -8 instead of -4, with the result that the final texture is off to the right by 4.
This edit shifts it back towards the center of the final texture, as well as exposing a bit more of the wood around and between the skulls where it had been a solid dark brown.
By setting the `role=bare` property on these links, the URLs do not get
included in the text of the print PDFs. While we want to include the
URLs for most links, in some cases it doesn't add anything and is just
disruptive to the flow of the text.
