[Steve_Yorkshire]

Noice AK!
*thumbs up matey*

[JeffR]

Hey everyone!

Time for another regularly scheduled update.

As usual, quite a bit of work's been done in various places.

Firstly, I took some time to bring some of the work I'd been doing with improving the convex editor out of the freezer and got to hammering on that again. I'd gotten it to where you could edit the UV's and assign material for each individual surface, but it was obviously still off from a fully fledged CSG tool like I'd preferred.

Fact is, sometimes the old BSP style editing is better for fast blocking out of levels, or levels that don't need a ton of complexity.

So I spent a bit of time getting it ported up and working on a carve feature. You can see it partially working in the screens here:





End goal would be to be a modern stand-in for ye olde BSP-style CSG editors.

While improving that, I also went ahead and hooked in another tidbit I thought was useful, namely, having the convex editor allow direct manipulation and editing of zone, portal, occlusion and trigger volumes.

They're set up already to be able to be converted from their class, to convex shapes, and then back again for editing, but it's done via right clicking on the object in the scene tree, picking the convex shape conversion, editing, and then doing it back.

So basically, way more steps than needed.

Now:






It automatically converts any appropriate object type into a convex by creating a proxy convex shape, and then when the editor is closed, the proxy is processed and sets the geometry of the object again in a nice, smooth, automagic action.

The carving and surface editing are still a ways off, but the automagic conversion function is pretty close to being considered final. It may or may not make it into 3.10.

Other R&D work has been starting to feeler around an implementation of Intel's Masked Occlusion Culling library, which would implement a really fast software occlusion rasterizer, which has the potential to cut back on a lot of overdraw of objects that SHOULD be occluded, which will help performance.

Beyond that, if you hadn't spotted it in the PR list, or on my twitter, we got OSX support merged on it, thanks to the incredible efforts by Timmy, Az, JeffH and Glenn. They put some macs into a frankly brutal chokehold and it tapped out and submitted.

Piggybacking off of that, Az found out that xcode actually has some really nice tools for cleaning up code, such as static analysis, and it uses clang, which tends to be a lot more strict than, say MSVC's compiler, even on Level 4 warnings. So he pushed a blast of PRs to help clean up some warn-generating bits of code, such stuff like unused vars and formatting bits.

Spurred by that, I tried getting VS2015's clang add-on working, and while it's kinda-sorta there, I get one error at the very end that blocks a total compile. But it compiles enough to generate errors and warns which is useful for code cleanup, so hey!

If you wanted to try it out yourself, here's what you do: First, get the add on(what a surprise)
You can find some info on the initial setup of it here: https://blogs.msdn.microsoft.com/vcblog ... -update-1/

From there, you generate your project as normal - as because it's not an official compiler mode, cmake doesn't play nice with it yet.

Then, there's a few settings you need to change to get it compiling(mostly) in clang mode.

Here's what to change:
1) Open the project properties, and go into the General Settings. Change the "Platform Toolset" property to "Clang with Microsoft Codegen".
2) Hit apply
3) Under C/C++ > General, Change the" Debug Information Format" to "Full Debug Info"
4) Change the "Warn Level" to "Warn All"
5) Ensure the "Object File Name" property is "$(IntDir)%(filename).obj"
6) Under C/C++ > Preprocessor, edit the preprocessors to remove the TORQUE_TESTS_ENABLED entry.
7) Under C/C++ > Code Generation, change the "C++ Exceptions" to be "Yes"

Then do a rebuild. As said, it throws a relatively non-descript error for me right at the very end, but I do want to make sure it all works in the future, as being able to at least run the code through clang can help ensure clean, stable code.

And likewise in pursuing such code, I found a few utilities to help with cleanup and format consistency. Namely, one that processes a file or files to be fully reformatted, so I plan to do a blast of PRs once 3.10 is out the door that go through all the files in the engine and ensure they are formatted to our guidelines.
And I also found a tool that iterates over every file in the engine and tests if each include in them are actually needed or not and removes it if not.

I had run a test of it the other day and it found almost 3000 includes that were not necessary. So I'll do a blast of PRs to clean those up as well, which hopefully will help with compile times.

We also recently switched the default audio to be OpenAL-Soft, as that's not butts-old, and plays a lot nicer with all the platforms. Thanks goes to timmy for rocking that one out. It'll also be a nice component of killing off the gross dependency we have on the old DirectX SDK due to Microsoft stupidity in how the sound libs relate to different OS versions.

Cutting it out means that when we drop DX9, so with it goes the old DX SDK and we can just use the Windows SDK for simplicity.

But beyond that, all that's really left is prodding a few known bugs, and then I believe 3.10 is about ready to go into RC for a shakedown before release!

Also, it came up before, with trying to establish a better testing paradigm, so I began working on a new test level. Outpost has served admirably, but it doesn't really touch on all the game object classes, and as our tools to test stuff improve, it hasn't been slapped into shape along with. So, I started jamming on a new test level that should hopefully touch all bases, and be usable with the more robust testing paradigm going forward to make sure weird graphical variances or bugs don't sneak past us.

It's still got a ways, but I had tweeted some screens of the WIP level before:




It'll have an extensive forest and terrain, lots of rocks and outcroppings, a river, some large puddles, a bunch of buildings sprinkled around with a small town... - basically, should be able to cram all the gameplay classes into it except for the water plane, but it has water blocks, so that should be sufficient. It's utilizing some personal assets of mine as well as stuff from the pacific demo, as well as stuff I've created just for this, like some of the ground textures. The plan is to establish the level, and then over time replace the art with high quality stuff. The pacific demo foliage is good, but it's definitely showing it's age, with it's lower resolution textures and relatively low geometry count, for example.

In the end, it should prove to be a very solid testing sandbox.

Also, also, I think it was mentioned as a suggestion in passing, but I figured I'd note it down here for a more or less official stance on it, but for 4.0, the editor will be adopting a 'dark skin'(though probably not literally black, as that'd be silly). It's not only fairly common now, but it helps with stuff like eye strain, which while subtle, can be a huge comfort when doing long editing sessions.

I've got a few ideas on how to make themes work, as well, so ideally we make it possible for several themes and you pick the one you like, but at minimum, the editor UI will be getting a little bit of shade for 4.0.

Tangental to all that, I've been making headway on my own personal game project, which is pretty cool. I'm hoping to have the core gameplay loop prototyped out by the end of the month, and then spend the next month or two doing the graphics sex-up pass to get it presentable.

I've got a website for it up currently, which you may have seen if you stalk my twitter, here:

http://thefactorygame.com

Feel free to keep an eye on it, I plan on progressively updating it as work continues

[Duion]

Did you fix the normal maps being wrong for the sketch tool? I can't remember exactly, but I did some extensive tests in the past and the result was I think, that the normal maps on the sketch shapes were somehow mirrored. So the shadows were wrong.
You probably just make a 2x2 cube in blender with a normal map texture and then a 2x2 cube with sketch shape in Torque, then watch how the shadow falls on the normal map, it will be different.

[JeffR]

I think that was corrected, yeah. I would need to double-check again to be sure.

[JeffR]

Entities, Components, Game Objects, and You!

Hey everyone! As 3.10 gets close to exiting RC testing and be finished and in the wild, I've been working on the entities, components, game objects and assets side of things in my R&D build to get it prepped for the prime time as we ready the push towards 4.0.

With that, there's still some vagueness in how it all works and intermingles, so I figured i'd take some time to jot down in my workblog here what each thing is, how they interact, how YOU can use them, and basically try and dispel confusion and solidify the concepts for everyone. I'll probably separate them into several posts, because going in-depth may take a bit of text, but it should act as a sufficient primer(and I can copy it all out for documentation purposes later, hoohoo).

First, let me lay down the higher-order explinations of each before we get into the meat of everything:

Entities
These are going to be the basic game object class. Everything will effectively be an entity, or for those of you like that to get all customiz-ey, will be what your custom classes derive from. It'll completely replace how ShapeBase acts as the common root for all the gameplay classes in the engine right now. The biggest thing is that entities allow the use of Components.

Components
These are little, separated bits of functionality for rapid work, and easy reuse. Rather than having a class that does physics, rendering, collisions, damage, weapons, state machines, etc(cough, looking at you, ShapeBase), each one of those would be a self-contained bit of functionality. A PhysicsComponent, CollisionComponent, etc.
This way, you write the functionality once, and can very quickly put together whatever functionality you need your game class to do. Need an object that renders a mesh? Spawn an entity and add a Mesh Component. Need it to collide with stuff? Add on a Collision Component. As they're separated, self-contained bits of functionality, they can be added on to your entities without having to code them in. Just literally add them to the object as you would any child object and poof, now that entity can do the thing the component says it can!

Game Objects
So you have your Entity with the various Components on it, allowing you to make it behave the way you want. But it's kind of a pain in the butt to manually add them each time, or do it programmatically. And that's where Game Objects come in. Game Objects are like a Prefab, but intended for gameplay functionality. It lets you save out your Entity + Components out, and easily spawn copies of them. What's more, you can have scripts associated to the Game Object, allowing for common script behavior, tying it all together if you want.

Assets (and Modules!)
Assets are a convenient means of tracking your...well, your assets. There's a manager system that keeps tabs on all your assets that are loaded, via the modules they're associated with. This lets you keep tabs on what's loaded, what's in use, and standardizes referencing/loading them. Rather than needing to include the path for your shape file you want your object to render, which could be changed and lead to a lot of manual editing to point to the new location, you just reference it in the format: ModuleName:AssetName. In our shape example, you could do MyArtStuff:TestShape, and as long as the asset's been loaded by the module(which happens automatically when the module loads if the asset is valid) then regardless of where it's placed in the game's directory, regardless of how it's moved around as you edit and organize, the system knows what asset your talking about, and you can avoid all those annoying manual edits and updating your objects if you moved your stuff around.

So, there's the short primer for each. From here, I'll do in-depth posts with pictures and videos exampling each of these out to give you an idea of what they are, what they do, and how it'll help workflow and iteration times.

[JeffR]

Modules and Assets

Alright, lets kick this off with the higher-level aspect of all this new stuff to work with, Assets and Modules.

Lets start with the topmost aspect: Modules.

What are modules?
A module is pretty much what are often called Packages in other engines like Unity or UE4. It's basically a package or group of assets, designed to be self-contained and easy to drop in and go. Modules are tracked by the Module Manager, and can be loaded, unloaded, and have stuff like dependency tracking to help make sure everything loads in the right order.

How do we use them?
In the new template, there's a modules folder, which is where most of your game's content will go. Quite probably be named something else in the end, but the folder's idea is the same regardless. When the game launches, and we get all the engine stuff initialized, the Module Manager is informed to look in folders and look for a module definition.

As the name would imply, it's a file that defines the module, it's name, any dependencies, what extension the assets and stuff will use, etc. This allows some customization to how your modules can behave, but largely, it's going to be pretty consistent.
So, the Module Manager parses through the directories - namely the modules folder, mentioned above - and finds our module definitions inside a folder for our module stuffs. An example of the definition would look like this:

Code: Select all

<ModuleDefinition canSave="true" canSaveDynamicFields="true" ModuleId="TestPackage" VersionId="1" scriptFile="TestPackage.cs" CreateFunction="onCreate" DestroyFunction="onDestroy"> <DeclaredAssets canSave="true" canSaveDynamicFields="true" Extension="asset.taml" Recurse="true" /> </ModuleDefinition>

Saved as a *.taml file. When the module manager finds and reads one of these files, it parses it, and creates and sets up a module entry in the module database. Once we read all our modules into the database, we then do loading of modules.
It's possible to very selectively load modules by explicitly saying 'load X module' to the manager, which is awesome for stuff like mods, or stuff particular to game modes, expansions, etc.
But normally, we'll likely load everything by default.

When a module is loaded, it iterates through it's directory looking for any assets, as set up in our DeclaredAssets block in the definition. We find any valid assets, and add them to the Asset Manager's database. They aren't inherently loaded yet, but they're primed for use. We also then call our onCreate function in our scriptFile that is paired with the module. This allows special handling of custom scripts and the like, allowing you to exec scripts or whatever other special functionality you need for the given module.

At this point, we're basically all loaded up on the module end. You may have spotted we have a DestroyFunction as well, which lets us do any shutdown/cleanup stuff in the event a module is unloaded, such as a mod being disabled, or the game is shutting down.

Now then, on to the more interesting half of this:

What are assets?
Assets are any given resource to be tracked and managed by the modules, and thus very easy to utilize in game. Assets range from shapes, sounds, component definitions, game objects, state machines, etc. It's a definition file that references the actual resources, and builds a common, easy to use entry in the AssetDatabase. This allows us to avoid annoying issues like 'I had 10,000 static shapes in my levels referencing this shape file, but then we moved it due to reorganization, or renamed it because the path had a typo, etc, and now I have to manually edit that garbage'.

How do we use them?
With assets, you have a consistent, easy way for objects to know what asset your talking about. It can be moved around, point to different shapes or any other manner of modification, and it doesn't impact the stuff using it at all.

We do this by having a regular scheme to refer to our asset. And it's formatted via <ModuleName>:<AssetName>

The module name, obviously, is the module that owns the asset. This is established as I explained above, where the module reads through the directory, finds an asset, and loads it into the asset manager database. This associates the module to the asset as it's owner. The asset name is, of course, the name of the asset as dictated in the asset definition.

So when you take your MeshComponent and want to inform it what shape asset you want to use, you can do a

Code: Select all

shapeAsset="MyModule:MyCoolShape";

and you're gold. As long as the module is loaded, and the asset is valid, it'll load, even if you change the shape file the asset points to, or rearrange the assets around in the module, etc.

Example
So how do we create these things, and make use of them? I've got a video I'll be putting down below, where it walks through using the Asset Browser to create a new module, then create a few assets, and use them with a component. You can also do all this manually by creating the assorted files via text, but obviously it's a lot faster to use the Asset Browser

[Jason Campbell]

This is amazing. The Module and Asset Managers alone will be such a leap! I can barely wrap my mind around all the changes. I can't imagine what it's like being in there making them. Thank you.

[JeffR]

Updated the post with the video walking through creating a module, creating some assets, and using them on an entity.

Lemme know how the audio came out. I had to jack the gain pretty high on my craptastic headset. I need to track down a real mic if I'm going to do more of these. If I need to tweak the audio levels, or any part of my presentation needs work, let me know and I'll polish it up.

Tomorrow: A post on Entities(and maybe components too)

[Chelaru]

Is Torsion going to be in the t4 build?

[Timmy]

Is Torsion going to be in the t4 build?

No.