|Re: [AD] al_set_win_dll_path|
[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On Mon, Jul 25, 2011 at 4:43 PM, Elias Pschernig
> Well, the problem really is that Allegro right now hardcodes the DLL
> path to be in the same folder as the .exe. In my case that's the
> system-wide python.exe so its location has nothing at all to do with
> where my game has libvorbis.dll.
A manifest won't help here, because it'd have to be embedded in
python.exe or named python.manfest next to python.exe (I think).
I'm just sort of against platform specific functions as a matter of
principle when they can be avoided. (e.g., Many of the iphone ones, to
me, could easily be platform ones. Things like al_get_battery_level()
could apply to a laptop, etc.)
Another way to resolve this would be something like:
al_register_library_loader(proc /* user written callback */);
bool proc(const char *name, char *folder, int len)
// name [in] => name of file being loaded. could be used to
determine which folder is relevant
// folder [out] => place to find library
// len [in] => folder buffer size
return true; /* use this folder */
Any time Allegro needs to load a library, it would use the first
folder set by a proc that returned true.
Not sure if this type of thing applies to Linux / OS X as well, but
the above could solve it for all platforms. But if this is only ever a
Windows problem, then the above is just over engineering.