Our community blogs

1. 

   Torque 3D

   A group blog by DEVGRU in Work Blogs

   • 8
     entries
   • 18
     comments
   • 65747
     views

   Recent Entries

   • Rounding the Bend
   • First update of 2025!
   • End of March-ish Workblog 2023
   • Workblog Nov 2022
   • Workblog - Aug 2021

   

   Latest Entry
   

   Rounding the Bend

   By JeffR, September 1

   Greetings! 
   It’s that time again, where I summarize up a bunch of work that’s been done and get the details laid out in a reasonably digestible way for you all to enjoy! Without further ado, here we goooo.

   
   What’s Been Done So Far?
   Since the last Workblog, or werkblerg, or wrgglglbnblglb depending on how much coffee you’ve had yet today, we’ve rolled in almost 160 PRs.
   Not quite as monstrous a list as last time, but it’s still pretty substantial.

   A good number of them were things on the TODOs from the last blog, so they may sound familiar, but a lot of them were bugfixes or QoL improvements that came up with feedback, reports, or just running into stuff when actually using the engine to make games.

   So, what do we have?

   
   General Fixes and Improvements
   This is where the vast bulk of the PRs were. Which makes sense, since I mentioned before that a lot of them were fixes and improvements(neat how that works out).
   So rather than plonking down a bullet point list of all 75 PRs, let me just pick through some of the highlights:

   
   Memory Leaks
   As with any piece of software, there is always a possibility or looming spectre of memory leaks. And while Torque’s had it’s fair share we’ve always made it a priority to chase them down.
   What we ended up spotting is that while there’d been prior cases of fairly obvious memory leaks that had been easy to fix, it was noticed that there was a much slower yet undeniable memory leak that had been an issue for some time.
   Letting a game run for an hour or two yielded gigabytes of memory consumption, so, you know, obviously that was bad.
   It took a lot of work and Az and Marauder doing some deep digging, but through multiple tweaks and fixes  and making it easier to track and chase down memory leaks with better integrated reports with any and every bit of memory the engine allocates and releases, we got everything playing significantly more memory stable
   Especially important for anyone trying to do long running games or servers.

   Path and Vehicle/Rigid Object tweaks
   A mix of small but important fixes across the board for these classes, such as fixing stabilizer behavior for hover vehicles when going over ground planes, shoring up some performance tweaks for rigid shapes(which also impacts vehicles), optimizations to networking of rigids and early outing on things like if an impulse is too small to mathematically matter, etc.

   For paths, there was tweaks to how the object snapping works(so objects trying to ride on a pathshape can still do normal things like jump) more reliably, as well as adjustments to workflow with them so they’re easier to use, like more consistent load behavior - especially when generating paths with gamelogic - and being able to copy/paste paths and shapes and having them behave more predictably.

   Networking Tweaks
   A few classes such as TSStatic got some tweaks to improve networking/ghosting efficiency. Nothing major this side, but it’s always good to refine how much we have to pipe across the network to save packet space for actual important gameplay stuff

   Subscene Stuff
   Az improved the logic for testing if a subscene could be triggered to load(since sometimes you’d want to condition a subscene loading based on gameplay logic or triggesr) to be more consistent/reliable.

   Similarly, there was just a bunch of small other tweaks like improving the workflow when creating a level asset and being able to flag it as a subscene immediately, having better in-place workflows for creating subscenes while working on a level, fixed an issue where MeshRoads would save/load into subscenes weirdly, etc.

   Nothing Earth-shattering, but it should just generally make subscenes easier to work with.

   Spawning
   Building off the work with the spawn chain mentioned in the prior blog, we did some cleanups and tweaks to how the callbacks and error reporting if something goes wrong work based on more people testing it and giving feedback.

   This means that it should be easier to drop stuff in and have it Just Work, as well as modules being easier and more reliable in how and when they’ll spawn stuff.

   Scripting
   Re-added the ability to kick off compileAll in order to forcefully compile everything to a dso. This is important because one of the features still on the TODO for the Project Manager is the ability to export a game build, which would include functionality like being able to compile scripts to binary files, or remove art source files and so on.

   Also added some unit tests for scripts as part of the build pipeline to better catch any regressions in the future next time we work on the script/console back-end.
   There was also some pruning done of old/redundant methods in a few spots which should help keep things clearer.

   Beyond that, shifted a bunch of object fields to utilize validators and range types to keep sane values on things. No more accidentally setting your gravity multiplier to a hundred billion and then wondering why the player can’t move!

   Jokes aside, it should generally just make it harder to have values go completely insane, as well as generally being better at straight-up plugging bad data into things and causing problems.

   Nothing major front-end wise, but should generally help stability overall.

   Recast overhaul
   What originally started as a “Oh, Navmesh preview renders funky-like on OpenGL” turned into a bit of a quagmire due to how NavMesh used to handle packing and presenting debugging data.

   Mar did a big overhaul to better use the library ‘as it was intended’ as well as packing in a bunch of additional utility features to help make working with it a little easier now, and opening up the opinion for new features in the future. 

   Plus, it’s always nice to be able to tell an AI to go a place and he actually manages to get there!

   GUI
   Gui stuff saw a smaller but important set of changes and fixes as well.

   The list of PRs for that includes:

   • Fix escape menu keybind not working (Areloch).
   • fix PopupMenu::checkItem filter (Azaezel). 
   • Gametsctrl mouserefactor (Olathuss). 
   • fix another potential crash with firstresponder code (Azaezel). 
   • Enables onMouseMove for scripting on GameTSCtrl (Olathuss). 
   • Better guiClockCtrl pause tracking and module callback integration with PlayGUI (Azaezel).
   • expand playgui callbacks to let game modes inject element layers (Azaezel).
   • game mode filterfix (Azaezel). 
   • setFirstResponder safeties (Azaezel).
   • guiClockHud augs (Azaezel).
   • Adjust OpenAL device listing query for reliability (Areloch).
   • Close Menu Implemented (Olathuss).

   Nothing absolutely earth shattering, but a lot of fixes and quality of life improvements. Stuff like the the fixes for the mouse handling for GameTSCtrl improves consistency, and the expanded callbacks and game mode filtering makes working with and interoping with gamemodes a lot easier.

   Being able to just drop stuff in and run with it in a more modular way goes a long way to improve iteration time, especially as we keep expanding the list of modules available for people to snag and use.

   
   Editor
   The big thrust of focus for 4.1 at it’s core was work on the editor suite, so predictably there was a lot done here.
   The highlights list includes:

   Material Editor Update/Inspector-ify
   The big one would be converting up the special-snowflake ad-hoc Material Editor, which looked like this:
   
   And shifting it to utilize the regular inspector class, so now it looks like this:
   
   Admittedly, not a gigantic space-magic powered visual change, but the backend code is much simpler and streamlined, it’s *standardized* to everything else that already uses the inspector like the normal world editor, and it means that if you add a new field or property to the material class, it Just Works and will appear in the MatEd for changing without having to hand-add it yourself.

   It also was an opportunity to pop the MaterialEditor out from being packed in with the main EditorGUI, so you can now edit the MaterialEditor with the GuiEditor.
   The other editors will follow suit from this as we go now that it’s shown that yeah, it’s pretty easy to do.

   In addition to the MatEd getting updated, the Cubemap editor was shifted over to it’s own standalone thing instead of piggybacking off the MatEd, and now there’s actually a full-fledged Composite Image Editor!
   

   Which basically lets you easily take a material with Ambient Occlusion, Roughness and Metalness maps, and quickly bake it down into a ORM Composite map for efficient use.
   Or technically any kind of composite texture, but that’s the main usage.
   You can also open it up via the right-click context menu in the Asset Browser on ImageAssets, so either direction works!

   Adding tab cycling between inspector sub-elements
   This is just a nice quality of life thing, but it means you can quickly hit tab to run through sub elements in the inspectors which should improve workflow speed

   Visibility Modes dropdown is an Extensible Menu
   This is likewise a QoL thing and ease of maintenance more than anything, but it makes it easy for expanding via stuff added in modules.
   For example, there’s the normal list:
   
   And if you’re using the Action-Adventure Kit module, it has some additional visibility modes:
   

   As you can see, we've injected in an entry for Showing Camera/Player blockers which are additional special volumes added with the AAK. 

   This makes expanding Viz stuff for modules or custom tooling way easier and thus making it much more actually useful.

   Ability to make GameModes or New MaterialAssets in Asset Browser
   This rectified an issue where neither of these types could be just made brand new via the AB itself, so now you can just make a new one like so:
   

   And it just creates it as expected for any other type and you can get cracking at the actual content your game needs without disrupting your flow or needing to leave the editor to  make them by hand in script.

   
   Prototyping UI moved to tools
   This is mostly just a standardization/cleanliness thing, but the Prototyping UI Az drafted up has it’s proper home in tools now.
   If you haven’t played with it yet, it’s a handy little shindig that lets you very quickly slap together objects and script functions(hence it’s name!)
   

   
   Additional Terrain Tools
   Az put in a little bit of additional elbow grease to finish out some work to add some nifty new brush modes to the terrain editor to facilitate stuff like thermal and erosion, as well as the ability to copy and paste sections:
   

    

   Color Picker Refactor
   Marauder overhauled the color picker to rectify a lot of weird under the hood oddities and now everything should behave far more consistently.
   

   Mind, that isn’t everything, and all told there were almost 30 PRs just for editor improvements, additions and fixes.

   
   Rendering
   Rendering saw a very similar number of PRs that largely targeted stability improvements. From fixing memory leaks to erroneous rendering behavior on the GL side of things, fixing wetness, mipmap handling, adjustments to PBR rendering to fit more correctly to model and some IBL/Probe issues.

   It was a lot of small but very important improvements.
   After all, no one wants their game to look like this:
   

   
   Platform/System And Libraries
   This largely was a small but straightforward list of changes, by which I mean it pretty much was mostly updating various libraries.
   Stuff like SDL, tinyXML2, OpenAL, etc.

   There was also improvements for logic to find said libraries on linux so our friends on that side of the OS divide don’t have to fret as much if it’ll get confused about which version of a library like SDL it should use.

   Also, also, there was some minor cleanliness changes like moving the libCurl stuff to resources as a module rather than trying to have that packed into the main engine build if most users aren’t likely to utilize it.

   
   Assets
   On the asset side, the main focus was retooling how Image and Shape assets handle their memory and references, as well as their loading and reloading logic.
   The end goal is to cut down on how much redundant handles we have everywhere, while being able to reliably manage and detect when Assets are loaded, pending, changed or reloading so actual game classes, like Players or TSStatics can react appropriately.

   This lets us do stuff like properly having Shapebase-based classes react when their shape is changed for hot reloading, or when an image is changed and needs to be reloaded and making the gui classes react appropriately.

   Beyond that, more cleanup and safeties in a bunch of spots to make the whole thing more robust.

   
   So, What’s Left?
   For the big todos:

   Finishing converting remaining ‘Special-Snowflake Editors’ to standard inspector-based stuff.
   It’s largely self-explanatory, but a few remaining editor UIs like the ParticleEditor utilize completely custom, ad-hoc GUis for their editors and standardizing those over to use inspectors like most everything else will make everything feel more consistent, be easier to maintain, and be easier to expand.

   Rework IBL/Probe memory management
   While the current setup works fine, it’s more that it works ‘fine’.
   Az discovered via his Warren test map that when you really start throwing a lot of probes into a mission you can pretty well strangle out the render API’s memory allocations in certain circumstances.

   The current method is ‘fine’ if you have a fairly small map, but once you start getting bigger and/or you need a lot of probes to wrangle lighting/reflections for indoor areas, you can brush up to that limit quickly.
   And it turns out GPUs are not a fan of having their VRAM mugged for spare bytes

   So, I gotta rework how the internal arrays handle things.
   The frontend shouldn’t change at all, but the inner rendering logic’ll change to properly handle sublists of probes to allocate and deallocate as demand changes.

   Only actually allocating cubemaps for probes close to the camera will fix the issue of running into those memory allocation limits without meaningfully changing how the end user sees the IBL rendering happen.

   
   More Misc Fixes and Improvements
   We keep getting more and more feedback and bug reports as people use and beat up on the build, which is awesome and lets us really grind down on remaining issues that get in the way of usage.

   Stuff like funkiness with the Options Menu, to jank with how the level selection screen works, or other small workflow and QoL issues in the editors.
   All that kinda thing we’ll keep polishing as they get reported to make 4.1 as refined and smooth to use as is physically possible.

   libGit and it’s usage in Torque3D
   This isn’t really a make-or-break issue, but ties into the above about various pain points and user feedback.
   The new Project Manager generally has been well received, but there’s been an ongoing issue with some funkiness about how it utilizes the commandline calls to kick off git for downloading engine builds or modules.

   It works, but inexplicably it can run into issues sometimes, and because it’s routing blind through the commandline error reporting is basically non-existent. Which is always frustrating for everyone involved if no one knows what actually went wrong.

   Beyond that, people have expressed annoyance that it feels like there’s still a lot of hurdles for grabbing modules and being able to just… ‘go’.
   As-is the workflow is to grab the engine, then go to the resources github page, download whatever modules, toss them into your project, and then you can start playing with things.
   If you’re using the PM there’s a few less steps because it can present you module options more directly, but it’s still ‘external’ to the editor/project you’re working on.
   So we’re going to look at being able to build libGit into normal T3D as well and let you snag resources directly from the Asset Browser.

   While the Project Manager will still do it, as well as let you… well, Manage Your Projects, such as exporting a game-ready build, etc, a user would be able to in theory grab a binary build of Torque, launch into the editor, and start snagging modules that are instantly ready to go right there, without needing to leave the editor.
   If that approach shakes out, it means the hurdles and speed bumps for prototyping or bringing in content for your project would go down massively.
   You could be like “Dang I could really use some trees right now” to clicking on a Trees module in the AB, it downloading via git, and now having trees to paint into your map without even needing to leave the editor.

   Conveniently, Az has put in a lot of work getting the library module ready to go, so I can pretty much start testing out said above integrations immediately, so figuring out how to use and abuse it won’t have long of a wait.

   It’s a promising prospect, and something we’re gunna take a good look at testing out, because really, no one ENJOYS fiddly work. People want to be able to work on their actual games. And workflow improvements like that would go a long way towards that end goal.

   So That’s Everything Then?
   More or less, yeah.
   Obviously there’s bits and bobs of fine details, but that’s the brunt of it.

   A number of big reworks and fixup passes caused quite a bit of a grind there, but ultimately the engine is in better shape for it. 
   The todo list is very short at this point if you consider “Fixing issues as they get reported” as a single main-line category, so I’m hoping to get our first 4.1 Release Candidate out in the next month or so.
   So keep your eyes out for that because we’ll definitely want people jumping in there and really giving it a workout so we can polish things up to a mirror shine!

   And, as always, if you want to help pitch in to cover stuff like server/hosting costs and the like, feel free to swing over to the patreon:
   
   You even get a nifty role in the discord now if you support it!

   See you there!
   -JeffR

   • Read more...
   • 4 comments
2. 

   Torque 2D

   A group blog by DEVGRU in Work Blogs

   • 1
     entry
   • 0
     comments
   • 63071
     views

   Recent Entries

   • Torque2D: Rocket Edition Road Map

   

   Latest Entry
   

   Torque2D: Rocket Edition Road Map

   By greenfire27, August 10, 2021

   Early Access 1

   Today I've released what was held in the Development Branch into the Master as Torque2D 4.0, the Rocket Edition, Early Access 1. That long rambling name deserves some explanation. First, the we needed to get this code out. The big change is the Gui System update which I actually started in 2018. Most of the Gui System has been updated by now and it's been battle tested by the construction of the Asset Manager.

   Which brings me to the second reason for the release, namely, the Asset Manager. This newly minted manager is immensely useful for seeing all the assets and building particle effects. Unfortunately, the Asset Manager is still rough around the edges so that's why we're doing an Early Access version.

   If you're starting a game, or just want to play around in 2D, you should really be using 4.0 since it has breaking changes from 3.5. Plus, I would greatly appreciate feedback on the Asset Manager. The "Rocket Edition" is just a nice text name for 4.x which I'll run with until we reach 5.x. Mostly it's a marketing theme.

   So what's next for the engine? Let's review the plan.

   Rocket Edition Road Map

   Disclaimer: This is a map, not the Bible. I will likely make changes as we go. Also there are no dates by design. These things happen as we have time.

   • Early Access 2 - Remaining Gui System changes and Improvements to the Asset Manger such as a visual animation editor and support for named image frames.
   • Early Access 3 - Project Manager to allow the copying of modules from the Module Library and a couple of modules for said library.
   • Early Access 4 - New game demo based on the Rocket Edition, Perlin Noise Function, and Complex Colors on Tile Maps.
   • Version 4.0 - Update to the Toybox to better match the Rocket Edition.
   • Version 4.1 - The Gui Editor! (We have started this as a toy. Go thank Marauder2k9!)
   • Version 4.2 - The Scene Editor! (This has also been started as a toy, again by Marauder.)
   • Version 4.3 - Empty for now...

   That's the currently plan. I for one, am excited to see these things completed, but there's a lot of work to be done. If you're interested in helping, please reach out to me through Discord.

   Carry on, citizens! 

   • Read more...
   • 0 comments