Both of these chain textures should be usable as decorations in places the player can pass through, but are not complicated enough that the fact that they don't look the same from either side would get lost in the details. I don't see why they shouldn't deserve similar treatment to the diagonal chains (18 and 19).
For when you want an upper area of a wall to have vines but you don't want them to unnaturally cut off at the bottom.
The regular vines have also been tweaked to get rid of some excessive solid colour blocks.
Nothing else in FD's repetoire quite matches the deep, rich, earthy green-brown that these textures have. They're perfect for certain outdoor environments - except in Final Doom they're part of this really unnatural fade-in fade-out animation. This doesn't really matter in FD in isolation but if you try to load a Final Doom-compatible animation definition then the entire intended effect is ruined.
This commit also updates E1M1 to use these new textures.
It was overwriting the existing id BROVINE2. Both are now available.
All levels have been converted to use BROVINE3 with a script. There are a few spots where BROVINE2 actually looks better but we can presume the brown wall green vine was the original authorial intent since that one has been the only one available since who knows how long, and it's not like we can't update these later anyway.
Also incorporates the Map11 edits from #1318.
Old green slime bricks preserved as SLIME13A and BRICK13A.
Map11 tweaked slightly to take advantage of both; also fixes the torch light effect in the octaminator zombie ambush and adds a big vent grate to that blank wall.
For maps that do things that might actually give an impression of an ostensibly horzontal-moving door that can be viewed from either side, or a pair of double-doors at the entrance to a level.
WOLF1 grey rocks by AxelMoon, copypasted into WOLF2 through 4 by me.
WOLF9 blue wall by 16BitGuy (Klikach) and AxelMoon.
WOLF10, 11, 12, 18 (steel doors) by SuperDave938.
Hand chain portrait converted by Craneo.
Swordsman portrait converted by AxelMoon.
AGM CEO portrait by Goji and Craneo.
Banners by Craneo.
Star chart by me.
See discussion in #1049.
If RW33_5 really is extraneous we can still get rid of it; otherwise it is now METAL9.
I've also taken the liberty of moving one of my recent textures.cfg additions to their proper place in the "Custom textures using resources of freedoom" section.
* textures: add GRAYRED and GRAYWIDE.
Also address #48 with respect to GRAYRED.
* textures: add AQPIPE06-7 and BROWN4.
The latter is called "BIGDOR6A" as the alternative BIGDOOR6.
* New Gray/ick wall by korp.
AS well new ones using stock patches.
* textures: add changes after April 2023.
---------
Co-authored-by: mc776 <24984517+mc776@users.noreply.github.com>
Some maps probably still have some COMPUTE4 textures that use the rightmost column of screens to the left of the leftmost column, which the recent expansion to 256 pixels would have broken. This adds two brand new screens to fill up the space, using colour schemes similar to the spectral graph and blue nebula.
I would like to add these to PLANET1 as well but there are probably maps that accidentally use the previously existing blank space to the right that would be broken by such an addition. If it is known for sure that I am wrong about this, let me know and I will add those as well.
Addresses #904. Defines the SUPPORT2 texture as though the SUPPORT2 patch were always 64 pixels tall.
A few pixels on the patch itself have been adjusted to get rid of a slightly visible seam, but the full patch height of 72 is unchanged.
A lot of IRL chainlink fences aren't nearly as tall as the full-height 128-unit texture we have now. An extra fence texture can be useful when creating more realistic environments.
Prior to the Eureka cleanup DM08 had circular saw blades on the left
side of the map via texture SLAD2. Unfortunately Eureka falsely flags
SLAD2 as a Medusa causing textures for middle textures since it
contains more than one patch. This fixes introduces texture SAW2 which
only contains the SAW2 patch, and which therefore does not cause the
Eureka warning. It should look exactly the same to the player.
Added new textures with stock patches, check the comments.
Removed broken glasses textures since it was unused.
added a new light patche, t14_4, by korp.
Height has been extended to 128, and new patches have been added (LFALLx) and are used instead of RWDM11x. I am deliberately leaving the original patches as-is, for the sake of PWAD compatibility.
Weirdly there's a STARBR2 but no STARBR1, and there are also these
SW11_4 and SW11_5 patches which are not used in anything except for
in COMPUTE3 as part of a montage texture. It seems like a natural fit.
These were Espi's second set of STAR* textures that he made for
Freedoom, and he ultimately replaced them with the ones that we have
now. However, I always liked these textures and the fact that they have
a very different and distinctive look compared to the original Doom
STAR* textures.
While this doesn't roll back STAR* to using these textures (and I don't
think we should), it adds them back as a second set of textures under a
different name (s/STAR/ESPI/). It would be nice if some of the Freedoom
maps end up making use of these in places and a nice tribute to Espi who
contributed so much to Freedoom in its early years.
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.
