Jump to content


  • Posts

  • Joined

  • Last visited

Monkeychops's Achievements

  1. I think a lot of people kind of miss the point about the scripting language... it's not so much that torquescript sucks, or that it's hard to learn. There's a number of much bigger issues: * Tooling - Sure you can argue syntax hilighting isn't that hard to add to most IDEs, but tooling goes waaaay beyond that. The tooling support for C# for example has code completion, snippets, refactoring, code navigation, advanced debugging, profiling etc. * Libraries - Say you're writing a game server and you want to store your data in some new-fangled cloud database or other. Or you want to integrate with a hot new game streaming service. There's going to be a C# library for that you can drop in and go. If you're using Torquescript you're probably going to have to write all that from scratch.. probably in c++ (yep, you're going to spend days/weeks in c++ hell worrying about closing connections and releasing resources, even if you only signed up for some high level game scripting). You shouldn't need to burn valuable game dev time implementing/porting stuff that already exists. * Performance - Torquescript isn't too slow for game scripting, but most of its biggest fans would still normally recommend writing high performance bits in C++. With a fast modern .NET runtime the performance should be good enough that you don't need to leave managed code or mess around going between different programming languages to get the job done. * Familiarity - Ok, you can learn Torquescript fairly easily. But if does have its quirks... and if you already know C# its one less thing you need to learn coming in to a new engine. * Productivity - C# is a much more feature-rich language with much neater and more productive ways of doing things. It also has tons of official libraries for working with data, collections, system interactions etc. * Maintainability - C# makes it very easy to structure and organise your code, and to find the bits you are interested in when needed. There are well documented and tried and tested best practices for code structure that make working with large projects much easier. * Security - Ok, so .NET isn't the most secure language and can be decompiled, but decent obfuscators exist that do a reasonable job of preventing casual snooping. Torquescript projects pretty much just lay their scripts bare for anyone to fiddle with or copy - and if you want to obfuscate it, you're going to have to write your own obfuscator, because again, its a niche language. Sure, other engines have their own quirky languages too... but as you also noted, most of those have died out now in favour of mainstream high-level languages. When a lot of older engines were made, being able to embed mainstream languages wasn't really a thing because the open source runtimes didn't exist. Now that they do, people want to use them.
  2. I think there's a few major stumbling blocks at the moment: 1) People looking in see the engine as outdated - that should be fixed with the new PBR release and the GI that's being worked on. 2) Not many people understand the engine - that should be helped with the new cleanup work and the new modular approach and ECS. 3) Not many people know or want to use TorqueScript I think #3 is a big problem. It perpetuates because those that know T3D and work with it understand torquescript well enough and don't see it as a problem. Meanwhile the rest of the world peeks in and sees a decent but outdated engine with a weird scripting language for which no modern tooling exists and moves on. I'm really looking forward to seeing the new release with PBR and cleaned up modular structure and I think that will go a long way to sparking interest in the engine, but I really think for the engine to have a long term future it will need to have official bindings for a more popular language like C#. Unless or until that happens, its going to remain a niche engine - that's the primary reason it died out under GG and hasn't picked up much traction since going open source either.
  3. That's great if you know the engine inside out... but most people will just load in a terrain texture from an asset library or whatever and it will look rubbish, and then they think the engine is crappy. Plus, if we have a dozen or so different terrain textures to use/test, it is a pain to have to load up a photo editor and tweak every one... and by how much should we desaturate it to get it to look the same as it does in the editor? Then we want to edit the texture and add some flowers... we need to desaturate it all again to save it out. And say we only have the desaturated version that someone else has saved already - we need to edit it in the desaturated form and guess how its going to look when saturated. You need to be able to visualize all that in your head and can't accurately pick the shade you're going for. The whole reason PBR workflow has got so popular these days is that you can be pretty sure what it looks like when you design it is how it will look in the engine. That's kinda ruined if you have to then guess at how much to desaturate your terrain textures by to get the look you're going for in the engine. Personally I think if it can be done in the engine and make the workflow easier, why not? It will help people make better looking stuff out of the box. And when making a whole game with just 1 or 2 people every little productivity boost helps.
  4. I personally don't think you should have to edit the images in photoshop in order to get good results, desaturating some parts and not others etc. Aside from the extra work and slower iteration when trying out different combinations of textures, it also involves a ton of guessing and experimentation. Why can't we just say that if there's a detail texture, we use that colour and ignore the base altogether? Or mix the base in but never go higher than the sum of the both.
  5. I quite like the CMake > VS workflow with the tooling etc. Installing VS 2017 is nowhere near as painful as previous versions, they have made the installer a lot more lightweight and faster, and it is easy to repair individual components if something goes wrong. The only problem is, the compiler seems to be more strict. I think if we fix whatever it doesn't like, it should work well enough in future. Only trouble is, I don't really get what is wrong or how to fix it. :shock:
  6. I'm trying to build the dev branch (https://github.com/GarageGames/Torque3D/tree/development) with VS 2017 final release and the latest CMake 3.8.2. I'm using the "Visual Studio 15 2017 Win64" generator with a clean BaseGame template. It was working before when I used the VS 2015 generator but it will not let me do that now since I broke my VS 2015 installation. Error looks like this:
  7. I get a ton of errors like this when I try to use the vs2017 compiler: error C2938: 'MaybeSelfEnabled' : Failed to specialize alias template
  8. Has anyone managed to get T3D to build with VS2017? I foolishly broke my VS 2015 because I ran out of disk space and it seems the VS 2017 compiler has issues with the code.
  9. Seems to run for me, although not sure how to do much except start the blank scene. This is really cool - I have to say I've kinda given up on Torque because TS is too quirky and not a lot of open source libraries and such out there for it.. but C# would be a whole new story.
  10. Microsoft stole your ".cs" extension, but you should also be aware they stole your ".ts" proposal as well with "Typescript", and "tsc" is the typescript compiler :D i would suggest .t3d as the safest extension that isn't like to clash.
  11. Personally I think the community is too small to fragment. Since the old forum is broken and full of spam, outdated info and generally hard to use and hard to find anything, it makes most sense to kill it off altogether. As I said though, as long as it's winning in the search rankings and all the links around the web point to it, it's going to be a bit dumb to close it completely. I think the best thing would be for the SC to petition GG to redirect it to here. Meanwhile, why not just post a thread saying the community moved and keep bumping it every day? The worst case someone from GG will ban you, but since they don't even log in to delete the spam any more, I doubt they will even notice. If they do notice, then at least it draws their attention to the issues and they might take a stance one way or the other. Also, for IndieDB, why not submit a new listing for "Torque3D MIT" - if the mods question why there are 2, tell them the old one is no longer maintained they may even delete it :)
  12. I think this forum is way better, and it makes sense to have a forum with new information and not all the old, irrelevant stuff. The old forum really doesn't make it clear when you search that what you've found no longer applies. The GG forum still ranks top in the search for Torque3D though so people will keep going there. What would help is to update all the backlinks around the web. For a start, a big link to this site at the top of the readme on https://github.com/GarageGames/Torque3D would be a big help. The first 2 links in the body go to GG still. Then there's wikipedia http://en.wikipedia.org/wiki/Torque_(game_engine) - still going to GG. Why not submit an edit to link back here? Then YouTube - lots of people search for 3d engines and stuff on youtube because you tend to be able to find nice demos of engines and compare things well there. Most of the Torque3d videos are a bit out of date and link back to the GG site. Why not upload some of the awesome new tech and tag with things like "[OpenGL] [DirectX 11] [Deferred Shading] [Physically based rendering] Torque3d" when people are doing work in those areas? I often search for stuff like that on YouTube when I am researching, and I bet most of you do too? And... last but not least... http://www.indiedb.com/engines/torque-3d has the GG site listed as the official page. I think if those things can be updated, the GG site will eventually drop out and everyone will come here. Plus, when the stuff like PBR hits the tubes, this forum will really take off, because there's no open source engine that does it yet.
  • Create New...