How do I dynamicly load shared libraries under Linux like Loki''s games so that the game can be compiled without linking to the libraries, be able to give more helpful, information if the library loading failed, implement a plugin system, and allow selection of drivers like Loki''s games? Also is using lots of pthreads is a game engine a good idea? Or should I just try to have everything done in a function or functions that are called in the game loop?

compile and link with the -shared flag, that will make your program use shared libraries.



Edited by - kwizatz on December 28, 2001 10:41:04 PM

Pardon my ignorance, but are shared libraries essentially the same as dynamic libs in Win32 (i.e., dlls)?

rm -rf /bin/laden

Check out: http://www.linuxjournal.com/article.php?sid=3687

The things you want to look at are dlopen, dlerror, dlclose and dlsym. I think they''re in dlfcn.h? Maybe? Never done it myself.

The general procedure is to compile a totally independent module, then call dlopen on the filename (apparently). For example, run ar (that''s a command) on all your .o files. That''ll make you a .a archive, which you should be able to load.

Doing the rest of the stuff... that''s more tricky. Given that you can actually load your external files...

1) Above.

2) If you''re plugin fails, use dlerror to grab the error message and use that for more information; the plugin you write should generate an appropriate error message.

3) A plugin system generally depends on an abstract class you implement in the loaded external file. For example, you could have a unit class which has all thing abstract functions; move(), die(), walk(), draw(), etc. and every unit is actually just a plugin that you load.

4) The selection of drivers is done by the above, but the classes are more general; for example, a 2D graphics class might have the draw_line(), draw_poly(), draw_image(), init() and shutdown() methods. However, those can be implemented in openGL, X11, Windows, etc. The plugin system lets you choose what file to load, and hence run on a particular platform.

5) Nope.

6) Yes. Threads are a point of argument, however, all you do is slow yourself down and put yourself out for problems about syncronisation usually, unless you are doing something very useful; like playing music in the background for instance. That could be handy. What you have to remember is that unix is written to run multiple processes at the same time. Why go to the (less supported and develeoped) practice of threads when it''s all ready so easy to do a whole new process (via fork() for instance). On the other hand, leave unix and suddenly you find you dont have a platform that does multiple processes at the same time.

Basically I guess that covers what you asked in a broad sense. If you want more details, ask. I''ll give you a more detailed answer if you give me a more detailed question.

CmndrM: Pretty much.
Kwizatz: Um...I''m not sure that was the question. Isn''t it --shared? *shrugs* Dunno.