JeffR

@NekoDemon117 Try Bandicam. Free, and it produces pretty solid quality videos without a huge amount of recording overhead. I use it and it's pretty solid. OT, As per the work that went on in IRC yesterday, it looks like most of this stems from how linearization of light and colors was being handled. Good headway was made on that, and we can get the code up here for others to verify against before a roll-in. I think the only remaining bit is the fog was still a touch off, but overall the lighting was much improved and correct.

Yeah, the recommended way to generate projects currently is CMAKE, and both D3D11 and SDL are standard options you can toggle on, generate and build. Do let us know if either/both of those help with it :)

Az noted that the steamworks integration behaved better with the SDL platform on their attempt, so any chance you could try smacking together a tester build with the SDL platform layer instead, and see if that changes anything at all?

You guys are using the regular windows platform stuff, not the SDL2 option, right?

@irei1as Sorry for forgetting to comment back on your post. Thanks for the check on that, I'll try and spool up an older computer to see what it does and at least try and make it fail more gracefully if there's no pragmatic way to fall back on older hardware. Haha, thanks. A lot of the idea behind the structure is from @buckmaster, but I've expanded on his original base. If you mean the module script files for initialization stuffs, then you actually can set what the creation/destroy functions are called in the module definition file. I opted for the create/destroy naming convention, but start/exit could work just as well. Wouldn't this be question 2? :P Not quite getting your meaning here. Could you clarify some? Yeah, the modules are intialized when loaded. If you look at the module taml files, there's a entry for the create and destroy function names. In the main.cs, we find and force load any game modules at the start, which automatically executes the create function. Order is defined by dependencies, so you'll see some of the modules have dependencies to the UI module, for example. The destroy function is called when the module is unloaded, which would usually only occur when the game is closing, but could also happen if you, say, de-initialized mods. This is definitely one of the squirrelier parts. Most of the common shaders are just core, attached to lighting, and main classes like terrain or water. So there's a fair case to be made of them just being in core to make sure everything initializes correctly. At the same time, customization of shaders(and entirely new ones) is pretty common, which puts it more into the 'project specific' space, so bumping them into the data folder also makes sense. It's definitely a weird one. If we had to merge 'em all, it'd probably make the most sense to bump 'em to core. The idea behind the core directiory is "This is what's needed for the engine to load/initialize". The game-specific stuff is still there for core initialization of core game classes like terrain and all that. So they kinda exist in a twilight zone area. You can just do a search for: $Core::CommonShaderPath And that should find 'em all. Other minor path tweaks were with: $Core::MissingTexturePath $Core::UnAvailableTexturePath $Core::WarningTexturePath Yeah, this all ties back to what I said above, about how the game class initalization and those common shaders are kinda in a twilight position, where they ostensibly need to be there to make sure it's all initialized properly, but also pretty game-specific as they're prone to modification, where as the CORE scripts usually aren't. Due to the way this template completely revamps the initialization process, that's already been done. As an aside, though, there is a new module named 'clientServer' that handles all the initialization for Client AND Server. But it actually IS easier to make MP games with this template, because it's easy enough to go one way or the other following the initialization scripts @JeffR has assembled here. Heck, as a matter of fact, the more I delve into this New Base Template, the more it's starting to stick and it's working well. I've already started building modules and having them initialize using the new system! EDIT: The thought occurred to me that one could split the clientServer module and add shaders\ to the client module. That could be useful, but Jeff's got it all so tidy already it's kinda hard to bring one's self to mix it up. lol. The client and server scripts are separate and initialize from different functions. Good enough for me! Breaking up the client and server sides into 2 modules wouldn't actually be a bad idea at all. It'd make it easier for people to have a 'client' and 'server' build of the game, for projects that go that route. Definitely worth a consideration! And yeah, if you've been keeping an eye on my work blog thread, the modifications to the asset pipeline should make this new approach way easier. I'm most likely going to retool the template some to account for those changes when they get more solid, as it'll be easy to smash out and organize modules in the editor directly. May help make clearer what to do with stuff like the terrain/water initialization stuff too.

You gotta start spamming it on twitter and sending a few copies to popular youtubers to try and get them to play it, drum up attention :P

There's not really distinct meetings at this point so much as constant daily discussions and work in an skype group.

Well, at least they got someone hooked in now, so we can whiddle this down. Interesting to note with the tutorial level having postFX disabled. If that's the case, when you first launch the main game, make your character, and wake up in the room, and go out the door to talk to the guy, those scenes run fine, and it's only when you sleep and wake up in the inn in the morning that it runs into the issues. For those conversation bits, are postFX disabled in the view as well?

Ah, cool, that'll probably help. So I did some more iterating on settings, and noted that on the oddball occasion it didn't totally lock up when I had shadows enabled, it DID tank the FPS. We're talking like, 4fps in the inn. I did some finnegaling with other settings, and noted that I could have shadows on and run fine if I manually disabled HDR. Could you, or your tester dude try doing that as well? Have the shadows pref on, but set the $prefs::video::HDR to be disabled, and see if it also prevents the lockup?

@jjkarau You said if you extract to a folder on the desktop is fine, but if you move it, it breaks. What happens if you extract straight into a different directory? Like, say C:/gamedev/testing or whatever? Does that also work? Or only if it's on the desktop?

The large size isn't unusual. It tends to build in a bunch of debugging stuff. You can trim that down to a more normal size using the strip command. As for the 'command not found'. I don't think I'd run into that before. Were you trying to launch if with a debugger, or were you just trying to execute the application directly? Though, if you noted a failure of linkage, that could very well be the issue. Maybe try doing a recompile and see if it re-links correctly?

Well, I had some ponderations I've put a fair bit of brainstorming towards in regards to loading large levels in my one workblog post here As someone that's actually crunched on the issue, I'd be 100% keen on your feedback on the idea.

Sorry for the delay, but it was quite a few PRs that got pulled! Here's the list! I'll also update the OP with it.

Give this a shot: http://ghc-games.com/SC/Torsion.zip

Can you modify line 4013 in guiTreeViewCtrl.cpp so it looks like: if (parent->mNext && mProfile->mBitmapArrayRects.size() - 1 >= BmpLine) and give it another shot? Looks like when there's a valid item listed in mNext(so we go from a subItem to the next parent's child item) it's not properly vouching that the little line icon exists in the gui profile, so we get a crash. Lemme know if that corrected it for you.

Yeah, it should. Example: http://ghc-games.com/public/ngonstest1.png And when imported into T3D, you can see it converts to the actual tris: http://ghc-games.com/public/ngonstest2.png The main thing with ngons is you're pretty much at the mercy of how the triangulation occurs, so if they appear in a spot that deforms on animation, you can get really funky results that could be avoided if manually fixed, but outside of that, they really don't impact anything. It's more just a "Principle of the thing" matter at that point.

Alright, that narrows it down quite a bit. It means that it's not really an issue with advanced(deferred) lighting itself, but something with shadows being rendered - resolution of said shadows being a non-factor. I'll do some more iterating(pending I can get it to kick in again) today.

It seems to me like these features will take drastically less time to develop than the other listed features. They also don't break backwards compatibility. In my opinion these are useful features that I think justify a 3.10 release rather than holding them back until the rest of the features are finished. Yeah, it's wholely possible that we can do a non-breaking update a la a 3.10. It's something I'll keep an eye towards. I would say though that the new base template is definitely breaking because it's a complete restructure compared to the current ones. If someone wanted to update their project, it would be a bit of an investment, and not just a drop-in-and-done thing. Not an EGREGIOUS amount of effort, but definitely not an 'update a few scripts and ye good' thing. The main thing of it is how fast stuff like that can cascade. If we drop out Dx9 and strip out the stuff related to that, there's some script changes there, if we did that before the new template, no biggie, if it happens after the new template, then that's a bit more complex to parallelize. Same with something like PBR. If it gets wrapped up and implemented in the next couple months, that impacts a ton of things, including existing art assets, meaning that doing a 3.10 release is a lot more complicated, etc. As a separated list, it's no big thing, but depending on the order stuff gets merged in, it can get weird, that's why I figured I'd lay the plan out in a safer 'assume breakage' target. If we can swing a lot of that stuff without that being a concern though, then a 3.10 update is a definite possibility.

Hey everyone! It's my pleasure to be able to announce that version 3.9 is now released! This has been quite a big release, with a whopping 142 merged PR's totaling to 515 commits, which is more than DOUBLE what went into 3.8. A herculean effort on everyone's part for sure! Here's a list of all the fine people that helped make this release possible: Azaezel rextimmy John3 Bradan pacomont dakk blackwc jamesu ghost irei1as JeffProgrammer OTHGMars Lopuska Alex-doc TheDushan RoundedIcon camporter rasteron Bloodknight Ragora ZOD2015 And still more of you that helped file issues and test. A huge, huge thanks to all of you! Several big things to note with this release is the full and proper roll-over to deferred rendering, the initial implementation of the entity/component stuffs, switching over to epoxy for OpenGL handling and DirectX 11 integration. Yeah, yeah, where can I get it? As always, you can nab it from the wiki's download page, found here. So, next is 4.0, right A capital question, question text! Indeed, the next major release will be 4.0. If you've been chumming around on the forums or in chat, you may have gotten hints that 4.0 is slated to be a pretty big deal, and I'm more than happy to intimate why. The big aspect of 4.0 is that it's going to be the build where we're OK with breaking backwards compatibility in order to get stuff updated. For the released up until now, we've put a fair bit of effort into avoiding huge breaking changes because, well, that sucks to have to rework your project when that kinda stuff hits. However, it also means that large improvements to the understructure, rendering, art pipeline, etc can't be implemented as those will, naturally, impact and probably break existing setups. So, we've been holding back on quite a number of big things for 4.0, and now that 3.9 is out, we can charge full-steam ahead to get all this stuff in there are really bring T3D back to where it should be. So, here's a main features list that we're looking at bringing into Torque for 4.0: Physically-Based Rendering. This is, unsurprisingly a pretty big one. Luckily, it's also most of the way done! The only main piece that needs finishing is reflection probes, and the core features are in. From there it would just be a matter of dialing in the supporting art pipeline and tweaking the math to make it look as good as possible. MacOS support. This was originally slated for 3.9, if you look at the 3.8 release blog, but a lack of machines to test on, and the age-addled old platform code made it impractical to really tackle initially. The good news is, near the end of 3.9's development, with SDL and epoxy to take a LOT of the workload off, huge strides were made and it's actually almost completed. There's still some issues with rendering on some machines and catching errors and warnings that crop up, but it's looking very practical to have MacOS as an official platform for 4.0! You can see Timmy's screenshot in the 3.9 RC thread showing off T3D running on MacOS with his and JeffH's work now. SDL as the main platform layer. Torque3D's supported SDL for quite a while now, and it's naturally the main platform layer for Linux(and MacOS). However, it's been a little bit of a red-headed stepchild to the Win32 platform code. For 4.0, that's changing and SDL will be adopted as the core platform layer with whatever glue needed sitting atop it. This will drastically simplify the platform code and make it easier to maintain. It also offers a good bit of future proofing should any other platforms come into the equation down the line. SDL's stuff is very nearly at parity with the Windows side, it's pretty much just a matter of jumping over the last bits and doing cleanup/bugfixes to make it rock-solid. New Project Manager The old project manager was useful, but was hacked together with QT and php, so maintaining it was a little sketchy and fell by the wayside for the more standard CMake gui. However, there's lots of management things CMake can't do, which is why the Project Manager will be making a comeback, it'll just be a graphical frontend sitting upon the more standard cmake project generation. This new PM will let you manage your updates, and hopefully in the future hook into online repositories for easier grabbing and integration of updates as well as fetching content packages without hassle. New Shadergen As great a job as the current workhorse does of generating shaders for all the many materials you need to make a game, updating and expanding it has proven to be a pretty annoying thing to deal with due to how it's structured. Excellent peice of tech, but a chore to maintain, just like ye olde German tanks in WW2. As such, we'll be looking into restructuring shadergen to not only make it easier to update and expand upon in the backend-sense, but also easier to build materials/shaders for the end user as well, up to, and probably including a node-based approach for engineering your fancy shaders for your fancy materials. Graphics API refinements DirectX 9 has proven to be a monstrous workhorse of the graphical APIs, reliably serving well beyond what anyone though it would. However, while it has proven to be a rock-solid API, the time has come to retire the poor girl and send her off to the glue facto-eeeer, the farm. Yes. As such, DirectX 11 will be taking over as the main Dx rendering API, and will continue to see refinements to bring it up to speed now that Dx9 isn't hampering it or OpenGL. Timmy's been poking at this and has noted improved performance in Dx11 by quite a lot, and some gains in OpenGL as well. Threads. Threads for days One major blocker to rendering performance that even dropping Dx9 won't help is that we curretly don't thread or do much to optimize out the render calls themselves. That'll change in 4.0. We've been brainstorming the optimal approach for a few months now and have a pretty solid plan of attack that will see the render calls threaded out, and also proper batching of rendered geometry where appropriate. So fewer, faster drawcalls for the same workload. We'll also be looking at threads for handling resource loading and spawning of objects to cut out all those hitches when the map starts or stuff is created. Hardware Skinning Another thing that's been pretty much complete outside a few oddball behaviors we'll be getting in there is Hardware Skinning. When it's behaving, the current implementation already notes a huge improvement in performance for animated meshes, so getting it polished up and in should be a huge, immediate performance boon. Physics API T3D's had a physics abstraction layer for a long time now, and it's been pretty useful in letting the end user decide if they wanted PhysX or Bullet. However, Torque's stock physics has still served a useful niche in being network-reliable, or lightweight for basic physics mechanics, and some people find it to be a pretty workable thing. As such, the Torque physics will be converted over into a Physics plugin, so all physics and collisions will go through the Physics API and standardize all the behavior for that across the engine, cleaning up quite a lot and making it easier to maintain. Entities, Components, and Assets This is the big one from non-rendering side. 3.9 already has the initial implementation of the entity/component stuff, as well as the Assets/Modules systems, but they're not yet fully utilized. That'll change in 4.0. If you've been checking out my work blog with the recent updates, I've been covering work I've been doing on the improved asset pipeline, as well as continued work with the Entity/Component stuff. For 4.0, this will become the standard, and all existing gameplay classes(Vehicle, Player, Item, Shapebase) will be replaced with GameObjects built of entities and components to do the same work. The idea is to give users a similar base to what is in Torque now in terms of starting objects, but remove all the bulky, hardcoded functionality. It should be a standard point, not an anchor, after all. Tying to that, we also will have: Assimp support This was actually mostly done back in the day, just some issues with animation stuffs and a few other minor problems. I'd poked at this with some R&D time a while back, so it shouldn't take much tweaking to get it polished up and hooked into the assets system, which will allow quite a few new 3d model formats, including FBX. A new base template This is also basically complete. This will be a much more streamlined starting template intended to easily drop in modules, assets and the like into to build up your game project, as opposed to having to spend time stripping out the stuff you don't need. Numerous ancillary improvements also help load times, easier to read and comprehend code and the like. This will replace the empty and full templates, cutting down on the effort needed to maintain(no need to duplicate changes). Vive support This comes from our own Mango's efforts. It's pretty much done, but didn't quite squeak in for 3.9. It will be going into 4.0 for sure. We're also looking at possible C# support, based on Lukas's fine work. So, the main takeaway from this is that the major goals for 4.0 are: A cleaned up codebase. Improved rendering and performance. Easier to use and expand - Source code should be for rendering, optimization and fancy stuff, it shouldn't be REQUIRED for the prototyping phase. As always, if you note any issues, please make an issue on the github page, and if you have anything you'd like to contribute or suggestions of things you'd like to see, by all means hit us up on the forums, we'd love to hear feedback! Here's the release notes for 3.9 Have a good one, and happy developing!

So I tried running through that first part 4 times last night and couldn't run across a freeze, and that was on maxed settings with steam running in the background, same as before. So it's a bit of a flakey one. In the meantime, your dude that's been helping you test, can you ask him if he notes any difference in behavior if he disables JUST the shadows in his preferences( $pref::Shadows::disable = 1 )?

When I triggered it, I merely had Steam running in the background. Didn't seem to trigger if steam was completely closed out. The missus hijacked the AMD machine to game all day, so I didn't get a chance to test any further today. I'll get back at it tomorrow and let you know if I can narrow 'er down any further.

Ah, cool. Yeah, if it's particular to the lighting, there's a few things I can have a look at, such as manually disabling certain things via pref settings(like shadows) to narrow 'er down further. I'll poke at it some more this evening.

Yeah, it was fine on low lighting + steam, or high lighting + no steam. What version of T3D are you guys on?

Ok, did a bit more iterating, and it seems like the hangup occurs if I have steam running. When I had it running, I'd make a character, click through the first screen(to open the door) and it'd lock up. I killed steam, re-did it and it seemed to progress through OK. So something's gotta be going squirrely with the recent drivers and the steam integration.