Currently, the game would attempt to search for the WAD files in the current directory, which (e.g. if user has populated $HOME
and runs it from there) might take up a lot of time and cause rather annoying startup delay. This design decision seems pretty controversial to me, and probably requires a rethink.
As a simple workaround, I disabled this behaviour in FreeBSD port, and attaching the patch for your consideration.
Check search directories for case where the default dir is
the home directory, or if it contains "Desktop", "Pictures", or "Music"
directories. If one of these is detected, the default dir
will not be searched. This is to avoid long searches due
to the depth of wad search, and to avoid searching the users
home directory, or exposing it to wad loading searches.
Please check if this is sufficient.
DoomLegacy was not meant to be run directly in a heavily populated directory.
If given the choice of taking away the search for other users, and altering your installation to stop it from searching the wrong directories, I would choose to move your DoomLegacy binary installation to a run-time sub-directory.
Search is Limited by fix in svn 1386.
Now it segfaults if run not via absolute path, e.g., just as
doomlegacy
, becauseprogdir
andprogdir_wads
would beNULL
in this case and they are dereferenced without a proper check insideowner_wad_search_order()
function in thosestrcmp()
calls.Fix of progdir==NULL problems in SVN 1485.
There is now protection against NULL progdir, and progdir_wads.
I have never seen such a problem on Linux, even when I have started doomlegacy without command line options. I suspect that this is operating system dependent as the progdir is returned by a SDL system dependent function.
Thank you for the debugging.