Topic: Bridging from 3D Rad to 3rd Party Dll's (Read 5850 times)

3dw32 · « **Reply #15 on:** September 19, 2010, 03:44:00 PM »

Hi, i still do not see wich part of your code is calling the 3rd party dll, whose name doesnt appear.
Isn't this the ususal way of calling a function in a DLL ?

Code: [Select]

#include "stdafx.h"
#include <windows.h>


typedef void  (_stdcall *oupfuncPtr)(short PortAddress, short data);
typedef short  (_stdcall *inpfuncPtr)(short PortAddress);
oupfuncPtr _Out32;
inpfuncPtr Inp32;

int  Reset(void)
{
    HINSTANCE hInstLibrary = LoadLibrary("inpout32.dll");
  if (hInstLibrary == NULL)   
{
      FreeLibrary(hInstLibrary);
      return 1; //pb de chargement de la Dll
   }
     _Out32 = (oupfuncPtr) GetProcAddress(hInstLibrary, "Out32");
     Inp32 = (inpfuncPtr) GetProcAddress(hInstLibrary, "Inp32");
   
     if ((_Out32 == NULL) || (Inp32 == NULL))     {
        FreeLibrary(hInstLibrary);
     }

     _Out32(78,11);   
    Inp32(0x34);         

 }

jestermon · « **Reply #16 on:** September 19, 2010, 09:57:30 PM »

For an actual example of usage that is done by a dll that is called from 3D Rad, see the thread starting at...
http://www.3drad.com/forum/index.php?topic=4562.msg37635#msg37635

Calling a dll from another dll is straight forward, and the way of doing this is a given. The key is not only calling the 3rd party dll functions, but passing parameters from 3D Rad to it, and getting data back again. This is where the concept of the "bridge" dll comes in.

3dw32 · « **Reply #17 on:** September 20, 2010, 06:50:56 PM »

Thanks Jestermon, this was the missing link !
Now i have an idea : would a universal wrapper dll be something that could work ?
The third party dll name, functions names , parameters numbers and types would be passed to the universal wrapper dll (UWD) directly from the script.
But the dll would be large to accommodate a large number of combinations.

Or maybe a dll source code generator would be something more easy to code.

jestermon · « **Reply #18 on:** September 20, 2010, 09:39:20 PM »

I have given much thought and experimentation to an "interpreted" dll, that would allow one to make a "universal" dll. I have experimented with many "script" languages which are embedded into the dll that gets called by Rad. It certainly does work.

To do the "on the fly conversion" with native c/c++ alone is a tiresome task, and not worth the effort, since you need to make a "huge" database of calls that will still need to be compiled into the dll, which makes distribution of the product a nightmare to maintain.

I find the easiest "interpreted" dll bridge to work with using Python, and its Ctypes. Since the python script can be added at runtime, and can be updated with a simple dll. But the problem with using a scripted solution is that you sacrifice speed of performance, since AngelScript runs fast enough to do the basic tasks. lua, rebol, ruby, python and even AngelScript give the best results so far, and all work very well, if you are want to explore this avenue

If the purpose is specifically for making a "bridge" to a local service such as a database, then interpreted is fine. It's when you need serious speed, such as validating chess moves, that the interpreter is out of its league.

Souce code generators are fun to play with, but the overhead is not worth the effort, since once it is in the user's hands, you will need a 24 hour help-line to provide support for a million possible problems. If it's only for your own use, then its simply a tool, that distracts from the game pipeline, if you are seriously into gaming.

But if gaming is a side issue, and you love programming, then play all you want

3dw32 · « **Reply #19 on:** September 21, 2010, 02:18:30 PM »

I not much of a coding guru, so i will stick to the usual method !

But maybe you will find this of interest :

Quote

http://elmer.sourceforge.net/

What is elmer?

Elmer is a tool which embeds a Python module into a C, C++, or Tcl application. The embedded Python module is used just as if it was written in the same language as the application itself, without requiring any knowledge of the Python/C API.

Elmer generates "glue" code that embeds an interpreter for one type of language into an extension for another. Elmer allows function calls and various data types, both native and custom, to pass transparently between the two languages.

jestermon · « **Reply #20 on:** September 21, 2010, 10:22:03 PM »

Thanks 3dw32,
I've looked at elmer some time ago. It's pretty great. I prefer the Python Ctypes, since they provide "native" data types that match c/c++, so data conversion is transparent. But it is really excellent for other interpreters that don't have this type of support.
Good luck with your dll's

3dw32 · « **Reply #21 on:** September 27, 2010, 04:52:47 PM »

Quote from: mohdumar on August 03, 2010, 01:25:40 AM

i dont know how to pass a float array to purebasic dll procedure.. i

try this PureBasic DLL, should work with the IDLLCall exemple :

Code: [Select]

Structure mydat
myarray.f[3]
EndStructure   

ProcedureCDLL MyFunction(*myData.mydat)
   *myData\myarray[2] = *myData\myarray[0] + *myData\myarray[1]
EndProcedure

jestermon · « **Reply #22 on:** September 27, 2010, 06:32:05 PM »

Quote from: 3dw32 on September 27, 2010, 04:52:47 PM

Quote from: mohdumar on August 03, 2010, 01:25:40 AM
i dont know how to pass a float array to purebasic dll procedure.. i

try this PureBasic DLL, should work with the IDLLCall exemple :
Code: [Select]
Structure mydat myarray.f[3] EndStructure ProcedureCDLL MyFunction(*myData.mydat) *myData\myarray[2] = *myData\myarray[0] + *myData\myarray[1] EndProcedure

Neither do I, I am not familiar with purebasic. I'm more a Java , c/c++, Python type of lady

3dw32 · « **Reply #23 on:** September 27, 2010, 06:37:29 PM »

And in Free Basic (Not for Jestermon

):

Code: [Select]

extern "c"
Sub MyFunction(Byval MyData As single Ptr) export
     MyData[2] = MyData[0] + MyData[1]           
End Sub
end extern

This forum is now archived!

News:

Author Topic: Bridging from 3D Rad to 3rd Party Dll's (Read 5850 times)

3dw32

jestermon

3dw32

jestermon

3dw32

jestermon

3dw32

jestermon

3dw32