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...
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
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!
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
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?
