Bloodknight

A quick track might be able to nail down a potential driver issue is to get release dates of drivers and the dates of player issues and do a quick compare.

Also, AMD will have a bunch of people who take pretty specific issues like this and attack them from their end, its worth making contact with somebody at AMD to see how to get hold of the devs there.

perhaps if information was posted by the OP instead of a random youtube video we wouldnt be here at all.

if you post a picture or a video its to show off.

If you want a discussion you add information.

If you want to highlight something specific you add information.

Because of piss poor information, people ask questions, its not up to the users here to google search for information regarding the video, this should have been provided, or at least a link to the page that discusses the concept that the video is showing off.

as for ruining the thread.

People who asked questions are being attacked, by a user who neither uses torque or even promotes the use of torque, in fact torque users here are being attacked by somebody who actively *actively* talks up other engines in this community as well as *actively* talking down the torque engine

1) there was no discussion ever in this thread, it started with questions and was hijacked by unity fanboy

2) the first person to start using provocative/evocative commentary was *REDACTED*

3) the only person shitting on other people here is *REDACTED*

4) the only person who continually talks down torque *REDACTED*

As a final note regardless of this being a general forum, it is a general forum of a torque community, it is a general forum of a game development community. Regardless of the generality it would be sensible to make posts about those two things. While this video is made using a game engine, its pretty simple to increase rendering quality if you remove all *game* from scenes. The fact that the video shows unity competing with blender (and potentially winning depending on your view) should have been highlighted in the text if the OP, so now we've come full circle.

nb: @deathbravo no. this is torque community vs unity community, the problem is that we have unity fanboys masquerading as torque community members

So as to not hijack http://forums.torque3d.org/viewtopic.php?f=15&t=677&start=20 thread anymore than already has done, i figured best a separate discussion.

While some platforms are a special case *android* in particular, many others are simply variations of the PC world, the problem as i see it is the fact there are only tiny pools of interest in non windows PC gaming platforms, and even tinier still the pools of expertise within those groups to be able to get the engine running well.

Part of the difficulty i believe lies in the fact that 'fringe builds' are not tested well enough, so that the few who are developing platform specific fixes are not getting enough feedback.

I'm not sure the best approaches for addressing this, while some will argue that linux is linux, the fact is theres a whole plethora of variances in linux distros which potentially cause issues, to such an extent that even some linux distros are being blacklisted by linux software developers. Perhaps what we need is a list of most used desktop linux flavours so that we could at least target those (and yes irritated purists this is going to involve ubuntu).

As far as macs... not sure how the hell that works, in Europe at least only rich pretentious hipsters own macs because of the prohibitive price tags, US base devs might be able to access the stuff more readily, but even in the US the mac crowd is much smaller than the linux crowd.

I know at least there are several devs that use windows as well as linux, but not all of us use torque specifically on linux. A properly formed list of things to test across different platforms might be useful because honestly i dont even know where i would start without switching platforms to work the majority of the time.

if this comes across as sarcastic then so be it :p

keeping up with other engines... other engines have dozens of full time paid engine developers.

stopping work on advancing the engine just so that... cross platform compatibility work can catch up, is a pretty good way of ruining a product even if you have people available to work on that particular task, its even more ridiculous if you have nobody to work on that task.

macs are a tiny part of the PC market, i'm not even sure gaming on macs is even remotely on par with gaming on linux outside of the USA, i'm not even sure it has parity even in the USA tbh.

So just to re-iterate, there is no point in stopping the few people who are contributing to the engine, this wont get mac compatibility done any quicker, in fact it will destroy whats left of the userbase because the majority of the users who can use the engine are no longer getting updates.

trying to run and trying to compile are pretty different things, while compiling 32bit can be awkward especially with regard to external libraries, the multiarch gcc package should make everything work fine so long as the correct flags are set in your makefile.

As for running adding the i386 architecture has always solved the issue for me, but then again ive not run especially complex software out of native space.

Considering there are a number of people in this community who are or were trusted with the future of torque; and are constantly shit talking about torque and constantly telling the rest of the community how much better other products are than torque i think in general most of the community are very tempered compared to other communities.

Also considering the level of vile members in the unity community, and the past history has had with that vile sect within the unity community, i'm honestly surprised that defensive is as 'offensive' as some people get

the lines are blurring, and have been for some time, vim was always just an editor with some decent plugins, now theres a variety of plugins to turn it into an IDE and even some guis that turn it into a full ide, many of the text editors especially the newer ones have the ability to compile on command, when the ability to debug in text editors is ironed out the transformation will be complete.

however there are still a lot of people especially on linux that spend an inordinate amount of time typing make into a terminal rather than clicking on the run button, and tbh torque script editing is much more like that for many people, and will be for many more when autoloading and autorunning overwritten functions become a thing in T3D. At which point the text editor and its corrected syntax highlighting become a more useful tool; imo.

as for the NPP thing, yeah i tried it before managed to screw up notepad... dont ask, its a gift :p

ive seen that page and frankly, it needs to be rewritten so that

1) its written by somebody who doesnt dispise torquescript and or windows.

2) uses software developed this century.

3) doesnt actually scare the living shit out of potential developers.

vim seriously, apart from superiority complex, antique and bristly microsoft haters pretty much nobody really uses vim. :p

most of the other options are old open source software with some hacked together half working syntax, again developed for much older version of the engines so not much more than the half baked syntax highlighting even works anymore.

The potential saving grace here is that the two leading windows contenders are now open source, it would do the community better if one was picked and modernised, and possibly made cross platform.

This conversation has gotten wholly sidetracked, probably all my fault, but really all i was trying to point out was that a small amount of work potentially fixes most of the problems associated with the extension 'problem'.

The only real problem i see with .cs is the C# conflict for those who develop in C# most of whom will be using Visual Studio simply because of its superiority in its domain, other C# devs who use a 'one editor to rule them all' system like atom or VS code or sublime etc only have issues of highlighting which i dont really see an alternative to extension change as a solution.

it does however need pointing out that for those who do have issues with the extension, the ability to change the extension for a particular project is pretty trivial, and tbh its something i might possibly recommend anyway.

@Johxz got some details on that download, like engine version etc?

The FPS tutorial was always out of date and problematic, this was true even when GG was still managing everything, i'm not sure who has the most uptodate versions, it may well be worth finding and following some forks to see who has the newest.

If you are running just to get some learning done, it may well be worth finding a version that matches up with an older more stable engine version, most likely to be 3.5 at a guess.

I wasnt trying to be deliberately awkward, part of this comes from the fact that in the past non issues have been made issues simply by use of an executable built elsewhere.

Something else to consider is the fact that there are a large number of potential executables that are needed for the many things that need testing. Two different platforms both with 32 or 64 bit options 3 different renderers on windows (assuming opengl is only one and not sure if that is actually the case) 3 different physics implementations. Depending how you choose to combine them thats somewhere between 15 and 30+ base configurations

While i do to some extent agree with your positive case, i firmly believe that concise building instructions should be pushed into the faces of everyone who downloads torque.

Another alternative if this is really beneficial, is to utilise CI builds, they should be able to automate all cases of exe production so that you have to hand all main alternatives for those people who d not have time and patience to install all of the not included development libraries/SDKs.

As i recall, development branch is classified as an unstable non production branch.

it is also mostly assumed that people tinkering with development branches are in fact devs and can create their own executable.

The only easily available executable(s) should be the latest tagged release versions or at most release candidate versions for testing.

The alternative i guess would be a "nightly build" system that seems to be gaining popularity, but even that needs to be covered by some form of disclaimer in my opinion.

somewhere in the code there exists a 20k ish poly cap per mesh, which roughly translates to a 60k vertex limit, this is an old TGE limitation of a very old DTS format.

What this means in real terms is that the exporter crashes if you have meshes above a certain size, options are either make more meshes by splitting them down, or export using collada (not sure how that works, back when i tested this collada was experimental, in torque terms and many others).

dont know if the chris robertson dts+ exporter has the same limitations, https://github.com/nzchris/ms2dtsExporterPlus or maybe you can hack the exporter to fix it :)

i'm not even sure what it is supposed to be highlighting.

Also, a lot of unity tech while very nice isnt actually real time, the environment for example will use baked in shadows and ambient occlusion, these two things alone make any environment look hugely better than any real time alternatives.

The rest is doable in any other game engine you can get the models into.

I'd be interested in seeing how long it took to create versus say a blender short movie

I'm pretty much on the fence with this.

Identifiable pros

The .cs is handy as it does trigger rudimentary (but incorrect) highlighting in most common editors, this highlighting is enough to aid navigation and readability for the most part.

identifiable cons.

If you've installed visual studio *after* your common editors, it hijacks the launch via extension. On my system at least this lumbering beats takes a while to start up before it can be shut down.

Identifiable work regardless of pro/con.

Extension needs to be assigned to the correct editor.

Editor needs to have the correct highlighting. you can add .ts .tsc to the C/C++/C# highlighting lists of most editors anyway

(side note, notepad++ gets quite pissy when trying to reassign .cs files to C or C++ highlighting.)

Seems to me that there are several issues here regardless of the actual extension.

The main one being lack of 'correct' syntax highlighting in many editors. So, regardless of extension changing perhaps the people who are good at editing such things could make functioning syntax highlighters for their favourite editors. I have seen a notepad++ one in the past, cant find it now, i also seem to think it wasnt quite right.

So to all you atom/sublime/notepad/VScode users out there, would you consider making a highlighter plugin for torque, we can always make minor changes if the extension changes.

If you edit parts of the CS file that torque writes to then, its to be expected that the torque overwrites those changes if you use a tool that writes your work.

That being said, auto capitalisation of words is the domain, or grammar and spelling correction applications such as word processors, perhaps a global setting to allow/disallow the engine from making such decisions would be useful.

I think there is some slight confusion over a single word here.

A single model can contain single or multi track animations. As far as i am aware, the first track in a model is called ambient by torque, simply because as was state earlier 'ambient' can be switched on and played automatically by a tsstatic object.

All other models have more complex animation needs, speed of animation, multiple animations, all of which can be accessed in many ways.

Single track named segments, where you name parts of the track as explained by dwarfking.

Multi track, where each animation is named and separate inside the model.

Also if you are clever regarding your skeleton and animation designs you can turn each animation into a .DSQ file in a similar way to how Chris calef describes, the advantage here is that you can use all premade animations on all new character models if the root pose and rigging are the same.

So all in all there are several ways of working

huh, maybe i liked it twice as much as others :)

In that particular category it was pretty difficult to find a completely free does it all solution, almost everything is now falling under the category of 'freemium' which is fine for commercial solutions, but OS projects soon get past the barriers they put up, and once past that the prices hike astronomically

https://github.com/OTHGMars/Torque3D/tree/mount_object_ex

this is the source of the work done as far as i can tell, i'm not sure it made it to a PR even much less the engine, or at least my search turned up nothing.

Maybe that will give you a head start if nothing else

[/size]Torque 3D MIT Uservoice Wishlist[/size]

This is the complete list of wishes from the garage games uservoice, I intend to relist them in some orderly fashion.

Some are done, some are works in progress, some despite wishful thinking are never likely to happen, especially with the current manpower issues, these along selected items from the other places where features are requested can form the goto list if you want to work on the engine, or users can add their own to the list and start work.

If you are working on one of these and wish to say so, I can put your @link next to them so people who want to help with specific parts

Also I've no idea how this clashes with jeffs new posts, if it does then... I've prepared a list for him :p

• Add full support for Linux Operating Systems to Torque 3D
  
• Multiple CPU Core Usage (for skinned meshes especially)
  
• A new scripting language
  
• Shader Composer / Material Editor
  
• Open GL 4.x support for Torque3D
  
• Add full support for Mac OS X to Torque 3D
  
• AI System - Navgraph, planner, fuzzy state machine
  
• Physical Based Lighting/Shader (PBR)
  
• A system like kismet from unreal engine 3
  
• DX11 Support
  
• Global Illumination
  
• Update the Terrain System
  
• Inverse Kinematics for character animation
  
• Export to mobile platforms
  
• weather system
  
• Create an Open Source Alternative to Torsion
  
• GUI system Overhaul for Torque 3D
  
• Terrain Streaming or Paging
  
• Wind animation and collision support for groundcover objects
  
• 3d skybox
  
• Multiple Viewports in World Editor
  
• Revamp the Shadow system
  
• Better support for MinGW compilers
  
• Upgraded sketch tool
  
• Advanced snapping options
  
• hitboxes aka locational damage
  
• KEY FEATURE - Please keep Torque-3D-Linux Generic (Non-Os and Non-Version specific! )
  
• Animation Blending
  
• Add Torque3D to Steam Greenlight
  
• Steps in the FPS Tutorial for how to compile Torque3D for the first time.
  
• CgFX Shader Language integration
  
• Use a Plug-in Architecture so all the Add-ons could work together
  
• Add full support for Linux Operating Systems to Torque 2D
  
• Convert data serialization over to use TAML
  
• In game cinematics
  
• More Full Featured templates/Starter kits
  
• Forest Editor to support multiple forest objects per mission
  
• Play through web page, with streaming capabilities
  
• Support for Intel Graphics Cards
  
• Displacement map option.
  
• Core Engine refactor with Core Plus modules
  
• PhysX vehicle
  
• C# implemented
  
• Light animation for the emissive material
  
• wetness PostFX and wetness custom material
  
• Torque Smart ptr: Shared, Weak, and Scoped
  
• Seperate Sever from Client
  
• XMLVM toolchain for cross compiling to .Net, iOS, Android and Java
  
• A scripting language like GML (Game Maker Language)
  
• Realistic Skin Shader
  
• Rim Lighting Shader
  
• screenspace lightning
  
• Elevation mask for terrain-painting and new filling function
  
• Add placement of physicsForce objects to the World Editor
  
• Re-add terrain erosion
  
• More efficient / intuitive handling of the editor
  
• Add TorqueScript Prefab methods
  
• Additional options for forest/mesh painting
  
• Phong Tesselation
  
• More Simgroups/better managing (forest items, terrain materials...)
  
• Bigger brushes
  
• Marble Class
  
• Vehicle steering return-to-centre
  
• Better Zip file functionality
  
• Occlusion Volume
  
• RayInfo distance with ContainerRayCast
  
• Database: Simple and Complex
  
• MVC Design Pattern (Component System?)
  
• An unreal mesh paint like editor hooked into shadergen
  
• SetDPIAware()
  
• Add terrain layer sensitivity to the forest
  
• Enable looping for GuiTheoraCtrl.
  
• Zone Update
  
• Support for exporting game to the Flash platform
  
• Ai poses and ContactTimer Pack/Unpack update fix (already in resources)
  
• T2D Style Toybox System
  
• beefing up the sketch tool
  
• Jitter in terrain system between terrain and models
  
• Feature: "externalCommand" for Torque 3D
  
• GuiHealthHud - a C++ replacement for the scripted numerical health hud
  
• Improved Color Picker
  
• Add new GuiBitmapStringCtrl that strings a number of images

Art and level development

*Interior/structure designer like Constructor

*Prefab object that combines models and scripts

*Improve forest editor

*Beefing up the sketch tool

*Beef up the material editor

*Fix the Shadow system

*Jitter in terrain system between terrain and models

*Add weather system

*Better snapping system

*Better Zip file functionality

*Re-add terrain erosion

*Add terrain specular, and if needs be, remove parallax from the terrain pass to make way for it, but retain parallax for shapes.

*Add the ability to set a kind of 'alpha mask' for the terrain tools, so you can set the strength & shape of the tools a bit more specifically.

*Add more flexibility in the noise tool again, maybe being able to set a tiled heightmap mask to it so you can again control the behaviour of it better depending on design requirements.

*Water... although I haven't played around with it in recent builds, and it may have been changed since I have used it properly, the settings for water could really be simplified down to make it more user-friendly, a lot of the settings are awkwardly named considering their effects on the water blocks.

*A basic precipitation and particle library

*Add split screen "viewports"

*Better terrain materials manager

*Add a semi "auto-zone" widget kinda thing. for example selecting a building shape, and at the click of a button, create a "zone" item matching its bounds etc.

*Ground Cover needs collision support

*Add terrain layer sensitivity to the forest

*Improve character import

*Add more keyboard shortcuts and show on the menu

*Light bleeding through the seems

*Possibly change the ground cover and forest editor to be 2 more generalized editors

*when standing outside of a zone, particles and lights are visible that are created inside of it. the only way that they should be visible is by looking inside the zone through a portal.

*Occlusion Volume. It should have a switch that allows it to effect the terrain behind it or not. As it stands, it causes the terrain to disappear behind it, which u don't always want.

*More 3D imports

*Artist friendly - add sliders along w numbers input

*SKYBOX and SCATTER SKY should work together somehow

*Better animation blending

everything that says 'improve' or one of its 20 million gazillion alternative ways to say improve need moving to a separate list, since clearly, the feature exists in some form, also to some extent they are the most pointless and irritating *wishes* in list form, they need to be discussed.

if you believe this is an important area of work, take an item and create its own thread, make sensible suggestions and notes about what is missing of needs adding/enhancing.

TODO Note: Rework to new thread with appropriate separation.

So having derailed the roadmap thing, i did some looking to find *stuff* while this is possibly a waste of time since status quos are almost impossible to shift, and new things are new and people dont generally like new things since its adding a learning curve. unless its a new faddy buzzword and then for some reason everyone promotes it as the best thing ever.

Anyway here are some alternatives to things current or no longer used with regards to projects and management and stuff, mainly for the current devs and SC to look at and see if they think it might help with the development. As for criteria, all of these projects are both open source and self hosting capable (with the exception of trello which is still usable in its free state).

The astute will also note that there is some crossover of products, this is a side effect of the defective thinking that there should be One software to do everything, as such there are some *complete* products in here too

Trello alternatives

https://trello.com/

https://www.mycollab.com/

http://taskboard.matthewross.me/

http://kanboard.net/

https://wekan.io/

http://restya.com/board/

Project Management

https://www.openproject.org/

https://taiga.io/

https://www.openproject.org/

http://www.redmine.org/

http://info.tiki.org/tiki-index.php

Bug/issue tracking

https://www.bugzilla.org/

http://www.thebuggenie.com/

http://www.mantisbt.org/

http://www.flyspray.org/

http://trac.edgewall.org/

One advantage here is that self hosting options allow you to have a single domain control over multiple products that do a singular task well, rather than 20 tasks badly.

I am under no illusion that this is likely to change anything, but i figured it was worth an hour or so looking at and picking out some notable products for at least a quick look by others if nothing else.

I should however point out that regardless of how good any item of software is at doing what it should, if the project is unmanaged or mismanaged you get the same problems as the current github management system.

It may also be noted that some changes to the management of github would help rectify some of the issues that i think exist, and that is an equally valid thing to do as get extra softwares involved.

There is no right or wrong here... unless you consider the status quo, at which point i personally feel that it is wrong :p

I think a section specifically for peoples games projects would be useful, a bit like the related technology section but for games.

There are already a few e.g. FreeRPG and Uerbergame, i understand some projects have their own websites and stuff but some dont

just a thought :)

EDIT: Torque implements some kind of instancing but it can make the situation even worse https://github.com/GarageGames/Torque3D/issues/678

Just to address this particular thing

If you are building a very large level with a lot of duplicated resources, this includes props as well as floor/wall/corner parts the batching system would have clear speed benefits.

If you are building a more organic level with more varied props, for example even a simple cube with 50 different textures on it is classed as 50 different cubes so batching doesnt recognise these.

As you can see from my question there are as of yet no metrics, however, if you try and fiddle with the values i'm pretty sure that if you use much repetition of models at all then there will be a setting value that at least helps a little.

just to speak out against everyone else...

Torque has a batching system that batches identica models into a single drawcall, so for example, if you are constructing a room out of 3 models (1 corner 1 wall and 1 floor) regardless of how big or small the room is you should be able to narrow that down to 3 drawcalls.

Now 3 might seem much more than one, untill you start building, extra rooms, when you have 4 different rooms you are already making less drawcalls than the system that makes single model rooms.

either way works just as well, but it depends what your usage is, frankly if the models get too big and unwieldy then you have other potential problems, it also takes level design out of the hands of designers and puts them into the hands of the artists, the ideal nowadays would be something between, this would allow you to have more 'organic' looking level parts (think caves in oblivion/skyrim) vs traditional square dungeons (think legend of grimrock).

It would also depend a lot on what your gametype is, and how you want to implement indoor/outdoor transition, if you wet with a NWN style transition (teleport to new zone) then torque would naturally hold thousands of building interiors, just wrap them in zones with no portals. If you are building counterstrike levels, honestly i cant think of anything more troublesome and development slowing than relying on an artist to fix up the level every time you have a fault because the level is one big model.

the scattering information i meant was for userspace specifically, with at least a couple of places with 'how to help' and specific help needed.

While i understand you and others have no issue, this goes partially to what i meant about adding new project management systems, and holding myself as a user in the middle in some respects. I have used various systems, some more complex than others some more obscure than others.

Github in my opinion is possibly the most user unfriendly system ive seen after redmine (I had a quote lined up about complexity vs friendliness but i lost it now), the worst part imo is the issues system which is nothing but a messy fucked up melting pot of ideas, issues, bugs, and the another 50% of stuff people dont actually give a rats ass about; Navigating this one useless ass system itself is a mini nightmare since only the overlords can but don't (in a timely fashion) actually decide what criteria a post fits in. This imo should be replaced with a real and dedicated bug tracking system

As the above shows, some people dont get along with the current system as much as others, we have massively reduced working portion of the community, changing to something they do not recognise is not something that should be done; the possible exceptions are:

• Other systems that the current developers use
  
• A discussion followed by shortlisting that highlights a system that would likely get more members of the community involved at a deeper level*
  
• * the above has to not exclude current busy developers

As far as the milestones page is concerned, while its mostly what Johxz and the rest need regards a roadmap, i has in the past been very 'flexible' in some instances this cannot be helped, especially if you consider the mistake of actually adding a timeline to a project of this type. but even some features have been moved from one release to the next. Features get added, others slip back, developers disappear, new ones come. (Please note that these are not necessarily criticisms, more of a detailed 'this is how it is now' kind of thing)

I also do not currently have a solution to this particular problem, especially since most code is added on a voluntary basis based on the development of other peoples projects. I do think however that some features listed in the milestones (excluding bugs) could be weighted in terms of 'this is what the engine needs' regardless of what people are working on; this at least would provide a todo list of importance should other/new people want to engage.

Another thing that might be useful is some form of who is working on a task, while that might seem silly now since Az has his fingers in almost every pie, and jeff almost as bad, and this is where shows a lack of features. for example, i know that az and timmy are the go to people regarding the physx and dx11 if i want to help on that particular feature, but without digging into contributors of the branch thats a difficult thing to know.

now ive thoroughly derailed the original thread i'll go hang my head in shame somewhere