Please login or register.

Login with username, password and session length
Advanced search  

News:

IRC channel - server: waelisch.de  channel: #wme (read more)

Pages: 1 [2]  All

Author Topic: DLL functions  (Read 16094 times)

0 Members and 1 Guest are viewing this topic.

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.075 seconds with 19 queries.