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.
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/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-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