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
* Add a switch in the secret exit area to allow backtracking.
* Make ledges in secret route non-damaging and made pit below into 20%
damage slime, allowing jumpers to risk death for a couple shells.
* 10 DM starts.
This gives a nice effect of blending the title in with the menu.
We actually used to do this, but it broke with a title screen update.
Thanks @JNechaevsky for the suggestion.
Closes#388
This at least lays some groundwork for doing so, by gathering archive
members by wildcard expansion rather than zip's -r parameter (which
uses file system order -- essentially random), combined with LC_ALL=C
so that locale sorting orders don't matter either. zip's -X option is
also used so no Unix metadata (UIDs, GIDs, modes) are saved in the
archive.
To really complete the effect, faketime should be used to deal with
file timestamps. Requiring faketime to do `make dist` seems too
extreme to me, so I'm leaving it out, but the general idea is to run a
command such as:
faketime -f "$(TZ=UTC date -d "@$(git show -q --format=format:%ct)" \
"+%Y-%m-%d %H:%M:%S")" \
make dist
This does also assume that zip's default compression algorithm never
changes (eg, from DEFLATE to BZip2 or LZMA), or never releases an
improved version (eg, a better DEFLATE). It's not perfect, but this
should be good enough.
Map changes since v0.11 have desynced these. I recorded demo2_p2
keyboard-only, so the gameplay is extra bad. On demo4_p1, I used
a mouse, so it is a little more skillful.
‘boom’ and ‘doom’ represent Debian-style links for the alternatives
system to set up preferred ports. Now that we no longer require
Boom compatibility, it should be safe to remove the former. This
should only be an issue if chocolate-doom -> doom, and tries to play
one of the maps that aren’t vanilla-compatible yet.
zdoom and prboom are dead ports, superceded by gzdoom and prboom-plus.
I hope their removals aren’t controversial. If it adversally affects
anybody: setup the ~/.doomport symlink to point to them.
Finally, crispy-doom. Odamex is still preferred before it because of
its simpler multiplayer capabilities, otherwise Crispy would have been
a winner (imo). It has a close relationship to Chocolate Doom, but I’m
leaving that last because of the non-vanilla compatibility of Freedoom.
Chocolate Doom is a last effort to run something.
Causes conflicts with ZDoom mods that try to define their own HUDs,
at least three on IRC were reported as being basically totally broken
with Freedoom 0.11. While it was a good attempt at adding an
enhancement to Freedoom under ZDoom, we cannot afford to break mod
compatibility.
