#640 Searching for WADs in the current directory can severely delay the game startup

[Alexey Dokuchaev]

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.

[Wesley Johnson]

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.

[Wesley Johnson]

Search is Limited by fix in svn 1386.

[Alexey Dokuchaev]

Now it segfaults if run not via absolute path, e.g., just as doomlegacy, because progdir and progdir_wads would be NULL in this case and they are dereferenced without a proper check inside owner_wad_search_order() function in those strcmp() calls.

[Wesley Johnson]

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.