C#/vb.net

#1 The app would also run horribly slower. And it would take eons to convert the source. But you're more than welcome to have a go at it. I thought a conversion to Delphi would be fun, but instead got flamed from here to hell and back.

I suggest just sharpening your C++ skills. :-)

- Brett

#2 It would be an extremely monumental undertaking. Writing C# wrappers would be less monumental, but then you'll have some major performance hits in areas like DirectX which is already a GL wrapper...

#3 I'm not terribly worried about the performance. From what I've seen messing around with DirectX9 in .NET it performs quite nicely. I'm mostly worried about stuff being in there that doesn't exactly work in .NET.

#4 I'd be worried about performance if I were you since you'll have to completely rewrite the renderer with managed code and DirectX 9 in mind. And that's just the renderer. You'd be doing a lot of major conversion work to use managed code with Torque.

Not that it couldn't be done. The Quake 2 engine was ported extremely successfully and relatively painlessly to .NET managed code.

It is possibly, I just don't know if it's feasible unless you are extremely well versed in C++, C#, and VB.NET. That way, you can know exactly what's happening with the C++ code so that it can be either converted to C# or VB.NET. I'd recommend moving to C++ managed code, though.

*Of course, converting the current TSE renderer to C++ managed code in .NET would probably be more feasible that vanilla Torque. After all, it currently targets DirectX 9 as its renderer with GL expandability planned in the future.

Edit: added TSE information.

#5 "The Quake 2 engine was ported extremely successfully and relatively painlessly to .NET managed code."

This was "just" a C++ wrapper around the C code, and recompiled with the managed C++ compiler. Not very much conversion was done there.

NB. managed C++ and J# are horrible hacks to the .NET runtime to get those languages running under the .NET VM. Horrible horrible horrible.

#6 Hmmm. I thought the initial project was a managed wrapper and the final implementation was a converted codebase. Come to think of it, that would have been overkill.

Looks like I picked the wrong day to stop taking crack.

#7 How is the Torque engine packaged? I mean does it use COM? Or does it all just get bundled into one big EXE

#8 David:
I've not looked at it recently - maybe someone *has* converted it to C# (eww)

VM-based langages are not the best tools to write games in, unless it is non-time critical server code.

#9 I don't think VM languages are even nearly as slow as people think they are these days. Java is fairly aggressive performance wise and .Net is pretty awesome for an 'early' Microsoft product.

Being a big fan of C# it would be nice to 'convert' the engine. But one of Torques strong points is it's cross platform. And that gets killed stone dead :( C++ to Managed C++ isn't particulary hard, it's just a LONG process.

Replacing TorqueScript with C# is viable though, and that would mean you could script in .Net features. Which may be the best compromise.

#10 C# only runs 5% slower than the same code in C++ by all current estimates. It takes longer to compile on load, but that is about it. TSE is going to need to get ported to managed code at some point, one way or another...in the near future? No. Eventually? Yeah. But I think its a rather large project to undertake right now, and not worth it.
Processor time is not what slows games down anymore...well, unless they are doing some very interesting AI or whatnot. With the advent of shaders, a large amount of processing is tossed onto the video card (if the programmer so chooses...), so a slowdown on the processor side in favor of more stability and not getting nasty warning messages about running unsafe programs in the next version of windows would make sense. The shader code runs the same either way...
Not to mention it takes half the time to write something in C# as it does in C++...I love C++, hate to lose it, but I think C# and its ilk will take over the average application in the future. But then...games are always behind on language switches, took the industry forever to go from predominantly C to C++. There are still holdouts. After all, C++ is 5% slower than C...
And the fact that C# is becoming cross platform in a way C++ can never be is quite useful as well. Regardless, this question obviously was not meant to start a holy war...the answer to the question is that this is a huge project, and not worth the effort except for educational purposes.

#11 FYI switching to C# makes it easier to be cross platform, not harder. At least for the future.

#12 I'ld be interested in knowing if this is in the Torque product development roadmap.

This would be a definite purchasing factor if it was especially since I'm currently evaluating it...

Have only "Members" replied to this question?... have any "Developers" from Torque yet replied.

#13 Not in the roadmap.

#14 Why do you think that VB would be more productive?

It may be is more productive but that depends on how you define productivity?

Lines of code per day done? Implementation details per day done? Classes per day implemented? Getting GUI design faster done?

Note that you cannot compare one programming language to another. In the end it all depends on your skills. Of course, some languages have more features or more powerfull features than others, so you pay the money and you got the choice. I know people that write productive code in VB and others in Java, others in C and again others in assembly.

Torque is written in C++, so the most effective way to deal with Torque is C++ - be it managed or not. I dont see a reason why to switch to VB. If you need a port to managed code you may use C++ .net.

#15 Well...that and the fact that unmanaged code will give warning messages and possibly not operate at all correctly on Longhorn. But then, when was the last time you were able to get an old DOS game working on a newer version of windows?

#16 I don't think that anyone who is seriously writing games is doing any work in anything but C++ for core engine code (not scripting). I'm sure there are some open-source wackos that are writing the "Supar next gearatreroun engin which r00ls al oters" in RUBY or something, but our roadmap leads to viable products, so we will, therefore, not be putting an ounce of energy into using anything but C++ until something better comes along.

#17 Am I missing something or did I just download a magic Torque3D demo with done in C# which in essence can be easily converted to VB.NET or did I simply just hit this thread a few years too late?