Jump to content

Happenstance

Members
  • Posts

    105
  • Joined

  • Last visited

Everything posted by Happenstance

  1. Sure. I'll try to get something uploaded later today. I also have a 'slim-310' branch on my github (https://github.com/chaigler/Torque3D/tree/slim-310) that's basically what I posted about earlier, except it only supports basic lighting. Edit: Uploaded to https://github.com/chaigler/Torque3D/tree/slim-310-al. This is 3.10 with many of the bug fixes from 4.0 ported over. SDL + OpenGL + OpenAL + Advanced Lighting only. I've left the commit history mostly intact so hopefully it'll give you some ideas on how to make your own 'Franken engine'. I tend to tailor the engine to whatever project I'm working on. My current game is a noire murder mystery so it relies on lighting and shadows especially, which is something that basic lighting struggles with. It didn't make sense for me to leave it in when the game experience would be so drastically different between the lighting models. I'd leave basic lighting in (and probably rip out advanced lighting!) if I was making something that didn't make heavy use of light & shadow. As for the new templates, I really like them. They're cleaner and smaller than the old templates, and I like that they're using T2D's module system which I'm also familiar with. I haven't run into any issues using them so far but I build off of BlankGame or spectatorGameplay so I'm not sure what'll find if you try to use the converted FPS template.
  2. It's an interesting time to start something new with T3D because as you said, 4.0 is going to change how we use the engine in some really significant ways but it's still months away so we're stuck in this strange limbo between versions. My recommendation, assuming you're wanting to start a project now, would be to use 3.10 but pull in some of the changes that have already made it to the development branch. For my current game I've built my own 'Franken engine' based off of 3.10 but I'm using the new templates and pulled in all of the bug fixes in the development branch (as well as did some major streamlining - got rid of unused libs, pulled out basic lighting, removed all DX support/SDK requirements, etc.). I've now got a clean base to start from and I can more easily keep up with the development branch if needed.
  3. T3D has support for Physx and Bullet (as well as a custom rigidbody solver that dates back to the early 2000s) but there's no 'tick-a-box' option in the engine that enables BeamNG style physics. In fact, BeamNG is really just a soft body middleware solution that was ported to T3D for demonstration purposes and there was a lot of custom code involved to make that happen. Godot is great for 2D games but I wouldn't use 2.1.x for any serious 3D project. 3.0 represents a big leap forward in terms of 3D capability but there's still many bugs to fix and workflow issues to iron out before I'd consider using it (we're talking months away from a truly production-ready release, in my opinion). Godot is on par with T3D in terms of physics which means you're going to need to dig into the source code of either engine to make what you want.
  4. Binding a move trigger ($mvTriggerCount0, etc.) to the mousewheel zaxis seems to be bugged. Scrolling the mouse wheel causes the trigger to be constantly set (even after restarting a mission) which in turn spams whatever function it's bound to. Could someone test this out and confirm what I'm seeing? moveMap.bind(mouse, zaxis, bunnyHop); function bunnyHop(%val) { $mvTriggerCount2++; }
  5. I whipped up a quick addon for Blender that will export all meshes in a scene as individually named .dae files. Not sure if this is useful for anyone else. :] https://github.com/chaigler/dae_batch_exporter
  6. @JeffR - Excellent! And not to add another thing to the pile but I just updated VS2017 tonight and compilation broke again thanks to the template issue. MS bumped the version number (MSC_VER = 1912 now) so the hack that targeted 1910 stopped working. Quick fix, of course, but just another thing to deal with.
  7. Any reason to continue linking these libs? libmng provides support for loading MNGs (animated PNGs) but MNG is essentially a dead format at this point and T3D never fully supported it anyway. The engine is also linking against a very old version of the lib (from 2007 I think?) which isn't good. lungif is intended for loading GIFs but again, the engine is linking against a very old version of the library and doesn't really support animated GIFs anyway.
  8. Bumping this because I think it deserves some discussion. Bloodknight's correct, imo. Right now 3.10, the last 'stable' version, fails to compile in VS2017 (which is also the only version of VS easily found online) and the development branch is such a moving target that I wouldn't recommend using it for any serious project. I'm not sure what the timetable is for 4.0 but I think there needs to be some consideration given towards releasing a 3.11 or 'maintenance' update to bring the current stable build closer to the development branch. I think we're asking an awful lot for new users (or any users, really) to cherry pick and backport fixes from the current development branch into their own master (stable) copies of 3.10 just to get it compiling (in addition to all of the other stuff that goes into setting up T3D).
  9. Godot has a lot going for it but 3.0 is still a ways out from being "production ready" in my opinion. In another 6-8 months I expect 3.0 will be stable enough to use and should be a viable alternative to Unity for 3D games. I'm sticking with T3D, though. I like how 4.0 is shaping up - dropping DX9, (finally) pushing the entity component stuff, streamlining the templates, etc. are big steps forward.
  10. Just waiting on 4.0 here. It feels like a bad time to start something new with T3D because it's such a moving target right now.
  11. Typically the two renderable classes you'll work with are TSStatic (a lightweight static mesh class with basic support for animations, collision, etc.) and StaticShape (like TSStatic but with much more functionality, including datablock support). TSStatic is usually used for static scenery objects like buildings, etc. StaticShape tends to be used for gameplay objects like CTF flags, doors, etc. There are also examples in the engine that explain how to create your own class that renders a mesh and uses a datablock. See the renderMesh, renderObject, and renderShape.cpp/h files for more on those.
  12. The point of ConsoleObject is just to define some basic functionality required to interface with the console/scripting system. SimObject inherits from ConsoleObject but adds additional required functionality. simObject.h explains this is more detail. I think it used to be possible (waay back in the early TGE days) to instantiate a ConsoleObject directly but that's no longer the case. If you look at line 869 in compiledEval.cpp you'll see why you get an error. As far as memory management, TorqueScript isn't garbage collected and there's no concept of new'd objects going out of scope, so it's possible to leak memory if you're not careful. Few examples to demonstrate: // $myObj is a global var that stores the 'SimId' mapped to MyFirstObject() // I can reference $myObj from any script $myObj = new MyFirstObject(); // But if I remap $myObj to something else... $myObj = "Oh no!"; // Then I've essentially created a memory leak: MyFirstObject() is still exists but I have no reference to it function CreateObject() { // %myObj is a local var that stores the 'SimId' mapped to MyFirstObject() // The %myObj variable will be destroyed when the function goes out of scope, but MyFirstObject() will still exist... %myObj = new MyFirstObject(); } function CreateObject() { // %myObj is a local var that stores the 'SimId' mapped to MyFirstObject() // The %myObj var will be destroyed when the function goes out of scope, but MyFirstObject() will still exist... // However, I've also given MyFirstObject() a name this time: 'MyObject' that I can reference anywhere - memory leak averted! %myObj = new MyFirstObject(MyObject); %myObj.doStuff(); MyObject.doStuff(); } %myObj.doStuff(); // will cause a console error - %myObj not found MyObject.doStuff(); // no error
  13. Your code looks fine as far as I can tell but inheriting from SimObject (or even lower, to SceneObject or GameBase) is typically what you want to do. The only classes in the engine that inherit from ConsoleObject are SimObject and NetEvent, neither of which are meant to be instantiated directly from script. This was written for an older version of Torque but is still (mostly) relevant and might be of use to you: Class Hierarchy - ConsoleObject
  14. Posting this here instead of creating a new issue on github because I'm not exactly sure why this happens (or rather, why it doesn't happen in a stock build of T3D). In my build (based off of the latest dev branch with these changes to remove Basic Lighting) I get an assert when exiting the engine: The problem seems to be caused by ShadowMapManager being destroyed before AdvancedLightManager. The callstack looks something like this: // This causes ShadowMapManager's MODULE_SHUTDOWN macro to run which calls ShadowMapManager::deleteSingleton(). EngineModuleManager::shutdownSystem() .. .. // This calls SHADOWMGR->deactivate(). SHADOWMGR is simply a #define pointing to, you guessed it, ShadowMapManager's singleton instance. Assert time! AdvancedLightManager::deactivate() I can fix this in my build by adding the following to ShadowMapManager's MODULE_BEGIN definition: MODULE_SHUTDOWN_AFTER(Scene) This delays the shutdown of ShadowMapManager until the SceneManager has been destroyed which ensures AdvancedLightManager has also been destroyed. What I can't figure out is why this doesn't happen in stock T3D. Removing Basic Lighting seems to be related to this but I have no idea why.
  15. The fix for this was supposed to be in the VS2017 15.3 release but the preview version is still tripping up over the 'MaybeSelfEnabled' template in engineFunctions.h. Anyone know of a workaround?
  16. What's the status of the OpenGL layer on Windows? Would it be possible to rip out the DirectX layer (D3D9, 11, and XAudio) and just have a build that uses OpenGL and OpenAL on Windows? Am I correct in assuming the SDK wouldn't be required in that case?
  17. That's great. Thanks! I'm going to look over everything this week in more detail but the quick glance I had at the template code has me excited for 4.0.
  18. @JeffR - I'm in the same boat as HeadClot so I appreciate the overview of all of the improvements in 3.10 & 4.0. I'd like to start a new project with T3D using 3.10 but I'm concerned the transition to 4.0 will be a hassle. Is the new base template (the one that's making use of the module & asset system) on git somewhere? I'd like to use 3.10 now but with the new template so I have at least some head start on the transition.
  19. Apologies for bumping this but I have the same questions as Mud-H. I'm still fairly new to git, so if someone with more experience could chime in I'd appreciate it. Let's say I have a project and I want to use the the latest 'master' release of T3D (3.6.3). I'm going to need to modify the engine source for this project but I -don't- want those changes being made public. To do the above, I need to fork from GarageGames/Torque3D and add an 'upstream' link back to GarageGames/Torque3D. I'll make any of my changes to my local (on hard drive) copy of the engine but -won't- push those changes out to my fork at github.com. Am I correct on the basics of git usage? Let's say I want to update my engine to 3.7 when it's released. How should I handle that? What if I want to bring in changes from another user's fork?
×
×
  • Create New...