With WAD merging with certain Doom 2 mods (eg,
doom2/Ports/megawads/strg), using a sprite in this texture causes some
engines to crash on loading the game. The mod makes up its new BOSF*
sprites but omits BOSFA0, which caused our game to crash when trying
to load Freedoom with Struggle.
This can break Plutonia mod compatibility a bit if they try to replace
this sprite too, but let’s hope that will not happen.
Python 2 is very near end-of-life, and Python3-compatible changes to a
few scripts introduced compatibility problems with 2.7 again. It went
unnoticed for me since my system symlinks "python" to "python3", but
it broke the build on systems where that symlink is still python2. At
this point in time, I feel it is worth targetting modern Python and
forgetting about 2.7.
Organize .gitignore by moving all patterns into a top level sorted
.gitignore file. With this change both "git status" and
"git-ls-ignore-index" should return cleanly. The later checks if any
files in the index are ignored.
Using the black code reformatter, pass it over all our Python files.
This allows for a consistent style across the code base.
Exception: lumps/dmxgus/stats.py, for readability.
This is one of the built-in variables for Make and can increase
portability on different operating systems (eg, on Windows, the
built-in $(RM) may be defined as "del" instead of "rm -f").
Now that we always include all textures in every IWAD, the configuration
is significantly simpler. The #defines we previously used to control
the conditional logic are now redundant.
We have been operating since the beginning with the idea of only
including matching compatible textures for Phase 1 and 2 based on the
textures that appeared in Doom 1 and 2, including keeping some
exclusive to each game.
This is artifically limiting to map creators and there is no good
reason to keep it this way. Fixes#588
Some mods (eg, crusades.wad) try to use SKY4 to (re)define other
textures, which doesn’t work in vanilla Doom, and the normal E4 sky
ends up creating a medusa effect.
While it is sad to see our light source go, reducing the effectiveness
of Double Impact’s lighting effects built into some of the maps, we
should prefer mod compatibility with Ultimate Doom.
Resolves#589
Replace all {S,W,B}FALL textures in the levels with their animated
equivalents, and remove {S,W,B}FALL from textures.cfg.
The {S,W,B}FALL were leftovers from when Freedoom had the goal of
being Boom-compatible instead of vanilla-compatible.
Also, rebuild these levels' nodes and reject tables with ZenNode.
A useful vanilla-compatible trick is that it's possible to include
sprites as patches inside texture definitions. It turns out that
both Final Doom IWADs added textures which do this, and Freedoom
inherits this as a result. We shouldn't include these sprites in the
pnames.txt that gets generated for inclusion in wadinfo.txt, since
they're already defined in wadinfo.txt under [sprites] and won't
be found under patches/ anyway.
This should help as a step towards resolving #485.
The tags are shorthand for the license of each file and avoid
copying the full license text into each one (and avoids having
to manually update the dates in each one...).
Redefine all of the new aquatex textures to be 128px tall.
This avoid tutti-frutti in vanilla Doom, where textures do not tile
property unless their heights are a multiple of 128.
Some textures which appear in both doom.wad and doom2.wad are defined
differently in each. We were always using the same definition in both
Phase 1 and Phase 2, causing compatibility problems with some levels
which expected a particular version of the texture.
To resolve, add both versions of the conflicting textures, controlled by
a new DOOM1_VERSIONS #define that allows which the version to be
selected. Use the doom.wad versions for Freedoom: Phase 1, and the
doom2.wad versions for Freedoom: Phase 2. This resolves part of #194.
A couple of scripts were not Python 3 compatible. Update smtextgen to
use print() instead of bare print, and update the texture build script
to use the correct binary mode for writing binary files.
On the dummy.wad level used as a stand-in for levels that don't
exist yet, show a computer sign on the wall that gives a brief
useful message encouraging people to contribute to the project.
Add some dummy texture entries that match the colormaps stored in the
single player IWADs. This allows levels that use colormaps to at least
be loaded in non-Boom compatible source ports, even though the rest of
the levels might not work properly. It doesn't seem to do any harm.
Having an arrow on the exit sign makes some levels confusing, as the
arrow can sometimes be pointing in the wrong direction or be
otherwise misleading. There is some discussion on Doomworld:
http://www.doomworld.com/vb/post/1303596
As the arrow version still looks quite nice, keep it around as a
second exit sign texture (EXITSGN2); include both the red and the
green versions.
Add FALL3 texture definition needed for TNT compatibility, and add
extra texture definitions so that all the patches required for TNT
compatibility are included in the PNAMES list (and IWAD). Add
symlinks for TNT sky patches that just point to sky patches that we
already have. Fixes#43.
The Plutonia WAD includes some extra textures (and associated patches)
compared to the original doom2.wad. Add these missing textures, with
dummy "Plutonia versions" of textures where they conflict with
existing ones, so that we include all patches needed for compatibility.
Fixes#42.
Now that #1 is fixed, we can be certain that all patches needed for
compatibility are definitely being included in the PNAMES lists. It
therefore isn't necessary to include every patch in the patches/
directory in every WAD.
Extend the build-textures script to generate a text file containing
the list of PNAMES, and include this from the main config file. That
way, each IWAD only gets the patches it explicitly needs.
Some build targets create multiple outputs, which can cause problems
when doing parallel builds. Clean up the build system so that all
subdir invocations come from the top-level Makefile and use $(MAKE).
Also fix the FREEDOOM/FREEDM lumps to really include the version
number by using $(shell ...) syntax.
Stop using deutex's built-in texture builder and generate our own
texture lumps. This is essential for compatibility reasons: the
entries in the texture/pnames lumps must match the order of those
in the original IWADs. Failure to match ordering means that some
well-known WADs (eg. DTWID) would not work with Freedoom.
This fixes#1, and also means that Freedoom can now be built in
parallel using make's '-j' option.
