Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest WME version: WME 1.9.1 (January 1st, 2010) - download

Pages: 1 2 [All]

Author Topic: DLL functions  (Read 16093 times)

0 Members and 1 Guest are viewing this topic.

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
DLL functions
« on: February 19, 2003, 08:49:30 AM »

Hi,
I have another really simple wish ;):
Calling functions from standard C++ DLLs.
As a programmer I'd like to add my own support functions for calculations and maybe some AI.

Greetings

Banbury
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #1 on: February 19, 2003, 01:02:13 PM »

Yes, I'm seriously thinking about this potentiality. I believe a good plugin system can greatly increase the extensibility, for example I like the way extensibility works in Unreal engine.
Of course, the problem is to design a good interface between the engine and the plugins, but I already have some ideas... :)
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #2 on: February 19, 2003, 03:09:06 PM »

I think the easiest way would be to allow external function definitions ala Visual Basic.
The declaration could look like this:

function MyFunction(Param1, Param2) external 'mycool.dll';

You'll probably need some form of type information for the parameters and return values.

Greetings

Banbury
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #3 on: February 19, 2003, 03:25:43 PM »

Yes, this is the simpliest way. Indeed the type information would be necessary; also, it would only work for primitive data types.
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #4 on: February 21, 2003, 08:09:56 AM »

Maybe it's possible to treat all parameters and return values as typeless pointers (void *). In the DLL they would be handled as pointers to classes. This way you could use complex types.
All the DLL author would need is a header file with interfaces to your type classes.

Greetings

Banbury
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #5 on: February 21, 2003, 08:57:13 AM »

Right, but I wouldn't want to publish directly the WME's internal classes. I think it would be better to make some simplified "proxy" classes, to encapsulate the objects exposed by the engine.
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #6 on: March 31, 2003, 06:07:11 PM »

OK, I'm working on a simple DLL interface right now. You'll be able to run a single function from a specified DLL library just the way described in one of the above posts.
More comprehensive plugin support will follow in the future...
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #7 on: April 01, 2003, 10:07:48 AM »

Hooray! I'll promise to write a neat DLL as soon as this feature is available.  ;)
Oh, and it would be nice to have the window handle (HWND) or better the device context (HDC) of the backbuffer as a WME constant.  ;D

Greetings

Banbury
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #8 on: April 02, 2003, 04:42:53 PM »

Whew, it seems to be working now 8) I'll release it sometime later this week, because while I was modfying the script compiler I decided to (finally!) add a switch command. I'm so tired of that "if else if else if else if ..." mess  ;)


Oh, and it would be nice to have the window handle (HWND) or better the device context (HDC) of the backbuffer as a WME constant.  ;D
Well, I could publish the HWND of the WME's main window, but I can't offer a HDC, because there is no HDC when the engine runs in an accelerated mode (Direct3D 8 doesn't provide device contexts anymore), so no direct drawing into the backbuffer, sorry. The planned advanced plugin support will (probably) allow you to use a WME sprite as a simplest drawing element, it should be enough (?). I'm afraid a direct acces to the back buffer will not possible because of the duality of WME's redering subsystem...
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #9 on: April 03, 2003, 09:00:35 AM »

Hi,
this sounds good. And I missed the switch statement, too.  ;)

Maybe it's possible to provide functions to convert a sprite to a HBITMAP and back. This way one could modify the sprites with GDI before sending them back to the engine.

Greetings

Banbury
Logged

Jerrot

  • Global Moderator
  • Addicted to WME forum
  • *
  • Karma: 0
  • Offline Offline
  • Gender: Male
  • Posts: 690
    • View Profile
Re:DLL functions
« Reply #10 on: April 03, 2003, 05:18:09 PM »

Wow, "real" coders here! I wish, I understood all this stuff, although I read these terms several times when playing (fooling) around with VC++ and DirectX. (Actually I just didn't understand the code I ripped from anywhere...  :-X)

@Banbury: I'd be very interested, what's possible with that dll support. It would be GREAT to see a sample and maybe some explanation, what's possible, this could become a really good reason to return learning C++...

@Mnemonic: I'm sure the dll support is a great feature, but until I understand it - I'm also very thankful for the switch() command.  ;D  ;)
Logged
Mooh!

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #11 on: April 04, 2003, 07:47:13 AM »

Hi,
essentially the DLLs we are talking about are just a bunch of functions. These functions can contain any code you want. So there is no real limit to what you can achieve with this but your imagination. On the AGS pages you can find some pretty good examples of useful plugins for a game engine.
Now for the bad news. C++ is not an easy language to learn. And writing DLLs belongs to the advanced topics. So if you are really interested in learning how to program be prepared to invest some time (a few months at least). And get yourself some good beginners books.

If you have more questions about programming don't hesitate to ask. I'm always willing to help.

Greetings

Banbury
Logged

Jerrot

  • Global Moderator
  • Addicted to WME forum
  • *
  • Karma: 0
  • Offline Offline
  • Gender: Male
  • Posts: 690
    • View Profile
Re:DLL functions
« Reply #12 on: April 04, 2003, 08:09:41 AM »

essentially the DLLs we are talking about are just a bunch of functions. These functions can contain any code you want. So there is no real limit to what you can achieve with this but your imagination. On the AGS pages you can find some pretty good examples of useful plugins for a game engine.

That was the first place I started, but didn't find too much there. And then I downloaded some game and then I played and... oh well, I forgot why I was there. ;-)

Now for the bad news. C++ is not an easy language to learn. And writing DLLs belongs to the advanced topics. So if you are really interested in learning how to program be prepared to invest some time (a few months at least). And get yourself some good beginners books.

Thank you - actually C++ is not completely new to me, but I never had a good project or the time to start with. I'm in internet development, so next to PHP/ASP/etc. I'm used to some Java, and I suppose C++ won't be too difficult to learn... I hope ! ;) Thats why I would be happy to see some code examples for a simple DLL to use in WME when the next version is released, I just need some nice goal! :-)

Ok, I'll look for AGS plug-ins now. Again. Really.  ;D
Logged
Mooh!

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #13 on: April 04, 2003, 08:48:13 AM »

The main differences to JAVA are pointers and the absence of a garbage collector. Getting used to pointers can be difficult (it was difficult for me at least).
All my releases come with full source code. So they should be useable as tutorials. The first thing I will try is to add new advanced datatypes like trees.

Greetings

Banbury
Logged

Jerrot

  • Global Moderator
  • Addicted to WME forum
  • *
  • Karma: 0
  • Offline Offline
  • Gender: Male
  • Posts: 690
    • View Profile
Re:DLL functions
« Reply #14 on: April 04, 2003, 09:04:08 AM »

The main differences to JAVA are pointers and the absence of a garbage collector. Getting used to pointers can be difficult (it was difficult for me at least).

Uh, I remember pointers from C (without ++) on my old AMIGA, you're right, I hated them. I understood them later at university - when I didn't need them anymore - but for sure I forgot that stuff.

All my releases come with full source code. So they should be useable as tutorials. The first thing I will try is to add new advanced datatypes like trees.

Great, I'm looking forward to it.
So finally to understand it the right way - is that dll support finally like a language extension for WME? Could it look like this somehow/someday ? -->

#includeDLL("weather.dll");

actor.Talk("Uh-oh... the weather seems to change...");
StartRain();
BigFlash();
actor.Talk("AAAAAAAAAH!!!!");

;)
Logged
Mooh!

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re:DLL functions
« Reply #15 on: April 04, 2003, 09:44:08 AM »

Quote
Maybe it's possible to provide functions to convert a sprite to a HBITMAP and back. This way one could modify the sprites with GDI before sending them back to the engine.
Well, I think this would be possible, but do you really think it's necessary to draw directly into the backbuffer and/or texture? I always thought a bitmap/sprite is sufficient as a basic graphic element.
Plus, conveting the D3D texture/DD surface into some generic structure and back would probably slow the things down...


Quote
And writing DLLs belongs to the advanced topics.
It depends on what DLL it is. Writing a DLL containing a set of utility functions is IMHO quite easy. And that's just the way it's meant to be in the first incarnation of WME DLL support :)


Quote
And then I downloaded some game and then I played and... oh well, I forgot why I was there. ;-)
Yeah, tell me about it. I must admit that instead of finishing the switch command, I got swallowed by The Black Mirror game yesterday ;) Pretty cool game, BTW, once the english version is out, be sure to get it!


Quote
The main differences to JAVA are pointers and the absence of a garbage collector. Getting used to pointers can be difficult (it was difficult for me at least).
Exactly :)


Quote
The first thing I will try is to add new advanced datatypes like trees.
Wow, that's quite a huge task. Do you already have some idea of the DLL interface for this? I mean, the current DLL interface is really simple. Basically it works like (from WME's point of view): 1) load dll library, 2) call a function, 3) unload dll library. Therefore it's difficult to hold a context in the DLL between subsequent calls to its function. Of course, you can overcome this by calling the LoadLibrary function explicitly and keep the DLL loaded all the time, but there comes the biggest problem: the player can save/load at any time and there is no standard mechanism of telling the DLL to "serialize" its internal data. That's why I keep saying it's just a simple interface, call a sigle function form a DLL and that's all.

My plans for the future are: the DLL "plugin" will contain one or more "objects" (in WME terms). The object will be published to the engine and it will have to provide some standard interface set, such as construction/destruction, setting/querying its attributes, calling its methods and being able to serialize (save/load) its state. Plus, the visual objects will provide an Update and Display methods.
On the other side, the engine will provide an interface between its internal objects (some "proxy" classes, simplified versions of some of the native WME classes) and the plugin. For example, the plugin will be able to tell the engine: "Create a new sprite, load it from file 'sprites\MySprite.sprite' and give me a reference to the new sprite object".

What do you think about this?
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

Banbury

  • Lurker
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 36
  • I'm a llama! Mooh!
    • View Profile
Re:DLL functions
« Reply #16 on: April 04, 2003, 12:42:41 PM »

Quote
Well, I think this would be possible, but do you really think it's necessary to draw directly into the backbuffer and/or texture?
I think it would be cool for filters or dynamically created sprites (e.g. constructred from different parts). In my case I want to be able to paint a beam from one point to another onto the background.

Quote
Of course, you can overcome this by calling the LoadLibrary function explicitly and keep the DLL loaded all the time
That's what I hoped for.

Quote
but there comes the biggest problem: the player can save/load at any time and there is no standard mechanism of telling the DLL to "serialize" its internal data.
I admit, that I didn't think about serialization. In the case of my tree type, I could overcome it, by initializing the tree, the first time it's called in a game session(providing it's possible to use global DLL variables). I want to use this trees for conversations and haven't thought about any further use :-\.
Maybe a general serialization could be done by using binary buffers or strings. The plugin would use a special function to allocate memory in the engine, that's automatically serialized.

Quote
My plans for the future are: the DLL "plugin" will contain one or more "objects" (in WME terms). ... What do you think about this?
It sounds very professional but also very complicated (for plugin developers).  It would allow for very powerful plugins and I would certainly like to have this kind of access to the engine. Maybe it would be the best to have both ways ;D.

Greetings

Banbury
« Last Edit: April 04, 2003, 01:07:00 PM by Banbury »
Logged
Pages: 1 2 [All]
 

Page created in 0.021 seconds with 20 queries.