No LoadMap ( ) function in leadwerks.dll?

[LEFans]

Do not see this function in leadwerks.dll.(LE3)

[YouGroove]

Have you read "darkness awaits" code or have you made a level test using LE3 at least ?

Caus LE 3 makes the basic App.lua code for you that load your map and it just works.

http://www.leadwerks...ap/mapload-r510

[LEFans]

I want to use other programming tools, rather than VC2010. So to call leadwerks.dll. Thanks.

[Josh]

C++ and Lua are the only supported languages at this time.

[Shaping]

C++ and Lua are the only supported languages at this time.

 

I will be interfacing VisualWorks to the C-API DLL, because I prefer to develop with a dynamic language, and I've already done many years of work that I don't want to port.

 

I'm trying to understand which functional areas are covered in the DLL and which are not. Josh has told me that the DLL is not a complete functional equivalent of the C++ class hierarchy, and that the DLL is currently used by the editor. Josh, can you tell us more about what is missing from the current DLL? I would like to see you support the DLL (the functional version of the framework), which is what I thought you had planned from the beginning. If you don't have resources for that, I understand, but please help us along with some suggestions for our own extensions to the DLL. I will probably be doing a lot of this, and I would be happy to contribute my additions to the product.

[Josh]

I only exposed the functions I needed for the editor. I don't know everything that's missing.

 

There's something like 600 commands, I think. Documenting them was hard enough, I can't imagine writing a wrapper by hand. I think there are some tools that do this automatically, seek the one called Klepto2. He will show you the way.

[Shaping]

I only exposed the functions I needed for the editor. I don't know everything that's missing.

 

There's something like 600 commands, I think. Documenting them was hard enough, I can't imagine writing a wrapper by hand. I think there are some tools that do this automatically, seek the one called Klepto2. He will show you the way.

 

These 600 "commands" are really just class member functions in the C++ framework, correct? Are you saying that you have equivalent flat versions (C functions) of some of these 600? I count about 505 non-commented-out function prototypes in the DLL header file. But I don't really expect these functions to map directly to the all of the member functions in the classes; so comparing these counts is likely not very meaningful.

 

After reading Kepto2's posts, I see that they are two years or older, and don't relate to L3. I sent Klepto2 a PM.

 

Is anyone else working toward a flat C-API-based version of L3 that they intend to use using directly, or wrap with their own classes? I don't need Lua if I have a flat C-API.

[Wchris]

Is someone still working on a Leadwerks.dll for LE3 ?

[klepto2]

yes, I'm still working on my .NET/Mono Wrapper for Leadwerks 3. I will have a new version ready by this weekend. Just waited for the terrain-update to be released.

[Wchris]

yes, I'm still working on my .NET/Mono Wrapper for Leadwerks 3. I will have a new version ready by this weekend. Just waited for the terrain-update to be released.

great news ! Thanks.

Will the wrapper have flat functions with the entity handle as first parameter like in LE2 ? Or will your wrapper recreate the whole object hierarchy ?

 

I would like to be able to call the flat exported functions from Delphi or Freepascal.

I guess other languages like Blitzmax also need such a DLL and won't be able to access the objects directly ?

[YouGroove]

Interesting

Like other people i prefer Java Like languages than C/C++ like.

C# could be a great winner.

[Shaping]

great news ! Thanks.

Will the wrapper have flat functions with the entity handle as first parameter like in LE2 ? Or will your wrapper recreate the whole object hierarchy ?

 

I would like to be able to call the flat exported functions from Delphi or Freepascal.

I guess other languages like Blitzmax also need such a DLL and won't be able to access the objects directly ?

 

Hi Wchris/klepto2.

 

Where are we sitting now in the development of a C-DLL equivalent (or basis) for Leadwerks 3.1? This is for those of us who enjoy the productivity of a dynamic language (or any language offering an FFI) and who are willing to wrap those C functions with their own new classes in the new language.

[Wchris]

Hi Wchris/klepto2.

 

Where are we sitting now in the development of a C-DLL equivalent (or basis) for Leadwerks 3.1? This is for those of us who enjoy the productivity of a dynamic language (or any language offering an FFI) and who are willing to wrap those C functions with their own new classes in the new language.

Hi Shaping,

 

Full 3.1 is not released yet, only steam lua version.

 

Klepto2 did a C# wrapper for 3.0 that can be found here http://www.leadwerks.com/werkspace/files/file/424-leadwerks-3-net-wrapper/

Strange it's now in a hidden LE2 subdirectory and the "code" subdivision from the download menu got replaced by "script". Probably because Josh is focusing on steam, maybe it'll come back when full Leadwerks 3.1 will be out.

 

The loadmap function is in Klepto's wrapper, but the wrapper is focused on OO so the C# objects get property names, but the undelying flat C export have no parameter names just arg1, arg2, arg3 ... This is because he is using an automated tool called SWIG that targets C#. If it could target C maybe we would have meaningfull parameter names.

 

klepto did 99% of the job to create a "C-DLL equivalent". I had no time to work on my leadwerks projects lately so I told him I would wait for 3.1. But if more people show up and show interrest for a flat C-DLL I'm confident he'll probably resume the task and find a solution. Version 3.1 is scheduled for end march anyway.

[Shaping]

Hi Shaping,

 

Full 3.1 is not released yet, only steam lua version.

 

Klepto2 did a C# wrapper for 3.0 that can be found here http://www.leadwerks.com/werkspace/files/file/424-leadwerks-3-net-wrapper/

Strange it's now in a hidden LE2 subdirectory and the "code" subdivision from the download menu got replaced by "script". Probably because Josh is focusing on steam, maybe it'll come back when full Leadwerks 3.1 will be out.

 

The loadmap function is in Klepto's wrapper, but the wrapper is focused on OO so the C# objects get property names, but the undelying flat C export have no parameter names just arg1, arg2, arg3 ... This is because he is using an automated tool called SWIG that targets C#. If it could target C maybe we would have meaningfull parameter names.

 

klepto did 99% of the job to create a "C-DLL equivalent". I had no time to work on my leadwerks projects lately so I told him I would wait for 3.1. But if more people show up and show interrest for a flat C-DLL I'm confident he'll probably resume the task and find a solution. Version 3.1 is scheduled for end march anyway.

 

Thanks for the update. So how many of us want this? I'm counting klepto2, Wchris, and myself.

 

I think we have the same thing in mind. Yes, we need correctly named formal parameters in all function or method calls. This is especially true for Smalltalk, where the keywords in the method selectors each name the formal parameter. As a contrived example we want DrawPointX: x y: y and not DrawPointX: arg1 y: arg2. You lose lots of reading speed and comprehension on long parameter lists, with the generic argument names.

[Wchris]

Thanks for the update. So how many of us want this? I'm counting klepto2, Wchris, and myself.

 

My update is worth nothing without Klepo's help ^^

 

I think we will be few to want this because the engine is not marketed as multi-language friendly like LE2 was.

[Shaping]

My update is worth nothing without Klepo's help ^^

 

I think we will be few to want this because the engine is not marketed as multi-language friendly like LE2 was.

 

Where is klepto2?

 

Josh, is the function set in the C-DLL only complete enough to support the editor, or is it complete enough to build all member functions of all classes in Leadwerks 3.1?

[klepto2]

Hi, sorry for the silence tha last days.

 

The C-DLL functions has a lot of functionality + a lot of editor related stuff, but i doubt it reflect the complete api.

I am already evaluating my wrapper generator with 3.1, but i need to solve some things here and there and i want to have LE 3.1 more matured before i release a wrapper which is subject to change frequently.

 

the 3.0 wrapper is currently hiddden because its not 3.1 compatible and Josh cleaned the workshop to only support 3.1 related stuff.

(So you can only download compatible stuff)

[Shaping]

Hi, sorry for the silence tha last days.

 

The C-DLL functions has a lot of functionality + a lot of editor related stuff, but i doubt it reflect the complete api.

I am already evaluating my wrapper generator with 3.1, but i need to solve some things here and there and i want to have LE 3.1 more matured before i release a wrapper which is subject to change frequently.

 

the 3.0 wrapper is currently hiddden because its not 3.1 compatible and Josh cleaned the workshop to only support 3.1 related stuff.

(So you can only download compatible stuff)

 

Josh/klepto2, which functions needed to build Leadwerks 3.1 class member functions are missing from the current, mostly editor-centric C-DLL? I'm trying to quantity and quality these missing functions, so that I can estimate how much time/effort I need to write them, and then to build what I need in Visualworks (arguably the most commercially successful and mature Smalltalk environ). At last check, the DLL contained about 600 functions.

 

I need the ease of programming and debugging that VW offers, and I have there many years of work I don't want to port. Porting and having to continue to work in C++ are, for me, two ways of working more slowly toward my goal--an unpleasant thought. In fact, I'm doing in the VW debugger some things that I could never do in VS. I don't want to waste time trying. More up-front time is needed to get Leadwerks 3.1 working in a dynamic language, but I'll be working this project for a while, and the invested time will be worth it.

[Shaping]

Josh, I know that you are busy finishing Leadwerks 3.1, but is there a response to the above question? I also wrote you an e-mail concerning this. I'm twiddling my thumbs and and waiting for a basic Leadwerks framework that I can get working in a dynamic programming environment, via an FFI to a C-DLL.

[Josh]

This just isn't a supported feature. Your best bet would probably to build your own DLL in C++.

[Shaping]

This just isn't a supported feature. Your best bet would probably to build your own DLL in C++.

 

I must be confused. We have a C-DLL that covers the functions of the editor, right? One could wrap those functions with classes one creates in any language that has a C-based FFI. I want to use as much of the framework I bought as possible, not write a new one. You've already done much of the hard work, and I want to leverage that as I do my own app-level work. I don't mind shadowing the existing framework. I don't want to write a new one, because my time/money budget doesn't allow for it.

 

I asked above what additional functions are needed to implement the methods found in the basic classes for the scene, primitive geometry, lighting model, renderer-- the basic stuff that lets you create a scene either with the editor (not necessary now for me) or programmatically (necessary for me). If those functions exist, where can I find them? I need to wrap them to implement the methods of the basic classes. I don't mind doing that work, but starting over is not necessary. I need to know which C functions are missing and where to get them.

 

In light of what you've said about this not being a supported feature, I'm having trouble understanding why klepto2 would build a C# wrapper using the C-DLL. I want to build a VW wrapper using the same C-DLL. I'm thinking that the rendering loop runs in the C# or in Smalltalk or in whatever language one chooses to shadow/implement the core classes. These would be the same classes that now exist in C++. This issue is not a matter of having or not having a supported feature. It's a basic matter of the form in which the code of the framework can be used. No one can wrap C++ classes from C#, Smalltalk, or any other language with an FFI. We can only wrap a flat C-DLL. What functions must I add to the existing DLL to implement the classes in the basic framework? I want to start this work now. I can't get any useful domain-level work done until I do, and I'm wasting time waiting for a solution from someone else. Thus, I'm willing to do what is needed to re-shape or shadow the existing C++ classes, but the basic functions needed in the framework class methods must be in the C-DLL. Such an architecture is efficient and separates framework-level and domain-level concerns somewhat. It let's me use much of what I bought but more productively. This architecture will render quickly, not as quickly as C++, but I don't care about losses under 15% of the C++ reference. The programming/debugging dynamism is more useful to me. This architecture lets me focus on using what I bought and on writing mostly my domain classes, once the basic C++ classes have been shadowed. I thought that this is what klepto2 was doing.

[Admin]

Here is the source code for the DLL interface. It is inconsistent, incomplete, and unsupported. But you're welcome to use it in whatever context you like:

DLLExport.cpp

DLLExport.h

[Shaping]

Here is the source code for the DLL interface. It is inconsistent, incomplete, and unsupported. But you're welcome to use it in whatever context you like:

 

Thanks. I'm studying it now.

 

I know that the C-DLL is not all-encompassing. What functional areas are left out?

 

The main issue is: does it contain the functions I need to build, in my programming environ of choice, an event/rendering loop that works by calling into the DLL and/or by setting-up callbacks from the DLL? Or, is that source in the C++ we get with our standard license? Or, do I need to buy some or all of the source to get this basic functionality? Does the C++ rendering/lighting loop currently run on a single thread? That would be easiest for me to implement as a first go. Does the physics engine also run on its own thread? Is there a place in the documentation that covers these topics?

[Shaping]

Can anyone answer the above questions?

[Yasha]

Did you look at SWIG, mentioned on the previous page? ( http://www.swig.org/ )

 

It wraps C++ classes from languages with an FFI (sorry to burst the "cannot be done" bubble). If you can get it outputting something your language can understand you shouldn't need a C-style DLL at all.

 

Leadwerks.h requires a small amount of tidying in order to work with it, but the main API does export correctly once you've put the right guards in place and so on.

 

If your language isn't supported directly, SWIG can dump a full parse tree in Lisp format which you should be able to pass through a second layer to process into declarations for the thing you want to use (or maybe one of the others will be close enough; I found the CFFI backend gave all of the necessary data in a much smaller file).

 

e.g. put this together in a couple of minutes: https://dl.dropboxusercontent.com/u/46635275/SWIGtest.zip

 

(Leadwerks_G.h is a preprocessed version, only contains limited declarations for export, skipping the irrelevant and the difficult; Leadwerks_wrap.cxx is the generated C-style library; Leadwerks.i is the interface definition that passes the original header to SWIG; the Lisp files are the generated CFFI output.)