Re: [AD] al_set_win_dll_path

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Tue, Jul 26, 2011 at 12:20 AM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> Hmm, maybe a different, more general solution is:
>
> al_set_exe_name("c:/foo/game.py")
>
> Because don't you have a problem with
> al_get_standard_path(ALLEGRO_RESOURCES_PATH) returning the python
> directory?
>
> The above function would affect the library loading location in
> Windows. It would also adjust the RESOURCES_PATH to be "c:/foo" in
> this case. It would affect what Linux and OS X (non-bundles) report
> for RESOURCES_PATH as well.
>

Would work for me. However I feel tying RESOURCES_PATH to the location
of runtime DLLs is a bit inflexible. I might have a game where my
resources are in /usr/share/mygame/ and the libraries are in
/usr/lib/mygame/. It's a contrived example of course but still, in the
documentation of RESOURCES_PATH we already tell users that they may be
on their own in some cases - so we shouldn't force the location of
runtime plugins.

So my suggestion would be, rename al_set_win_dll_path and have this function:

al_set_plugin_search_path(ALLEGRO_PATH *path)

It would specify the path where Allegro looks for additional plugins
at runtime before looking in the standard places, on all platforms.
(Currently only Windows makes use of runtime DLL loading, but in the
future we may add that to other platforms as well.)

Also, reading up a bit on manifest files, it seems I could use
al_set_plugin_search_path("") therefore causing Allegro to call
LoadLibrary("libvorbis.dll") in which case I could specify the actual
location in a manifest file. (With the absolute path next to the exe
we are using otherwise the manifest file would be ignored.)