Jump to content

Pull Request: New Base Template


JeffR

Recommended Posts

I'd mentioned it in the chat, but I pushed an update that should fix the shader error. Make sure you do a recompile.


And yes, one of the known issues is the brightness menu UI not adjusting to reflect the changes. I'm trying to think of a way to fix that. It does work in-game though.


And the defaults button should only impact the particular menu(controls, graphics, audio, etc).


Also, the latest update has an example of the alternate, module-oriented layout. Give it a look an tell me which you think is better!

Link to comment
Share on other sites

  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Maybe you need to render a shape or small demo scene in the Gui, since the Gui itself does not seem to be affected by the brightness settings.

 

Oh, that's actually a good idea, I think that may work.


I'll give that a shot this evening. Thanks for the idea dude!

Link to comment
Share on other sites

I'm starting to set my project to work on editor improvements based on the NewBaseTemplate tools and I have a small issue with the new setup. I think the default tools should be independant of the general game scripts so if you use it on a modified script base it still work without any changes.

So my current "problem" is with the movement binding, the new editor scripts call: getHorizontalMouseAdjustAmount function which is included in the game scripts:data\scripts\client\game\inputCommands.cs . Since I don't have that script, the mouse movement don't work, I think the editor should have it's own function to get the mouse movement (and any other bind related functions), also it would avoid any problem if someone decide to modified that function for his project needs which might cause the editor to not work correctly.


As I said, it's not a big issue and I will be able to quickly fixed it for my needs but I think it should be fixed in the default tools/ structure.


Edit: Same should be applied to prefs so the editor have his own prefs independant from the game prefs (Ex: $pref::Input::VertMouseSensitivity could become $pref::Tools::Input::VertMouseSensitivity)


Edit2: I think the tools should also have it's own GuiProfiles and not use/overide default game profiles. Not sure if it's something I added to my script base but by running to default tools, my GuiRolloutProfile used on game side get Overridden by the one set in tools. I think, like most GuiProfiles used in tools, the GuiProfile names should start by Tools instead of GUI. Would be ToolsRolloutProfile in this case. Also from experience while working on TorqueLab, there's some coded GuiProfiles used by the tools that should be renamed to avoid conflicts. (I remember having issue with the GuiPopupCtrlProfile which is used by the tools and override the template profile. I had resolved it by using GuiDropdownProfile in my game)

Link to comment
Share on other sites

Yeah, definitely good points.


Well, it'd be fairly easy to have some stuff that handles the editor camera stuffs contained into the tools folder specifically. We could also expand out the editor settings menu to flesh out stuff like keybinds, mouse sensitivity in the editor, etc.


This way, the editor will be consistent, regardless of what kind of game you're making.


Also agree about the editors having self-contained guiProfiles.

It's just that there's so many controls in the tools it's gunna take a bit to do, haha.

Link to comment
Share on other sites

Also agree about the editors having self-contained guiProfiles.

It's just that there's so many controls in the tools it's gunna take a bit to do, haha.

Like I mentioned in my TorqueLab thread, I can help making the stock editor independant of the game templates. Also renaming the GuiProfiles is not a big deal if using a good text replacer tool. For TorqueLab, I used a tools called grepWin and it saved me a lot of time: http://stefanstools.sourceforge.net/grepWin.html

Link to comment
Share on other sites

Alright, sorry for the delay on this(had to get my car fixed which took my afternoons for a bit).


Looks like we'll be going forward on the modular-based layout, so I'll spend the next few days wrapping that up and get her rolled in.

Link to comment
Share on other sites

Alright guys,


https://github.com/Areloch/Torque3D/tree/BaseGameTemplate


I *think* I got the remaining issues squashed and this cleaned up. So everyone give this a pull and a test. If there are no remaining major problems, this can get PR'd in.


BaseGame template now replaces the Empty template, and is the default template selected in cmake. Once a FPS gameplay module is finished, the Full template will be removed.


In the Templates/Modules folder, there's a BlankGame module. If you drop this in the data folder instead of the other modules that are part of the BaseGame template, you'll get an ultra barebones game setup. It's enough to spawn a level and connect to it with a local instance and nothing else. As mentioned above, I'm working at an FPS gameplay module to replicate the contents of the Full template, which will also be placed into the Templates/Modules directory, as well as modules for the pacific art content and whatnot for ease of dropping in and going.


So yeah, give it all a whirl, lets make sure there aren't any real problems remaining and we can get this rolled in.

Link to comment
Share on other sites

when I try to load a level


Executing tools/gui/guiPlatformGenericMenubar.ed.gui.

d:\newtemplate\basegametemplate\engine\source\console\consoleobject.cpp(174,0): {Warning} - Couldn't find class rep for dynamic class: GuiPlatformGenericMenuBar

tools/gui/guiPlatformGenericMenubar.ed.gui (0): Unable to instantiate non-conobject class GuiPlatformGenericMenuBar.

Executing tools/editorClasses/main.cs.

% - Initializing Tools Base


this occurred during exit the engine


http://pastebin.com/H3xHdqWi

Link to comment
Share on other sites

Ah, yeah. That's happening when SDL isn't active for the project. That class only really exists for SDL, so the editor code that initializes it is trying to activate a non-existant class.


Pretty sure there's an easy way to check for that so that'll be an easy fix.

Link to comment
Share on other sites

  • 2 weeks later...

Alright, fixed a few more issues that cropped up(somehow forgot to copy the splash image?!?!?!) and almost have the FPS gameplay module locked in. Gotta make sure the gameplay mode properly initializes and it should be good. Should be all prepped and gold tomorrow for that part.

Link to comment
Share on other sites

Alright, fixed a few more general issues, and got the initial chunk for the FPS Gameplay module up there. Not 100% but it spawns the player via the DeathMatchGame game mode as per the level info setting, and it loads off a module-independent level list now, mirroring the datablock list.


Still need to wrap bugfixes on the fps module, namely the inventory isn't intiailized yet and the like, but it's almost done.

Link to comment
Share on other sites

Got the FPSGameplay module pushed up on the basegametemplate branch last night, forgot to comment here, heh.


Few issues I'm already aware of, but I think it's most all of the way there not. FPSGameplay module is the default included with the basegame template, can remove that and dump in the SpectatorGameplay module for the empty-template style setup, or for a true barebones, strip everything out except the shaders folder and drup in the BlankGame module.


Issues I'm aware of: the generated textures for terrain are hardcoded to art/terrains/, so I'll have to remove the hardcode on that. Also note that the default postfx settings seem to be a little weird with the HDR/Bloom on the blank terrain map. Outpost, with it's own postfx preset works fine though.


Beyond that, I believe the FPS gameplay is functional. Giver 'er a whirl and lemme know if you spot any other issues with it.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

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.

Link to comment
Share on other sites

The crash is related to

https://github.com/GarageGames/Torque3D/blob/development/Engine/source/lighting/advanced/advancedLightManager.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.

http://i.imgur.com/VBgzmya.png

http://i.imgur.com/UdRA8qC.png


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.

Link to comment
Share on other sites

  • 3 months later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

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!

 

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.

Link to comment
Share on other sites

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

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!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...