Work Blog - JeffR

353 posts Page 24 of 36
Duion
Posts: 1242
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jun 25, 2018 2:11 pm
Mono and C# are not really free, Microsoft just made a promise, that they will not enforce their software patents and take down free implementaitons.

The fact that they kept it free to this day is not proof they will keep it free forever.

If you want to develop with a damocles sword over your head all the time, go ahead, but I will never do that, especially since there is no proof yet, that it will give any real benefit.
Timmy
Posts: 371
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Mon Jun 25, 2018 2:34 pm
Duion
Posts: 1242
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jun 25, 2018 2:35 pm
Microsoft has proven that they are untrustworthy, so their promise does not mean anything.
Timmy
Posts: 371
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Mon Jun 25, 2018 2:42 pm
Hang on while i grab my tin foil hat.
JeffR
Steering Committee
Steering Committee
Posts: 908
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jun 25, 2018 3:58 pm
@ Monkeychops
Lukas's work with the EngineAPI and c-interface - which is relating to his work to make the C# implementation rock-solid - definitely lend to what you're saying already. Main thing is some hangup/behavioral bits causing some grief, but the basic notion pretty much covers what you said there already, we just gotta really capitalize on it.

What I'd like in the longer term is to have even TS go through the engine API so all script languages are treated consistently, to avoid weird special-snowflake behaviors.

As for the trustworthiness of MS and the freedom of C#/Mono, it's not something I'm at all worried about. Thing is, if MS tomorrow suddenly decided to take off their mask and unveil themselves as a Scooby-Doo villain, then that just means that people willing to accept the terms of that will use C#, while others won't. Same as now.

While I'm still going to say that TS is the primary script language of Torque in the forseeable future, I also see it as a very good thing for flexibility(and making the engine easier to work with for people that don't like TS for whatever reasons they have) to enable other languages like C# as add-ons that go through the engine API. There's basically no downsides to enabling it as a solid option.
Also most likely nobody will copy over their C# from Unity to Torque, you cannot just copy a game from one engine to another.
While you're correct that game/glue code wouldn't port, premade math libraries that you can get from github and other open source libraries could absolutely be easily ported in this way, and being able to capitalize on that fact can definitely save time and effort.
HeadClot
Posts: 80
Joined: Sat Feb 07, 2015 1:29 am
by HeadClot » Mon Jun 25, 2018 6:05 pm
Hey @
User avatar
JeffR

Have a few questions / Suggestions for the clean core, Terrain, other bits of T3D and beyond.

1. Will Torque 3.11 include the new PBR lighting system and E/C work you have been doing? I am waiting for the PBR and EC system to make it into a binary version of T3D.
2. Are there any plans to upgrade to physx 3.4? From what I understand we are on 3.3 and the origin rebasing feature in 3.4 would be beneficial for much larger worlds.
3. As for terrain - What is the plan in regards to that?
Duion
Posts: 1242
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jun 25, 2018 8:00 pm

As for the trustworthiness of MS and the freedom of C#/Mono, it's not something I'm at all worried about. Thing is, if MS tomorrow suddenly decided to take off their mask and unveil themselves as a Scooby-Doo villain, then that just means that people willing to accept the terms of that will use C#, while others won't. Same as now.
They already unmasked themselves as the villain.
My point is that the main advantage with Torque3D is that it is open source, if you now keep implementing shady stuff you eventually flush the main advantage down the toilet.
Sure if someone cannot help himself and wants to implement C# he can do that, since it is open source, but please keep it out of the main repo.
JeffR
Steering Committee
Steering Committee
Posts: 908
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jun 25, 2018 9:15 pm

As for the trustworthiness of MS and the freedom of C#/Mono, it's not something I'm at all worried about. Thing is, if MS tomorrow suddenly decided to take off their mask and unveil themselves as a Scooby-Doo villain, then that just means that people willing to accept the terms of that will use C#, while others won't. Same as now.
They already unmasked themselves as the villain.
My point is that the main advantage with Torque3D is that it is open source, if you now keep implementing shady stuff you eventually flush the main advantage down the toilet.
Sure if someone cannot help himself and wants to implement C# he can do that, since it is open source, but please keep it out of the main repo.
Implementing support for C# has no negative impacts on the open-source-ness of the engine. You would be free to not utilize that plugin in your builds.
Hey @ JeffR
Have a few questions / Suggestions for the clean core, Terrain, other bits of T3D and beyond.

1. Will Torque 3.11 include the new PBR lighting system and E/C work you have been doing? I am waiting for the PBR and EC system to make it into a binary version of T3D.
2. Are there any plans to upgrade to physx 3.4? From what I understand we are on 3.3 and the origin rebasing feature in 3.4 would be beneficial for much larger worlds.
3. As for terrain - What is the plan in regards to that?
1) E/C yes, PBR no.
With the E/C stuff, it's much easier to leave the existing game classes in place(just flagged as deprecated) while pushing for the E/C stuff and various premade GameObjects to act as replacements for the old game classes like Player. for PBR though, you either use PBR or not, so it's definitely a larger, breaking change.

2) Yep. There was some compaitibilty issues with VS2017 and 3.4, but it sounds like recent updates to both have resolved that. I'll be testing on that tonight or tomorrow so we can get that PR rolled in.

3) Quite a number of things have been discussed, but we haven't fully pegged on anything concrete yet. Major topics involve it being easier to stitch terrain together so you can make larger worlds without having to do a lot of weird juggling of terrain blocks. It should just be a natural thing to expand the terrain's scope. Likewise being able to go back and adjust texture and terrain mesh densities, so you can tweak stuff without having to start all over, because duh ;)
The other future considerations would be either small tweaks to the current means of texturing so it's a bit easier to comprehend(adjusting names of texture maps in the editor, etc) but we've also been mulling on just jumping straight to full Virtual Textures. Using VTs means an overhaul on the toolset, but it'd work far better for artists(since you'd just paint down the material into the map, blending would happen as part of the paint action, not a blit-at-runtime bit of render voodoo), and would be WAY more efficient to render.
Happenstance
Posts: 77
Joined: Sat Apr 11, 2015 9:08 pm
by Happenstance » Mon Jun 25, 2018 11:35 pm
Andrew had the right idea with Torque6. T2D's codebase has Melv's historically clean, well-documented coding style and although it was outdated from day one and is outclassed by other 2D engines, was a real pleasure to work with so I'd support a move in that direction. I'd even go as far as to say a change of this magnitude is long overdue.

My concerns with all of this are:

1). T3D's usability right now is pretty low, especially for new users. 3.10 is the "public facing" build but it's outdated and a hassle to compile. Anyone forking the master branch has to jump through hoops setting up CMake, finding a now ancient copy of the DXSDK, working around whatever weird VS bugs still exist, etc. and then once they finally do compile they're greeted by an overwhelming Full template that doesn't help them make much of anything. It's not a great first experience for a new user and makes retaining them all the more difficult.

2). There are only a handful of people actively developing the engine and of those handful only a couple are pushing the "4.0 tech" (PBR, etc.). We're one argument, illness, or distraction away from losing a significant contributor and potentially roadblocking development in a big way. Something similar happened last year with the Atomic Game Engine. It had a small but active community built up around it but once Josh Engebretson left (anyone remember him, Minions of Mirth fame?) development came to a screeching halt and now it's dead.

In my opinion, there needs to be a solid amount of work done (like, yesterday) to get a 3.11 release out that includes the bug fixes, new templates, and removal of DX9/SDK requirements from the dev branch. At this point I would mark 3.11 as the "End-of-Life" version and start on TorqueNext (or whatever) - with PBR, E/C, clean core, and so on while breaking backward compatibility in any way necessary to move forward. I would also make a serious effort to revitalize the steering committee so we're not depending on one or two active people to handle all pull requests, etc.
Duion
Posts: 1242
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Tue Jun 26, 2018 12:48 am
Andrew had the right idea with Torque6. T2D's codebase has Melv's historically clean, well-documented coding style and although it was outdated from day one and is outclassed by other 2D engines, was a real pleasure to work with so I'd support a move in that direction. I'd even go as far as to say a change of this magnitude is long overdue.
It was not the right idea, how is it the right idea to start from scratch and setting yourself back for years? This only works, if you have a team and Andrew said, he just made it as a portfolio work, so he can get hired, so sooner or later it will have gotten abandoned anyway.

Regarding developing the engine, we could at least need some people in the steering committee handling the pull requests and stuff, the job of the committee was never intended to do all the work, they were just supposed to do things like pull requests and guide the direction the engine will develop.
So who volunteers for that position? It is not very efficient to have JeffR doing engine development AND handling all the pull requests.

So who volunteers?
353 posts Page 24 of 36

Who is online

Users browsing this forum: No registered users and 3 guests