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.
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.
textgen: instead of running ImageMagick yourself, output a Makefile rule
for each graphic. Dependencies are passed on the command line.
Makefile: Add rule for 'textgen.mk' which is built by running textgen.
graphics.stamp depends on textgen.mk and all the built graphics files.
Then, each built graphic depends on textgen.mk, ensuring it is made
first. textgen.mk itself depends on textgen config, font, and dehacked.
(Makefile itself also depends on textgen.mk implicitly via include)
This duplicates previous behaviour where changing textgen config remakes
all text graphics, but one Make rule for each, allowing parallel make
with -j instead of the script doing one at a time.
The built IWADs are byte-for-byte identical before and after this patch
series is applied (provided VERSION is set to the same thing of course)
One problem is 'make clean' rebuilds textgen.mk because Make thinks the
Makefile needs it, but then immediately deletes it. Not sure how to fix.
Use git clean -fdx instead, or just don't clean twice in succession.
----
This gives the following improvement in build time (-j1 as control,
built on 4 cores and a large tmpfs so disk speed isn't a factor)
(master)
make -j1 4.83s user 6.77s system 93% cpu 12.444 total
make -j1 4.74s user 6.72s system 93% cpu 12.267 total
make -j1 4.72s user 6.68s system 92% cpu 12.292 total
make -j4 5.72s user 6.77s system 109% cpu 11.414 total
make -j4 5.39s user 6.85s system 107% cpu 11.419 total
make -j4 5.66s user 6.79s system 109% cpu 11.383 total
parallel_textgen
make -j1 4.57s user 6.66s system 92% cpu 12.185 total
make -j1 4.73s user 6.57s system 93% cpu 12.152 total
make -j1 4.60s user 6.72s system 93% cpu 12.152 total
make -j4 5.62s user 7.72s system 262% cpu 5.084 total
make -j4 5.82s user 7.76s system 262% cpu 5.165 total
make -j4 5.79s user 7.73s system 261% cpu 5.161 total
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...).
The original Doom HELP screen showed the default key bindings for the
game's controls. This is not so useful nowadays: at worst it's
outright misleading because the player might not be using the
defaults, but it's also redundant because most modern source ports
allow the key bindings to be changed via the menus, which doubles as a
convenient list of the current key bindings.
Z0k suggested an alternative HELP screen that shows the items and
powerups available in the game. More discussion can be seen in this
thread: http://www.doomworld.com/vb/freedoom/69458-help/
This extends the new font to include lower case as well as upper
case characters. Add a couple of kerning rules for the lower case
characters so that they render nicely, too.
Decompose the help screen into three parts: the background, the
text and the title. Generate all except the main text programatically:
the background as a color transformed version of the INTERPIC graphic
and the title using the textgen tool.
This replaces the old Freedoom font with a new chunky one named "Denex".
I (fraggle) have split the font out into separate images for use with
the textgen script, but have included the original source .pcx image
here.
Currently the font only includes uppercase characters and does not
include smaller lowercase ones, so I've hacked the textgen script to
convert all strings to uppercase before rendering. There are also no
font kerning rules for the time being.
If a text string contains all lower-case characters, then generate
it at a reduced height. This is necessary for certain graphics, like
the WIF graphic ("FINISHED") on the intermission screen, otherwise
it ends up in the wrong location (#49).
Adjust the offsets for some graphics in the build config to
compensate, and fix up the vertical offsets for WICOLON/WIMINUS while
we're at it.
Give a fourth channel blend percentage of zero so that the alpha channel
of the default fill colour (fully opaque black) is ignored. This fixes
the blue menu titles (skill, episode etc.) having black backgrounds.
The use of -colorize here blends 100% of the default fill colour (black)
into one or more channels of a greyscale image. Mixing in 100% black is
equivalent to nullifying the channel by setting it to zero, e.g. red
text is achieved by mixing 100% black into the green and blue channels.
It turns out, when passed more than one value (to affect all channels by
that percentage equally), -colorize looks for _four_ separate channel
values (RGB and alpha). If fewer are given, the missing ones inherit the
blend percentage of the first channel (red).
For red and white there is no effect, as the red channel is left alone.
But blue blends 100% of the red channel (thus, unwittingly, the alpha
channel) of fully opaque black into the image, making it fully opaque...
- factor out command line generation: a new function _make_command_line
returns most of the command line for a transparent image rendering.
- Callers render_transparent_text and render_text append the output
filename and extra imagemagick options to colour the background as
needed. This means imagemagick is only called once per generated
image, which makes the process considerably faster.
- This also works around a bug in the current version of imagemagick in
Debian sid, which caused single-character graphics (e.g. winum*) to be
generated with a black background.
DW: http://www.doomworld.com/vb/post/1221810
Acked-by: Simon Howard <fraggle@gmail.com>
Signed-off-by: RjY <rjy@users.sourceforge.net>
Remove the big text graphic images used for the menus and the
intermission screen. Instead, generate these graphics programatically
from a script. This allows them to be easily changed and extended
as desired.
