RE: [GD-Windows] GetProcAddress()

[Emmanuel A. <emm...@wi...>]

I'm interested by more info on this stuff...

I'd like to create 'mod' dll that would use the core engine fonction.

For the moment, I'm using Python as the script language, but I will have
to get back to plain C/C++ because our games are distributed by Web, and
I can't afford the extra weight of Python ( about 700 ko ) (sic...).

So any more info would be really appreciated...

Thanks,=20

Emmanuel


> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]
> Sent: mercredi 17 octobre 2001 18:12
> To: 'Erwin de Vries'; Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: RE: [GD-Windows] GetProcAddress()
>=20
>=20
>=20
> I do pretty much the same thing -- I have a render layer that=20
> I explicitly
> load from a DLL.  One of my problems was that I needed my=20
> renderer to be
> able to use a few functions out of the application that=20
> loaded it (warning
> logging, etc).  It's actually possible to have a DLL load=20
> symbols from an
> executable, but the executable name has to be known at link time.  The
> problem I ran into is that I wanted to be able to use this=20
> one rasterizer
> DLL with multiple executables (the game itself, world builder=20
> tools, asset
> viewers, etc).  I did some research and ended up using the techniques
> involved in hooking DLL functions to actually allow the DLL=20
> to rebind the
> imported functions into the executable that loaded it.  Very=20
> nifty.  If
> anyone wants more info, I'd be glad to type some more stuff=20
> up.  It took me
> several days to figure out this trickery, but in the end it=20
> cleaned up a lot
> of crufty code.
>=20
> jefftep
> Jeff Grills
> Star Wars Galaxies
> Technical Director, Austin Studio
> Sony Online Entertainment Inc.
>=20
> -----Original Message-----
> From: Erwin de Vries [mailto:er...@vo...]
> Sent: Wednesday, October 17, 2001 4:58 AM
> To: Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: Re: [GD-Windows] GetProcAddress()
>=20
>=20
> > A perhaps better way of using DLLs is to have each DLL=20
> export one factory
> > function for the kind of services it implements, and return=20
> an interface
> > implementing all the services. All function calls into the=20
> DLL will then
> be
> > routed through this one interface. The interface could=20
> consist of a simple
> > aggregation of a procedural API, or factory functions for=20
> the kinds of
> > classes the DLL exports, or something fancier (such as=20
> something you can
> > query for other interfaces by name). In effect, you'd be=20
> hand-rolling
> > something COM-like, without the additional management/installation
> overhead
> > of COM.
>=20
> Yes! Thanks for the idea. I just tested it, and it is exactly=20
> what i wanted,
> except for the factory create function, but i can obviously=20
> live with that.
> =3D) I knew there must be some way to use DLL's in a normal manner.
>=20
> > Another approach, if you don't need the run-time loading,=20
> is to just let
> > your app link against the .LIB link library at link time,=20
> and reference
> all
> > the functions directly. This is still a win compared to=20
> statically linking
> > everything if you expect some parts of the system to rev=20
> much more often
> > than others.
>=20
> Thats not what i want, because i want to dynamically link to=20
> our renderer.
>=20
> Erwin
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20