DNT released, OneWorld Coming!

#1 Looks interesting. Good luck!

#2 Not completely understanding your description of OneWorld. Does this mean your product will enable multiple clients to edit levels at the same time?

#3 That's the gist of it.

#4 Nice! That's something I've been wanting to see, but too lazy/busy/unknowledgeable to develop myself.

#5 Looking forward to this. Keep those updates coming.

#6 Thanks for the comments guys, it hasn't been an easy process. I can't wait to get this out to beta. I'm close, very close, gotta finish up simpaths, river and roads and I'll be in beta.

#7 You've worked extremely hard, you deserve success(!), congratulations on this monstrous release!

#8 DNT Product Page

#9 @Vince,
I have a very specific question that may solve some interfacing issues for me.

Can the DNT program generate a the DLL binding code that can be used to interface to a different language? Like LUA if you compiled the correct calls with it? Because if it can then you can leverage your program as a generic binding program to created bindings for any scripting or programming language.

If this is possible I would be very interested in getting DNT. Since the produced code is liberally licensed I can use it to do direct bindings to V8 or Python for instance and release that code. This will save me time.

#10 Frank,

DNT is a CSharp Framework where I took care of complete integration, I not only made the pInvokes friendly but I established a consistent feel and logic to the code. I just don't create extern's and say have at it, I spent months writing static code which leverages the generated code.

The best I could probably do for other languages would be to generate the externs for the c++ like I do for DNT and "a call wrapper" in the language chosen. You wouldn't have the framework, you would just have a million functions in the language chosen which set up the extern call in that language.

I do not believe that would be difficult to do, tbh. Assuming I either knew the language or all the specs were laid out for me. Since in all reality all I'm doing is code generation (Logical String Building) and it usually follows a format.

Unfortunately I just don't have the time currently for this endeavor. I'm under the gun to release OneWorld by Christmas and after that I've got the next major release of DNT coming out.

But, with that said, I might be able to help you out. The DNTC is written in cSharp, it is what parses and generates all of the pInvoke code. Assuming that we could come to some arrangement, NDA, contract etc, I could share our trade secret code generator code(lol, sounds funny) with you.

So in other words, I'd share with you our code generator source and my time and we would work together on the project, since I don't have the time to learn the syntax to Lua or Python. Winterleaf would have to retain the rights and ip to the code generator, etc. There would be a royalty in it for you for any sales of the new product since you would of helped to write the product.

I wouldn't be able to start this till February at best though and I would need to run it by Paul since he makes the business decisions. But I am all for it, the way I figure, it's 50% done, since parsing the c++ works already and all I would need to do is write the code generator for the selected language.

Vince

#11 Hey Vince,

I am not sure I asked the question right.

Thanks for the details. I was trying to understand if the externs were in a separate file from the C# code. I don't need a special build or anything. I thought if it already did the dirty work of exposing the interface to the DLL and consoles calls then I could leverage what you already created.

I figured if your code generator already had already exposed the interface then I could leverage that part of the generated code. I would do the later part. Besides, I think SWIG already does code generation for exposed APIs so that part is already done. The part that has the most potential to me is the exposing the console calls as typed function calls. I had some ideas about how to do this, but I did not want rewrite it if you already figured that out.

#12 Yeah, I didn't think about that frank, the code generated looks like

C++ generated looks like

extern "C" __declspec(dllexport) void  __cdecl wle_fnGuiCanvas_setWindowPosition(char * x__object, char * x__position)
{
GuiCanvas* object; Sim::findObject(x__object, object ); 
if (!object)
	return;
Point2I position = Point2I();
sscanf(x__position,"%i %i",&position.x,&position.y);
{
   if( !object->getPlatformWindow() )
      return;
      
   object->getPlatformWindow()->setPosition( position );
}
}

Then it generates the csharp which looks like

static internal wle_fnGuiCanvas_setWindowPosition mwle_fnGuiCanvas_setWindowPosition;
[UnmanagedFunctionPointer(CallingConvention.Cdecl, CharSet = CharSet.Ansi, SetLastError = true)] 
 internal delegate void wle_fnGuiCanvas_setWindowPosition([MarshalAs(UnmanagedType.LPStr)] [In]  StringBuilder guicanvas, [MarshalAs(UnmanagedType.LPStr)] [In]  StringBuilder position);

Then finally it writes the base csharp helper

/// <summary>
/// Set the position of the platform window associated with the canvas.
///    @param position The new position of the window in screen-space. )
/// 
/// </summary>

internal void fnGuiCanvas_setWindowPosition (string guicanvas, string position)
{
var sbguicanvas = new StringBuilder(guicanvas, 1024);
var sbposition = new StringBuilder(position, 1024);

SafeNativeMethods.mwle_fnGuiCanvas_setWindowPosition(sbguicanvas, sbposition);
}

Then after that is the framework generated code which groups the functions by object type etc.

So, yeah, if swig can read the C++ function declaration, then you should be good, Pretty much for the puffers for return values they are 1024 for params and 4k for return buffers.

Vince

#13 I don't generate a header for this file, I guess that wouldn't be that difficult though. Write out the function signatures to the DotNetC.H file so you could just import that into swig.

#14 Any news on OneWorld?
Is there a method for the clients and or players to receive the updates live? Like if you drop in a new asset? Or would the assets all have to exist on the client first?
Will OneWorld work with the DotNET version and standard TorqueScript when released or just DotNET?

#15 @Scot,

The initial release won't have the ability to do live updates, I plan to have that type of functionality in the near future though. So right now all clients will need the same asset base before connecting to the server.

Right now, we are trying to keep a matched build between the DNT and Torquescript builds. No promises but yes we may have a TS build of the first release of DNT. We are finding that the TS build is significantly slower than the DNT build. So it's still all up in the air.

Vince