Replacing TorqueScript

Expanding and utilizing the engine via C++.
  • 1
  • 2
15 posts Page 2 of 2
Rene Damm
Posts: 3
Joined: Wed Apr 15, 2015 7:11 pm
by Rene Damm » Sun Apr 19, 2015 4:00 am
Whoah, it's @ Rene Damm!
Hey Daniel :) Been coming round here occasionally to see what's going on with good old Torque. Thought I may as well contribute something, even if it's just random comments.
Interesting Rene... I always wondered how the engineAPI info was meant to be used. Before I couldn't really find a concrete explanation for the merits of such a system besides "better docs" or "better parameter type checking".

I investigated making use of the information myself for embedding but didn't find it useful enough since certain things seemed to be missing (I forget which, it was a while ago), memory management seemed a bit weird, and the whole process seemed a bit backwards if you weren't intending to use it to generate a C#, Java, or a basic <insert favourite scripting vm here> module. Also no varargs :(

As a veteran torque dev, IMO one of the strengths of the older console system is I can quickly make scriptable functions or objects anywhere and rebuild the exe without having to worry about external tools in the pipeline. That seemed to be missing a bit in engineAPI. Thinking about it though I guess one could probably achieve something similar with engineAPI if they made use of a scripting API which relies on an FFI-like interface (like LuaJIT or Angelscript), though then again its probably not going to be good enough unless the DLL-with-a-processing-tool approach is used.
Aside from the benefits you mentioned, engineAPI was mainly meant to hide all the internals of how the interop works (such as the manual string parsing that the old console methods were doing) such that the interop can be done in whatever way you want without changing any of the script methods.

The "final" version also supported varargs. What's now in T3D is sort of engineAPI v0.8.

We eventually used it from C# without any generator tool. It requires manually adding some interop stuff but .NET makes that very, very easy. Still, once it was set up, the interop generator actually made for a really nice experience. Add something in C++, hit build, and continue writing in C# with VS/ReSharper seeing all the new definitions (and even documentation; we converted the docs added in C++ to XML docs in C#).
JeffR
Steering Committee
Steering Committee
Posts: 858
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Apr 19, 2015 6:02 am
Whoah, it's @ Rene Damm!
Hey Daniel :) Been coming round here occasionally to see what's going on with good old Torque. Thought I may as well contribute something, even if it's just random comments.
Interesting Rene... I always wondered how the engineAPI info was meant to be used. Before I couldn't really find a concrete explanation for the merits of such a system besides "better docs" or "better parameter type checking".

I investigated making use of the information myself for embedding but didn't find it useful enough since certain things seemed to be missing (I forget which, it was a while ago), memory management seemed a bit weird, and the whole process seemed a bit backwards if you weren't intending to use it to generate a C#, Java, or a basic <insert favourite scripting vm here> module. Also no varargs :(

As a veteran torque dev, IMO one of the strengths of the older console system is I can quickly make scriptable functions or objects anywhere and rebuild the exe without having to worry about external tools in the pipeline. That seemed to be missing a bit in engineAPI. Thinking about it though I guess one could probably achieve something similar with engineAPI if they made use of a scripting API which relies on an FFI-like interface (like LuaJIT or Angelscript), though then again its probably not going to be good enough unless the DLL-with-a-processing-tool approach is used.
Aside from the benefits you mentioned, engineAPI was mainly meant to hide all the internals of how the interop works (such as the manual string parsing that the old console methods were doing) such that the interop can be done in whatever way you want without changing any of the script methods.

The "final" version also supported varargs. What's now in T3D is sort of engineAPI v0.8.

We eventually used it from C# without any generator tool. It requires manually adding some interop stuff but .NET makes that very, very easy. Still, once it was set up, the interop generator actually made for a really nice experience. Add something in C++, hit build, and continue writing in C# with VS/ReSharper seeing all the new definitions (and even documentation; we converted the docs added in C++ to XML docs in C#).
Man, I hadn't even noticed that the EngineAPI stuff got that much attention in Torque 4. I'm gunna have to dig into that at some point.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Sun Apr 19, 2015 6:35 am
Behold, a wiki page!
chriscalef
Posts: 377
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Tue Apr 21, 2015 5:25 am
Hell of a nice wiki page!

Buckmaster +1
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Tue Apr 21, 2015 10:35 pm
Are you really going to get people using Lua instead of TorqueScript?
Well, I would, but it's not worth the effort to me to put it in there. TorqueScript works fine, warts and all, so why spend any time at all pulling it out just to plug something else in?

Oh, I'd probably enjoy working in Lua considerably more and there would overall probably be fewer WTFs per second. But personally I'm fine with using what's there.
  • 1
  • 2
15 posts Page 2 of 2

Who is online

Users browsing this forum: No registered users and 3 guests