Jump to content

Closing in on 3.9


JeffR

Recommended Posts

The truth is that I like the way that T3D works. It is mostly intuitive and fairly easy to use.

Like all game engines there is a learning curve.

For someone new to T3D it is just a bit confusing because a lot of the examples floating around are for older versions and

parts of the documentation are either very thin on details or just does not work as stated.


Clear with ver 4 coming out with major changes it does not make much sense to spend hours changing the current source.

I will obviously have to figure out work arounds to my problems.

Thank you to those who have made positive suggestions.

Link to comment
Share on other sites

I agree that the documentation is out of date. I agree that all features should be working as described.


There are parts of this beast that bother everyone and there are parts that bother only some of us, but there are some things that need to be added even before some of the old bugs are fixed just to draw more users. I think that the SC is trying to focus on some modernization to help bring more developers in so that there are more people with the time and inclination to jump in.


I feel that the engine belongs to everyone. If you see a problem and it really bothers you, log the bug in Github (https://github.com/GarageGames/Torque3D/issues) or fix it and make a pull request - or both. It belongs to you as much as it belongs to me.


Many features are actually genre-specific, or at least specific enough that they can't be said to apply to "most" genres - are we sure that those features need to actually be added to the engine instead of shared as a resource? Do vehicle-mounted turrets or character facial morphing really apply to my 3D chess game? Card game? Medieval RTS? Before adding something we need to ask ourselves "is this really useful in a broad sense?" Sharing these resources is probably the better option in my opinion - it lets people do more without adding bloat to the engine for people who don't need the added features. This was a guiding principal in T2D during the preparation for moving toward 3SS/MIT.


For example, I've recently updated the old RTS Prototype walkthrough/tutorial for 3.8/3.9 and I'm currently working on extending that - I keep it in a copy of the full T3D online documentation that I host on my site (http://www.roostertailgames.com/TorqueRef/index.html). While this doesn't make it easy for anyone but me to edit it does leave it accessible, and since it is an extension of the current documentation available at https://github.com/dottools/Torque3D-Documentation (MIT from the original public release) anyone is free to copy/paste if they wish. I focused on this mainly because at this time it's all I have the available time for. There are a few (very simple) engine-side changes that I want to make for it, but I'm going to document those separately. I want to keep the tutorials script-side only, but I want to make the engine-side changes available for those with the inclination to try them. Additionally, ballistic calculations and a RTS-style decal move/placement cursor don't belong in the engine in my opinion - they're things that I want for this RTS but they're not "generally applicable."

Link to comment
Share on other sites

I agree that certain things don't belong in the engine. I feel that the engine should be a generic as possible and then use a system of plugins such as dll's for Windows and whatever the equivalents are for other operating systems.

Plugins are better way of dealing with these things. The problem with compiling things in if you need them is that your version of the engine is unique and then when big changes are made to the engine it can be difficult / time consuming to adapt your special bits of code. Using plugins can make these changes easier to handle if done correctly. Obviously even with plugins you would always be free to change the core code if you wanted to. It also means you could supply end users with add-ons in the form of plugins to give new functionality without having to give an entirely new executable.

But hey my programming skills are for microcontrollers so I might be the wrong person to make these kinds of suggestions lol.

Link to comment
Share on other sites

Plugins are better way of dealing with these things.

This has crossed my mind a few times. Most of T3D is already a dll, no real reason we couldn't make the executable portion look in a specific directory for other dlls and load them. Need to expose a ton of stuff so the plugins can use the Console and TorqueScript, but though it's a lot of work it's not impossible by a long shot. I've just been too busy ("lazy") to do it myself.

Link to comment
Share on other sites

I used to program credit card terminals. They had an interesting way of working. The central core program was pre-compiled and installed. You could then compile your own code which you would register with the core as a callback. The core would then hand full control to your program on every system 'tick' or any events such as keypad, wifi, network etc. It would also pass 'handles' to the event drivers. Your program would at that stage have full control of the system. If you did not want to react to the event you would simply hand control back. The core would then pass control to the next possible program until it had gone through the callback list. When compiling your code a header file was used to allow you to call the various functions built into the core. Using this method it was possible for terminals to download additional code or update existing without changing the core program. The core was like a mini operating system in a way.


Just thought I would mention this - perhaps give some ideas :shock:

Link to comment
Share on other sites

Yeah - I'm guessing you had a well-defined set of events to handle and your plugin was required to have at least a stub for each event. I'm also guessing that your number of required stubs was fairly small, numbering in the few dozens at worst? Torque's console is well-defined but very broad - the sheer number of export/import definitions is the issue, not the method. It's not really a matter of "this is difficult" but more "this is time consuming." I've looked at it (spent about 6 hours one Saturday about two years ago) and admittedly didn't dive terribly deep, but it looks like a lot of busy-work.


But of course you don't have to take my word for it - give it a go and see what you think. In all seriousness I might have gravely overestimated the amount of work necessary because, as I say, I only spent a few hours doing some preliminary research.

Link to comment
Share on other sites

Actually the plug-in had no stubs at all.

The core program passed a pointer to a struct which the plugin examined and decided if it was something that it could handle.

If the struct contained an unknown record type then you would return with a status that it was not processed. The core then sent the record pointer to the next plugin and this went on until it came across a plugin that knew what to do with the event / data / whatever.

Being an embedded system with limited memory and CPU it was a very effecient system. It was using C not C++. So it might be even easier using C++


No its not something I would try - My C++ skills are very basic, and after many years of microcontroller programing you tend to think very differently about software - especialy when on smaller devices you only have 8K of flash to put the program in and 2K of ram for the variables :D Everything you do is about speed and using the least amount of resources, so no dynamic stuff here.

Link to comment
Share on other sites

Actually it seems like what @flysouth is discussing, is exactly what @andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

Link to comment
Share on other sites

Actually it seems like what @flysouth is discussing, is exactly what @andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

Yeah, was thinking that myself - but wasn't entirely sure. Maybe he'll chime in on it.

Link to comment
Share on other sites

Actually it seems like what @flysouth is discussing, is exactly what @andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

Yeah, was thinking that myself - but wasn't entirely sure. Maybe he'll chime in on it.

 

The theory could be reused but the actual code can't. The plugin system is obviously very specific to Torque 6, but yes, it functions pretty much exactly as its being described here.

Link to comment
Share on other sites

×
×
  • Create New...