[Azaezel]

Sorry but i don't know C++ or Torque 3D specific code to be able to contribute.

Do you want only contributors to use Torque 3D and make a wish list , while scripters and users are not important ?
When scripters make a great game i think it would give lot of prize for Torque 3D demonstrating how good it could be, or all users making tutorials, i think those users are as important as people contributing.

It's important to get more and more people that are scripters not necessary C++ contributors, more people is using Torque 3D more the community will grow.
CryEngine have a great 3D engine, but their community is empty

I have a game going on in a 3D engine that has all features i listed, until Torque 3D is able to catch up i will only follow Torque 3D progress from time to time, but starting a game in Torque 3D is a no go. There is too many things that will change and we don't know how stable it will be or how good it will perform or not.
It's like the next Torque 3D development is just beginning.

As a contributor, your PR doesn't put food on my plate, nor pay my medical bills. Shipping games I make with the engine does. Assisting folks making actually and for real games with the engine via subcontract may at times do so. This isn't a sold product, we don't get shares for tossing over our work, and nobody is collecting a paycheck while trying something for a few weeks or months. We get work in turn. So no, I don't much care for a response to a 'here's what we're working on, who wants to help' post being a set of demands to start on totally different things with no offered assistance and a side order of a threat of walking if we don't do things your way.

You've got 4 options: exercise patience, stick to commenting on what is already in development and what is listed, start a new thread trying to recruit folks to work on what you want them to work on, or walk so the rest of us can have a productive ***mutually*** beneficial discussion.

[Duion]

I want to remember people that we have a freedomsponsors page, where people can put money on features they want to have:
https://freedomsponsors.org/project/294/
If everytime someone wants something, he would put $5 or so on it, development would be soon much quicker.

It is linked on every forum page in the bottom left of the screen, maybe we need to make that icon bigger.

[Razer]

As a contributor, your PR doesn't put food on my plate, nor pay my medical bills. Shipping games I make with the engine does. Assisting folks making actually and for real games with the engine via subcontract may at times do so. This isn't a sold product, we don't get shares for tossing over our work, and nobody is collecting a paycheck while trying something for a few weeks or months. We get work in turn. So no, I don't much care for a response to a 'here's what we're working on, who wants to help' post being a set of demands to start on totally different things with no offered assistance and a side order of a threat of walking if we don't do things your way.

You've got 4 options: exercise patience, stick to commenting on what is already in development and what is listed, start a new thread trying to recruit folks to work on what you want them to work on, or walk so the rest of us can have a productive ***mutually*** beneficial discussion.

Contributors C++ will never make great games, because they are coding and don't have good art skills.
What is a good 3D Engine purpose if no one make some games and community never grows and only contributors are active on the forums ?
Remember Xenko 3D Engine ? It's a great 3D engine, but most users left.

The roadmap i put was informative about some things Torque 3D should get before it would interest me and some other people.
There is no game i'm making in Torque 3D so there is virtually no demand from me about Torque 3D features, the 3D Engine i use is already modern.

Why everyone should code C++ Torque 3D when they don't know anything about 3D engine ?
There is very different users, those fans of visual scripting or pre made game kits, and those coders that won't participate coding the engine for various reasons.
Why denying those that are not contributing ?


Torque 3D is going for modern rendering like some others 3D engines are doing even open source ones
I hope Torque 3D will become another good enough 3D engine, more choice is always better.

[Azaezel]

Yeah, I'm done wasting my time on folks sense of entitlement.

@

Happenstance: What specific aspects were you wanting to give a look at so we can see about prepping any additional notes you might want?

[Happenstance]

@ Azaezel - Good question. I think I'll need some sort of "beginners guide" or overview of the system - what's there now, what's missing, how to build a basic object out of components, maybe a "hit list" of things that still need testing, etc. It's been years at this point since I tinkered with that part of the engine so I'm going to need a little help piecing it all together.

[JeffR]

@ Happenstance I can work on a draft of the 'todo/to-convert' for the E/C stuff tonight or tomorrow to act as a springboard for you and anyone else wanting to pitch in on that end

[OTHGMars]

For the 'Further incorporation of SDL as the core platform layer, further deprecation of per-platform code' task in the General/Ongoing tasks section of the list, does anyone have any ongoing work or definite ideas of what they'd like to see there? The most specific guidance I found was in the 3.9 Release Notes. As implemented now, SDL is a platform layer with the T3D platform-independent layer riding on top. Are we talking about making SDL the platform-independent layer and removing all remains of the platform layers?

Is there a plan for how SDL is to be utilized going forward? If not, a plan should be created so all related PR's can be evaluated against the long-term goals for SDL.

One thing I'd really like is to eliminate translating input from SDL's scancode enum to T3D's enum and to carry the additional 32 bits of keycode information in the generated T3D keyEvent. This would make it possible to support all of the keyboard layouts that sdl does, eliminate some conversions from the input loop and make it much easier to interface keyboard input to external API's. References to InputObjectInstances are spread throughout the engine (mostly in guis and ActionMap), so there would be a lot of find and replace involved but nothing mentally challenging. I would raise my hand for this task if changes like this were on-the-table. The SDL_Joystick/Controller code could also have some redundant conversions removed.

If anyone has any ideas, plans or hopes for SDL utilization, please get them out in the open soon.

[Azaezel]

SDL2 inputs were actually one of the core discussion points singled out at the time for redundancy kill-off, so yeah, definitely on the table. Since this is one of those pervasive alterations that doesn't necessarily impact the general way most end-users would interact with the engine, splitting it on out to a subtask makes perfect sense there, as does leaving that as a 4.x, so no real pressure there to get it done by 4.0, though hey, if it *is* done by then, by all means.

Long term, just like with the general philosophy behind shifting from long-chain inheritance classes to E/C, the more redundancies we can prune to make for a quicker turnaround time on future development, and/or free folks up to work on the cool stuff, the better.

[Duion]

Contributors C++ will never make great games, because they are coding and don't have good art skills.

As a good artist I can tell you, that programming is the single most important skill in making games, everything else is optional.

The roadmap i put was informative about some things Torque 3D should get before it would interest me and some other people.
There is no game i'm making in Torque 3D so there is virtually no demand from me about Torque 3D features, the 3D Engine i use is already modern.

Then just add those features, if you are just waiting for others to do everything for you for free, you will probably be waiting until eternity.

[Skipper]

Regarding clean core..
JeffR your argument for clean core is basically sound.
A highly efficient and up to date open source game engine with all the bells and whistles, I am all for it.
Some questions...
Gutting the engine at this stage will take time you say, how long are we talking, weeks, months, more than a year, longer?
Feature creep is always an issue on any project, the more new ideas come on board during production the more slippage on release date.
Your second approach seems to me to be more doable - a similar idea to the modular approach to 4.0 - where PBR and other near complete features can be put in and meanwhile the backroom boys can be working on a stripped down engine that can be plugged in at a later date without too much rewiring of spaghetti.
Just my two cents worth, but what I am thinking may be worth more than two cents though is the opinions of the people who will be doing the actual donkey work.
What effect will such a major undertaking have on their ability to keep on with the core project with the same level of dedication and enthusiasm?
What are the implications of using the Torque2d core for possible future Android and iOS implementation?