Jump to content

Closing in on 3.8


JeffR
 Share

Recommended Posts

I know, I'm not blaming anybody. And if I were able to fix it myself I would have posted it, because I think that besides OpenGL/Linux support, T3D also needs the latest on DX9 but also make the step to DX11. We'll see how it goes. :)

 

Yeah, total agreement there, probably from everybody ;)


The BeamNG guys have said they'll likely patch us the DX11 work they've done for their stuff, but even if that falls through for whatever reason, at minimum we can just take Anis' excellent work as a starting point, get it working and move on from there. One way or another, we'll get DX11 crammed in.

Link to comment
Share on other sites

I know, I'm not blaming anybody. And if I were able to fix it myself I would have posted it, because I think that besides OpenGL/Linux support, T3D also needs the latest on DX9 but also make the step to DX11. We'll see how it goes. :)

 

Yeah, total agreement there, probably from everybody ;)


The BeamNG guys have said they'll likely patch us the DX11 work they've done for their stuff, but even if that falls through for whatever reason, at minimum we can just take Anis' excellent work as a starting point, get it working and move on from there. One way or another, we'll get DX11 crammed in.

 


DX 11 you say. Hmmmm when ?

Link to comment
Share on other sites

So no DX11 in v3.9 ?

We've got it on the dockett for 3.9, probably pretty early in it's development arc.

Least that's how I read it.

 

When will the particle refactoring will introduced?

When will the PBR branch will be merged with the main line ?

@LukasPJ will have to speak for himself on the particle refactor.


For PBR, and speaking strictly for myself, I'm hoping to have all the kinks worked out well enough to make 4.0. (Wouldn't be apropriate for a point-release, since for all that it adds quite a bit, it does take a couple things away and alters folks workflows. May or may not be able to pull out some more extracts to slip in earlier, like that https://github.com/GarageGames/Torque3D/pull/855 that the levelinfo/envVolumes bit augments for fallbacks.)

Link to comment
Share on other sites

So no DX11 in v3.9 ?

We've got it on the dockett for 3.9, probably pretty early in it's development arc.

Least that's how I read it.

 

When will the particle refactoring will introduced?

When will the PBR branch will be merged with the main line ?

@LukasPJ will have to speak for himself on the particle refactor.


For PBR, and speaking strictly for myself, I'm hoping to have all the kinks worked out well enough to make 4.0. (Wouldn't be apropriate for a point-release, since for all that it adds quite a bit, it does take a couple things away and alters folks workflows. May or may not be able to pull out some more extracts to slip in earlier, like that https://github.com/GarageGames/Torque3D/pull/855 that the levelinfo/envVolumes bit augments for fallbacks.)

 

Let's hope that @LukasPJ will speak :D .


You are doing a lot of work and it looks good.


A question for you @Azaezel : Does T3d need's a ground up rework ?

Link to comment
Share on other sites

A question for you @Azaezel : Does T3d need's a ground up rework ?


Polish, yes. Total rewrite would be a disservice to current users. Not to mention that's that much more playing catchup with other engines.

 




And how much polish is required ?

What functionalities you think need to be polished ?

Link to comment
Share on other sites

And how much polish is required ?

What functionalities you think need to be polished ?

Well, folks seemed rather enamored of the notion of making classes a bit more flexible, judging by the responses to the component system proposal, so there's one.

For me, the big one once the platform agonstic and general tech update ends are considered as-given would be per-map editing. Little things, like having visually oriented tools for linking triggers to lights, or object animations and the like would speed things up for mappers. Looking forward to where @Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Link to comment
Share on other sites

And how much polish is required ?

What functionalities you think need to be polished ?

Well, folks seemed rather enamored of the notion of making classes a bit more flexible, judging by the responses to the component system proposal, so there's one.

For me, the big one once the platform agonstic and general tech update ends are considered as-given would be per-map editing. Little things, like having visually oriented tools for linking triggers to lights, or object animations and the like would speed things up for mappers. Looking forward to where @Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

 


Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.



Would ArcaneFx be a part of the main line of t3d?

Link to comment
Share on other sites

Would ArcaneFx be a part of the main line of t3d?

I know I'd like to see it make it in. Or at least the lions share. It's certainly something I incorporate for my own projects.

 


Why is so hard to do it? Is not like they changed so much in the core of the engine that is not possible to merge it .

Link to comment
Share on other sites

Why is so hard to do it? Is not like they changed so much in the core of the engine that is not possible to merge it .

 

It's not a question of technological effort. In my case at least, it's one of respect. Till http://forums.torque3d.org/viewtopic.php?f=2&t=43&start=30#p1792 gets answered from the guy that busted his hump to make it, not comfortable making that call for him.

Link to comment
Share on other sites

Looking forward to where @Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.

Thanks for your comments, I never expected to be mentioned in a T3D releases discussion thread :shock:

Sorry for the lacks of updates, I decided to cut on updates time and focus on making TorqueLab stable and clean. Also, I got back into game development and I keep updating TorqueLab to fit my game dev needs. I will try to make a new progress update soon.


It's getting quite stable and features completed (in reference of default T3D editor). What I need to do now is to cleanup and optimized my scripts. There's a lot of scripts in there...

So, since there's some interest, I will try to make a new update with reviewed installation process. Also, I started working on a pre-compiled demo using full template + UeberPack levels.


Since we are in a release discussion thread, you think some of the T3D code that cause issues with TorqueLab could be fixed? Mostly about the GuiSwatchButtonCtrl bad mGridBitmap integration which store the bitmap wrong on saving and make the engine crash on next loading. Here's a link to the code changes I made: https://github.com/NordikLab/Torque3D/commit/4b1334db9f7e5edc99e54d55b0f8ff98ea0481bb#diff-c348008717952844f31149ead72c0633


Also I have some problem with the GuiMenuBar, I can't get SubMenu items to works with stock codes. Not sure if I miss a concept about it but I made a basic hack for now, but it still need more changes. I'm thinking about making a new GuiMenu class which would work more like the MenuBar code. (Is there a simple way to expose the MenuBar class to scripts? Not familiar with that stuff...). Here's the hack I did for now: https://github.com/NordikLab/Torque3D/commit/05021ff72ffc879bd8387cba2776ca0712d61433#diff-61ad3cefe9e2956f6a06efa28c277b30

Link to comment
Share on other sites

... you think some of the T3D code that cause issues ... could be fixed?

Particularly if if you've got fixes you can PR for verification, the answer is almost always yes. (Assuming it's not a big clump of spiderwebbed mess touching 15 unrelated spots at once instead of targetting a specific issue to verify. They never seem to take those. Can't say I blame em either.)

Link to comment
Share on other sites

Looking forward to where @Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.

Thanks for your comments, I never expected to be mentioned in a T3D releases discussion thread :shock:

Sorry for the lacks of updates, I decided to cut on updates time and focus on making TorqueLab stable and clean. Also, I got back into game development and I keep updating TorqueLab to fit my game dev needs. I will try to make a new progress update soon.


It's getting quite stable and features completed (in reference of default T3D editor). What I need to do now is to cleanup and optimized my scripts. There's a lot of scripts in there...

So, since there's some interest, I will try to make a new update with reviewed installation process. Also, I started working on a pre-compiled demo using full template + UeberPack levels.


Since we are in a release discussion thread, you think some of the T3D code that cause issues with TorqueLab could be fixed? Mostly about the GuiSwatchButtonCtrl bad mGridBitmap integration which store the bitmap wrong on saving and make the engine crash on next loading. Here's a link to the code changes I made: https://github.com/NordikLab/Torque3D/commit/4b1334db9f7e5edc99e54d55b0f8ff98ea0481bb#diff-c348008717952844f31149ead72c0633


Also I have some problem with the GuiMenuBar, I can't get SubMenu items to works with stock codes. Not sure if I miss a concept about it but I made a basic hack for now, but it still need more changes. I'm thinking about making a new GuiMenu class which would work more like the MenuBar code. (Is there a simple way to expose the MenuBar class to scripts? Not familiar with that stuff...). Here's the hack I did for now: https://github.com/NordikLab/Torque3D/commit/05021ff72ffc879bd8387cba2776ca0712d61433#diff-61ad3cefe9e2956f6a06efa28c277b30

 

You do good work, so I'm all for fixing stuff you're having problems with :)


But yeah, if you have an issue with something, then by all means, put up an issue on github if it's not already there, or mention it here on the forums. A problem no one knows exists can't be fixed :P


Like Az pointed out, if you've got contributions or fixes or whatnot, they'll definitely be considered, and if you form the PR yourself with a fix, it's even easier to check and integrate. Looks like you've got a decent start with those changes already.


While several of us do a lot of the work, we definitely can't do everything, so If you think what you've got in those changes is good enough to integrate into stock, or CLOSE, but needs a bit more work*(you called the submenu changes a hack, for example), I'd say make them a PR and just notate if you think they need a bit of feedback/tweaking/discussion before integration.


It's a good way to prevent the issues from being lost, and it's easier to iterate and test to move it from 'hack' to 'ready to roll in'

Link to comment
Share on other sites

 Share

×
×
  • Create New...