JeffR

Pretty neat. The first 3 look like I'm in various stages of an acid trip, haha. That last one's pretty slick. Any custom shaders happening, or is that purely a custom color correction ramp?

In blender, take care to make sure that your mesh and armature have any rotation and location changes 'applied'. Having the transforms at non-0 can look fine in blender, but yield really weird results in-game.

Just the other day I was testing character models/rigs and had the guy turn into a spindly slenderman horror-beast because the mesh had been rotated and the armature hadn't, and it tried to 'compensate'.

Why you want to do it? You can just make your game singleplayer only, no need to remove networking.

 

I'm the main programmer on board at this point, and I've worked an early-build MMO client-server model from our previous attempts at the project into something somewhat standalone, and I want to work it into Torque, but I can't get it working. I'm wondering if the built-in networking component is what's getting in the way. I would rather strip out what's in Torque and work in a fresh new version of what we've made than try to get what we have working around what's already there and ignoring it. In fact, doing so, according to a couple of people I know networking from the college, is considered a (albeit non-defcon) security risk.

I mean, they could be wrong, they aren't industry pros they're mostly info security in corporate settings, but I still think they probably have a good basis on the thought. Unless someone has a suggestion on how I could somehow rework the built-in networking altogether, that's what I'm looking at.

Would I benefit from making that client-server model a plugin to the engine versus built-in? I would think that too would be a security risk versus just going full into building it into the engine and thusly client.

If that makes sense, please shout if I'm not clarifying right. :)

Details for the particular setup you're shooting for would be useful, but on a basic level, I'm not sure how extreme a security risk an uninitialized and unused networking layer would be.

For example, if you wrote a custom game class that worked with your custom networking model and doesn't interact with the built-in packet handling in any way, then any theoretical bits exposed that could be set couldn't really be utilized to mess with the custom game class.

If your security buds have specific points of concern a la security, those could probably be addressed, but if your stuff doesn't interact with the existing networking, I don't think it'd really matter much.

Regarding the performance I could not tell, seemed to be a little better, but not much. I could notice significantly less polygoncount, so this should impact performance in some way positively. I will make more detailed tests for that later.

The jump from prepass to deferred will reduce the polycounts rendered, but offset the potential gains there with extra bandwidth costs in setting up the gbuffer and the like.

In your average scene, performance is likely to be about the same, but deferred shading scales better when adding more lights and post process heavy effects.

You could make it as an addon that is default to off like other modules with Torque like physics modules are and if someone wants to use it, he can switch a flag to on before compile.

Something along those lines, yeah. The actual changes, as Lukas has pointed out is really just exposing and tweaking an existing interface in the engine to make it more flexible, but the idea is it's an additional option for people to work with if they want to work with it, but not an obligation.

If C# does get implemented, it won't be at the cost of TS. At minimum, the core configuration and tools are in TS and that's unlike to change in the future.

Much like enabling multiple sound systems and multiple physics engines, the idea is to add a framework to let the end-user have the option that suits them best.

C# is very unlikely to go anywhere, and if you don't want to use it(if it gets rolled in in the end) you can just continue using TS as usual, but having it as a potential option may well be more appealing and comfortable for some people.

@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.

@JeffR: It would appear I'm raising this thread from the dead! Necromancer extraordinaire! I have been designing a new Base Template for modular development, and I found this thread. Firstly I'd like to commend you for the work and effort that went into building this. Thanks man, this has been needed for awhile. Respect, I am particularly fond of the craftiness that went into bypassing all of the duplicate initialization code.

Haha, thanks. A lot of the idea behind the structure is from @buckmaster, but I've expanded on his original base.

I have some inquiries about your work. Firstly, I didn't see the onStart() and onExit() callbacks in the new main.cs files.

This is really interesting, and left me curious:

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.

Question #1: Will the current "main loop" layout be deprecated in source? Obviously it's already been deprecated in the New Base Template, just wondering if the current functionality would still be available. (i.e. onStart() and onExit() overrides to initialize mods.)

Wouldn't this be question 2? :P

Not quite getting your meaning here. Could you clarify some?

Question #2: Related to Question #1 - Would the current onStart() and onExit() callbacks just be redundant anyway because the module system is automagically initializing the modules?

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.

Unrelated to all of that, I wanted to ask about the postFX and shaders:

Question #3: Would it be safe to move the shaders\ directory into core\? It just seems out of place since it's not really a 'module' in the data\ directory. It appears shaders aren't necessary for core\ initialization, though, which leads us to Question#4:

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.

Question #4: I noticed the core\gfxData\ directory holds game-specific stuffs. TerrainBlock, Clouds, ScatterSky, Water...are these necessary to include in core\ ?

Suggestion for #3 and #4: I would merge all of that either way. Either place shaders\ into the gfxData\ directory or gfxData into the shaders\ 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.

Anyways man, yea thanks so much again for this template. I had put in a few pages worth of a changelog constructing a new template when I stumbled on your post. Would have saved me a good bit of time. lol.

Oh, I almost forgot:

Question #5: Could you point me in GitHub to relevant files that were altered in source regarding the shader file paths?

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

In my posting, if anything, I've spoken in favor of moving some stuff that doesn't belong in core\ out of it. I only suggested shaders\ joining with gfxData\ since they are closely related anyhow. Preferably, yes, I'd imagine they would belong in a client module. If you look closely at my Question #3 above, you'll see I did state that the shaders aren't necessary for core initialization. Which I immediately followed up with #4, where I question if gfxData\ belongs in core to begin with. Really all of that serves to highlight how much of a grey area those are and it's easy to see how placement of those particular directories/files can be a bit of a chore.

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.

Why not separate files in a way that makes separating client and server easier for those that want to make multiplayer games

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!

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!

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)

 

Making the whole block look like:

 

// Do we draw the tree lines?
   if( mFlags.test(ShowTreeLines) )
   {
      drawRect.point.x += ( mTabSize * item->mTabLevel );
      Item* parent = item->mParent;
      for ( S32 i = item->mTabLevel; ( parent && i > 0 ); i-- )
      {
         drawRect.point.x -= mTabSize;
         if (parent->mNext && mProfile->mBitmapArrayRects.size() - 1 >= BmpLine)
            drawer->drawBitmapSR( mProfile->mTextureObject, drawRect.point, mProfile->mBitmapArrayRects[bmpLine] );
 
         parent = parent->mParent;
      }
   }

 

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.

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.

Does it convert them to triangles?

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.

• 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.
  
• 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.
  
• 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.
  
• 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.

 

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.