Pull Request: New Base Template

This forum is for tracking and working on active issues that need to be resolved, as well as testing Pull Requests that are waiting to be integrated into Torque 3D.
51 posts Page 5 of 6
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Fri Feb 26, 2016 8:35 pm
Pretty similar.

I used a good bit of it as a starting point(like the core folder), it just extends further to utilize the modules system to make it easier to drop in/out module packages and the like.
irei1as
Posts: 59
Joined: Fri Feb 27, 2015 5:13 pm
by irei1as » Wed Mar 30, 2016 7:44 pm
Let me note that old graphic cards (old intel laptops, for example) makes these templates crash because they can only handle Basic Lightning.

But, well, a merge in 27th Feb (c0e29d...) already kind of broke the rendering of the terrain for those old computers.
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Mar 31, 2016 4:40 am
Got any particulars on the crash, like a console log?

It shouldn't really CRASH on really old hardware, just, you know, run poorly.
irei1as
Posts: 59
Joined: Fri Feb 27, 2015 5:13 pm
by irei1as » Fri Apr 01, 2016 5:06 pm
The crash is related to
https://github.com/GarageGames/Torque3D ... er.cpp#L79

If that function returns false, be the pixel shader less than 3.0 or the card unable to use R16F textures, then the advanced lighting isn't initialized (so it could try another light manager next). The old computer fails at both then no light manager at all. It's more a minimum graphics requirement issue so it's not really related to the new template work.
Image
Image

Console log: http://pastebin.com/KjPGfV1b

I'll "shake" a bit the source around to try to force past the pixshader 3.0 and the 16 bit textures. But I don't think many people needs this kind of ancient compability.
---------------------------------------

A thing I've noted that it's not fixed for the template is the bug of the animation trigger editor explained in:
https://github.com/GarageGames/Torque3D/issues/1273


Other minor thing is that some buttons of the menu don't show if the height resolution is kind of small (1024x576). But anybody can fix that with the gui editor if they plan on using a smaller screen.
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Wed Jul 27, 2016 6:02 pm
@
User avatar
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.

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:

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

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?

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:

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.

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?
Bloodknight
Posts: 76
Joined: Tue Feb 03, 2015 8:58 pm
by Bloodknight » Thu Jul 28, 2016 12:35 am
disclaimer: only read the last post, i'm lazy, sue me.

If you are moving files and folders around why would you move them into core rather than out of core? seems to me core is more about the engine initialization and less game related core functions maybe.

Why not separate files in a way that makes separating client and server easier for those that want to make multiplayer games
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Thu Jul 28, 2016 12:56 am
Bloodknight wrote:disclaimer: only read the last post, i'm lazy, sue me.


Well, if you are going to only read the last post please try to fully grasp that single post you do read. :shock:

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.

Bloodknight wrote: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 @
User avatar
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!
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Jul 28, 2016 4:37 pm
@
User avatar
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.

TorqueFan wrote:@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 @
User avatar
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.

Bloodknight wrote: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 @
User avatar
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.
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Fri Jul 29, 2016 7:11 pm
I appreciate all of that info man, thanks. It's all pretty clear with your explanations, sweet! Yea, that shader initialization is a trip. If it DID all get merged into core\ at least developers could simply just remove any shaders they didn't use if that was the case. Any project specific shader code could sit comfortably in a module.

JeffR wrote:Wouldn't this be question 2? :P

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


Yea, it kinda is I guess. I was just wondering if onStart() and onExit() callbacks would still exist that's all. I noticed ya did still use onExit() so I'm assuming those callbacks may still be floating around. It's a trivial concern, as you've eluded to, in question 2 we've covered what really matters: the modules initialize everything with their functions!

JeffR wrote: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!


Toss my vote in the hat for doing that. There are a few reasons:
1) Because I am going to separate my client/server scripts into separate modules. lol. My main project I'm making 'modular' atm will require it, because all of my GUI stuff will belong in the client module.
2) I believe that long time users of Torque will find it easier to maintain familiarity with separate client/server modules. It just 'feels' comfortable to pop open whatever directory it may be and see client\ and server\ sitting there side by side. Torque-goers know that feeling! :D

Really I believe what's important here is looking at how easy it is to approach Torque. Regardless of our module structure or initialization process, Torque is going to require that client/server architecture. Better sooner than later for newcomers to learn how that all works. Having a single 'clientServer' module could serve to conceal a bit the importance of that divide for those unfamiliar with the engine.
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Thu Aug 04, 2016 12:46 am
@
User avatar
JeffR
- I finished with my new template, which is based off of this one. I gotta hand it to ya, I've looked at reducing down all of that initialization code for quite some time but never really pegged it. Certainly not in such an elegant implementation. Kudos!

So yea, after really getting my hands dirty and building up a project(using this template as a base) I wanted to share a couple things that stood out to me during the process.

Root Directory : I renamed the root game\ directory to app\. If you really think about it, T3D can and has been used to develop more than just games. Of course many of the included classes and code is specifically designed around making games, so this could just a matter of preference ;) But hey, think about it!

Shaders Directory : Actually I just ended up leaving it alone entirely. It exists in the root directory alongside core\ and data\, so it's app\shaders\. After getting a better 'feel' for the new directory structure, I actually didn't find anything wrong with shaders\ having its own directory there. All of the modules rest in data\ and core\ deals with things necessary to initialize the engine. So the shaders\ directory still does sort of exist as a grey area and as such shouldn't be denied its own directory.

Gui Directory : Personally I opted to keep the old gui\ name instead of the new UI\ one, for 2 reasons: Firstly, I am more familiar with looking for a directory named gui\ after using Torque for years(it just 'feels' like it should be called that lol). Some of my existing projects can easily be transferred over using the same directory name. File paths will of course always need to be changed for something like this, but in any event I've found the entire process of transferring over to the new module system easier with the gui\ directory name intact.

So really just some directory naming stuff. Which is a good place to be in with such a large update to the script base. Good work man, I hope you'll consider the suggestions :D

P.S. Oh, I almost forgot. I did end up splitting apart the client\ and server\ modules. In the root directory's main.cs I did this and it works well:

Code: Select all

if(!$Server::Dedicated)
   ModuleDatabase.LoadGroup( "Client" );

ModuleDatabase.LoadGroup( "Server" );


Of course this depends on your 'Client' module residing in the group called 'Client' and the 'Server' module residing in the group called 'Server'.
Cheers!
51 posts Page 5 of 6

Who is online

Users browsing this forum: No registered users and 1 guest