Tgea Vs Leadwerks 2.0 Engine
by Morrie · in General Discussion · 05/02/2008 (12:40 pm) · 50 replies
Leadwerks Engine 2.0 Features
Rendering
* Unified per-pixel lighting system with dynamic soft shadows; Every object casts and receives shadows.
* Point, spot, and directional lights.
* Masked shadows for tree and plant effects.
* Specular reflection and normal mapping.
* Parallax mapping.
* Fast instanced mesh rendering.
* Dynamic visibility determination, requiring no pre-placed portals or compiling.
* Hardware skinning for fast animation.
* Bloom, depth-of-field, motion blur, and other post-processing effects.
* Fast hardware particle effects.
* Seamless transitions between indoor and outdoor areas.
* Adjustable rendering viewports.
* Support for ambient occlusion maps.
* Render to any graphics context to create Windowed applications and tools.
* Render to texture.
* Lens flare effects.
* Dynamic shader management chooses from thousands of variations and compiles requested shaders on-the-fly.
* Open-ended materials and shader system.
* Use existing shaders or add your own.
* Optimized rendering pathways for Shader Model 4.0, with render fallbacks for older hardware.
* Features can be scaled to accommodate older hardware.
* Load textures from .dds, .png, .tga, .bmp, and .jpg files.
Meshes
* Load .obj, .md3, and .gmf meshes, or create meshes from scratch.
* Support for animated meshes with fast hardware skinning.
* Create box, cylinder, sphere, cone, and plane primitives.
* Support for arbitrary number of LOD versions.
* Fast mesh rendering using GPU instancing, if available.
Terrain
* Huge landscapes with up to 33 million triangles.
* Simulate areas up to 650 square miles.
* Dynamic lighting and self-shadowing terrain allow day/night cycles and weather effects.
* Modify terrain in real time.
* Vegetation layers can simulate millions of plants.
* Alpha-blended tiling terrain.
Animation
* Hardware skinning for fast animation.
* Blend animations, or mix hard-coded actions or physics with animation.
* Attach weapons or items to animated limbs.
* Attach physics bodies to limbs for animated collision and locational damage.
Physics
* Support for multi-core CPU acceleration.
* Simulate thousands of rigid bodies.
* Create complex machines with ball, hinge, corkscrew, slider, universal, and fixed joints.
* Physics vehicles with any number and configuration of tires.
* Extremely fast solver, with far greater stability than any other physics engine on the market.
* Collisions with polygon meshes, convex hulls, boxes, cylinders, cones, spheres, chamfer cylinders, and capsules, or compound collisions made up of any combination thereof.
* Player controller simulates player movement while participating in complex physics interactions.
* Customizable collision system with support for any number and scheme of collision types and interactions.
* Powered by Newton Archimedes
Rendering
* Unified per-pixel lighting system with dynamic soft shadows; Every object casts and receives shadows.
* Point, spot, and directional lights.
* Masked shadows for tree and plant effects.
* Specular reflection and normal mapping.
* Parallax mapping.
* Fast instanced mesh rendering.
* Dynamic visibility determination, requiring no pre-placed portals or compiling.
* Hardware skinning for fast animation.
* Bloom, depth-of-field, motion blur, and other post-processing effects.
* Fast hardware particle effects.
* Seamless transitions between indoor and outdoor areas.
* Adjustable rendering viewports.
* Support for ambient occlusion maps.
* Render to any graphics context to create Windowed applications and tools.
* Render to texture.
* Lens flare effects.
* Dynamic shader management chooses from thousands of variations and compiles requested shaders on-the-fly.
* Open-ended materials and shader system.
* Use existing shaders or add your own.
* Optimized rendering pathways for Shader Model 4.0, with render fallbacks for older hardware.
* Features can be scaled to accommodate older hardware.
* Load textures from .dds, .png, .tga, .bmp, and .jpg files.
Meshes
* Load .obj, .md3, and .gmf meshes, or create meshes from scratch.
* Support for animated meshes with fast hardware skinning.
* Create box, cylinder, sphere, cone, and plane primitives.
* Support for arbitrary number of LOD versions.
* Fast mesh rendering using GPU instancing, if available.
Terrain
* Huge landscapes with up to 33 million triangles.
* Simulate areas up to 650 square miles.
* Dynamic lighting and self-shadowing terrain allow day/night cycles and weather effects.
* Modify terrain in real time.
* Vegetation layers can simulate millions of plants.
* Alpha-blended tiling terrain.
Animation
* Hardware skinning for fast animation.
* Blend animations, or mix hard-coded actions or physics with animation.
* Attach weapons or items to animated limbs.
* Attach physics bodies to limbs for animated collision and locational damage.
Physics
* Support for multi-core CPU acceleration.
* Simulate thousands of rigid bodies.
* Create complex machines with ball, hinge, corkscrew, slider, universal, and fixed joints.
* Physics vehicles with any number and configuration of tires.
* Extremely fast solver, with far greater stability than any other physics engine on the market.
* Collisions with polygon meshes, convex hulls, boxes, cylinders, cones, spheres, chamfer cylinders, and capsules, or compound collisions made up of any combination thereof.
* Player controller simulates player movement while participating in complex physics interactions.
* Customizable collision system with support for any number and scheme of collision types and interactions.
* Powered by Newton Archimedes
#22
Any development package takes time to learn. I spent the same amount of time with pure homebrew C++ and Ogre3D, and got to the same point I am with TGE, but my "game" had better graphics, and was far easier to add new features to, without having to worry about 20 other things breaking for stupid reasons.
Most other engines I've toyed with had "simulation" quality features- ie, certain features were being calculated, instead of being faked, or hacked in. Most things seem to be this way with TGE (not sure about TGEA, don't care either!), meaning if you want realistic physics for example, be prepared to spend more time re-coding large chunks of the engine, than working on your game.
Shaders? What's that? TGE doesn't know out of the box. Shaders have been around for a long time. So has TGE. Why haven't they met yet? Oh yeah, they did- and had a child called TGEA that costs more money. Lovely.
Terrain with LOW resolution textures? Oh yeah, we've got that. Wait, people actually use textures larger than 256px^2? Crazy fools! They must be trying to break something! We don't need no hi-res terrains! That's for little kids who want to make an MMO! Give me a break.
Last update I saw to TGE had something to do with implementing TLK. Wow. Impressive. Should I be shocked or something?
Okay, so I've figured out the brass tax of how GG and it's products are successful. Time and money. They've been around longer, and pulled in the indie audience when the engine actually was worth it's weight. They've spent the money to advertise (and a lot too). If you took TGE and threw it on the market day 1, this year- it wouldn't stand a chance against the likes of Leadwerks or C4. I can almost guaruntee that with time, the new kids on the block will be pulling more of the market away as well. I know I see a few people on a weekly (at the least) on the Ogre forums saying they left Torque out of frustration of it's crustiness...
Now this is just me whining again I suppose, but I've asked multiple times for a list of published games that used TGE/TGEA. Everyone always points at Marble Blast... Okay, I got. Tribes. Right, got that too. What else though? I'm not relying on those results to make my game, that has nothing to do with it. I just want to see what others have done, that's gone to market, to see reviews and features. Then I'll compare that list to the ones for the other engines out there.
06/19/2008 (9:37 pm)
Why does it seem that the "card up the sleeve" for Torque always comes down to networking? I've compared multiple engines, both commercial closed source and free open source. Honestly, Torque is minimally better than any of them.Any development package takes time to learn. I spent the same amount of time with pure homebrew C++ and Ogre3D, and got to the same point I am with TGE, but my "game" had better graphics, and was far easier to add new features to, without having to worry about 20 other things breaking for stupid reasons.
Most other engines I've toyed with had "simulation" quality features- ie, certain features were being calculated, instead of being faked, or hacked in. Most things seem to be this way with TGE (not sure about TGEA, don't care either!), meaning if you want realistic physics for example, be prepared to spend more time re-coding large chunks of the engine, than working on your game.
Shaders? What's that? TGE doesn't know out of the box. Shaders have been around for a long time. So has TGE. Why haven't they met yet? Oh yeah, they did- and had a child called TGEA that costs more money. Lovely.
Terrain with LOW resolution textures? Oh yeah, we've got that. Wait, people actually use textures larger than 256px^2? Crazy fools! They must be trying to break something! We don't need no hi-res terrains! That's for little kids who want to make an MMO! Give me a break.
Last update I saw to TGE had something to do with implementing TLK. Wow. Impressive. Should I be shocked or something?
Okay, so I've figured out the brass tax of how GG and it's products are successful. Time and money. They've been around longer, and pulled in the indie audience when the engine actually was worth it's weight. They've spent the money to advertise (and a lot too). If you took TGE and threw it on the market day 1, this year- it wouldn't stand a chance against the likes of Leadwerks or C4. I can almost guaruntee that with time, the new kids on the block will be pulling more of the market away as well. I know I see a few people on a weekly (at the least) on the Ogre forums saying they left Torque out of frustration of it's crustiness...
Now this is just me whining again I suppose, but I've asked multiple times for a list of published games that used TGE/TGEA. Everyone always points at Marble Blast... Okay, I got. Tribes. Right, got that too. What else though? I'm not relying on those results to make my game, that has nothing to do with it. I just want to see what others have done, that's gone to market, to see reviews and features. Then I'll compare that list to the ones for the other engines out there.
#23
As for the terrain comments..GG has said many many many times why the textures are [u]still[/u] 256^2. I dont know why they havent changed it since the late 90's, but I think its a bit late to bitch about something that hasnt changed in 10 years.
TGEA took 4? years to develop into something somewhat useable. Why wouldnt GG charge extra money for it? Like I said in my other post, in order to make TGE be what TGEA is, it would take some major recoding and it would be almost impossible. It was easier to make a totaly new engine then to add shinny shaders and hi-res textures on terrains. TGE was ready for a change, and that change meant that something better had to be made.
06/19/2008 (11:12 pm)
Nathan, firstly I want to put a point in about the published games. Lets say your the owner of some big development studio. You want to make a new game and have millions of dollars to spend on an engine. Do you seriously think that a big company who can afford to make a game that scales up to games like Call of Duty or World of Warcraft is going to pick Torque? Torque is made for Indies, therefore most people arent seriously developing a game using Torque. For the people who are, 99% are still Indie companys. Thats why you dont see tons of games being published with Torque, because its an Indie engine, with Indie users.As for the terrain comments..GG has said many many many times why the textures are [u]still[/u] 256^2. I dont know why they havent changed it since the late 90's, but I think its a bit late to bitch about something that hasnt changed in 10 years.
TGEA took 4? years to develop into something somewhat useable. Why wouldnt GG charge extra money for it? Like I said in my other post, in order to make TGE be what TGEA is, it would take some major recoding and it would be almost impossible. It was easier to make a totaly new engine then to add shinny shaders and hi-res textures on terrains. TGE was ready for a change, and that change meant that something better had to be made.
#24
TnL has some competition from RakNet of course, both in terms of performance and licensing. If you thought TnL's open-source licence was unrestrictive for testing purposes, RakNet has something similar to offer.
But, I don't quite agree with your "simulation" argument. The degree of immersion you expect a sub-system to exhibit is just sufficient for its purpose. I guess, keeping in mind that TGE was a spin-off from Tribes 2, you couldn't really expect a totally immersive physics simulation (I'm not blaming the current implementation, with the right tweaks, it can work wonders for you). In fact, simulations are done with the end-result in mind, aren't they? You don't need to have rag-dolls and full-blown networking physics for something that is not going to use it extensively. These are specific applications, so if you want something more than what it offers, like everyone else says - add it! You've got the source! and I'm sure you'll find more than a couple of resources to help you along.
If you ask me, I'm pretty tired of these comparisons. They've been on for too long. OGRE is a full-blown rendering engine, which is why it does what it does so well. I don't want to argue about pipelines, but sometimes I wonder if OGRE is slowly-becoming a scapegoat of its own pursuit of generality. The OGRE team has always maintained that they envisage OGRE as being a library not supporting one end-application or another, one game or another. Sure, there are options - there's oFusion, a couple of scene-managers, but what of people who cannot afford MAX? What of folks who're used to LW or XSI? I have seen many a discussion, but there simply is NO point in comparing stuff like that.
My suggestion to anyone reading this thread would be - COMPLAIN!! BY ALL MEANS PLEASE DO!! But DO NOT COMPARE! Ask for features that you'd like - ask for stuff that you'd like to see. Maybe someone lurking somewhere will add it in and help you along on your way so you could do the same down the line. Complain about stuff that is broken, and someone will be able to help you out. That way, your experiences will also help the documentation grow, and people will start complaining lesser.
An APPLE is NOT necessarily better an ORANGE! You can never tell, you just have to take a liking to either one...
06/19/2008 (11:25 pm)
Personally, I haven't had any problems with low-res terrain textures, with the detail maps applied. Guess I've never had the need for anything more dandy.TnL has some competition from RakNet of course, both in terms of performance and licensing. If you thought TnL's open-source licence was unrestrictive for testing purposes, RakNet has something similar to offer.
But, I don't quite agree with your "simulation" argument. The degree of immersion you expect a sub-system to exhibit is just sufficient for its purpose. I guess, keeping in mind that TGE was a spin-off from Tribes 2, you couldn't really expect a totally immersive physics simulation (I'm not blaming the current implementation, with the right tweaks, it can work wonders for you). In fact, simulations are done with the end-result in mind, aren't they? You don't need to have rag-dolls and full-blown networking physics for something that is not going to use it extensively. These are specific applications, so if you want something more than what it offers, like everyone else says - add it! You've got the source! and I'm sure you'll find more than a couple of resources to help you along.
If you ask me, I'm pretty tired of these comparisons. They've been on for too long. OGRE is a full-blown rendering engine, which is why it does what it does so well. I don't want to argue about pipelines, but sometimes I wonder if OGRE is slowly-becoming a scapegoat of its own pursuit of generality. The OGRE team has always maintained that they envisage OGRE as being a library not supporting one end-application or another, one game or another. Sure, there are options - there's oFusion, a couple of scene-managers, but what of people who cannot afford MAX? What of folks who're used to LW or XSI? I have seen many a discussion, but there simply is NO point in comparing stuff like that.
My suggestion to anyone reading this thread would be - COMPLAIN!! BY ALL MEANS PLEASE DO!! But DO NOT COMPARE! Ask for features that you'd like - ask for stuff that you'd like to see. Maybe someone lurking somewhere will add it in and help you along on your way so you could do the same down the line. Complain about stuff that is broken, and someone will be able to help you out. That way, your experiences will also help the documentation grow, and people will start complaining lesser.
An APPLE is NOT necessarily better an ORANGE! You can never tell, you just have to take a liking to either one...
#25
Did you look on the product pages? There is a link to this page which shows quite a bit:
www.garagegames.com/products/torque/powered
These ones in particular have been getting a good amount of press lately:
www.hotheadgames.com/pa.php
www.dreamlords.com/home.action
www.acronymonline.com/rocketmen.html
06/20/2008 (5:57 am)
Quote:Now this is just me whining again I suppose, but I've asked multiple times for a list of published games that used TGE/TGEA. Everyone always points at Marble Blast... Okay, I got. Tribes. Right, got that too. What else though
Did you look on the product pages? There is a link to this page which shows quite a bit:
www.garagegames.com/products/torque/powered
These ones in particular have been getting a good amount of press lately:
www.hotheadgames.com/pa.php
www.dreamlords.com/home.action
www.acronymonline.com/rocketmen.html
#26
Ofusion has a shaderFX bridge for the commercial version that works in realtime with ogre shaders exported and viewed in an ogre viewport within 3dsmax.
Garage Games seem slow to develop their engines, and spread themselves thin with too many products. Biggest sin in TGEA is only supporting 1 UV channel. I collaborated with Ben Garney on a Blitz3D B3D loader several years ago a TGE addon that had 2 UV's and the B3D fixed function material system, as well as the coldet triangle collisions that just appeared now 3 years later in TGEA.
I quit using Torque two years ago because things were too slow and expensive. There didn't seem much interest in anything but leading the community with small carrots. I've been with the community for 7 years waiting for Torque to come good and even get basic features like multiple UV channels. Before my dabble with torque we used blitz3d which has probably produced more finished indie games than most other indie solutions despite using Basic and a DX7 renderer. Currenty there are about 180 finished games.
Today were using Ogre and have never looked back. It supports so many free user made modern technologies that actually work out the box and are properly maintained so you have many options that are scaleable to fit your needs. It has two licence options so you can use it any way you need. Free with LGPL or $5000 for an unlimited commercial licence that can be staticly linked and ported to other platforms.
Leadwerks is a cool engine that runs amazingly well on pixel shader 3.0 cards. But its focus on cutting edge tech means that probably 70% of people with pixel shader 2.x or lower can not run the engine. It's really a engine aiming for hardware maybe 2 years into the future and almost requires you to purchase 3D world studio to use it efficiently.
06/20/2008 (7:35 am)
Actually Ogre has excellent support for most 3d modeling tools. Not just 3dsmax with ofusion. Ogre has a XSI exporter created by Ogres project lead. There's Maya, Lightwave, several 3ds max exporters. Ofusion has a shaderFX bridge for the commercial version that works in realtime with ogre shaders exported and viewed in an ogre viewport within 3dsmax.
Garage Games seem slow to develop their engines, and spread themselves thin with too many products. Biggest sin in TGEA is only supporting 1 UV channel. I collaborated with Ben Garney on a Blitz3D B3D loader several years ago a TGE addon that had 2 UV's and the B3D fixed function material system, as well as the coldet triangle collisions that just appeared now 3 years later in TGEA.
I quit using Torque two years ago because things were too slow and expensive. There didn't seem much interest in anything but leading the community with small carrots. I've been with the community for 7 years waiting for Torque to come good and even get basic features like multiple UV channels. Before my dabble with torque we used blitz3d which has probably produced more finished indie games than most other indie solutions despite using Basic and a DX7 renderer. Currenty there are about 180 finished games.
Today were using Ogre and have never looked back. It supports so many free user made modern technologies that actually work out the box and are properly maintained so you have many options that are scaleable to fit your needs. It has two licence options so you can use it any way you need. Free with LGPL or $5000 for an unlimited commercial licence that can be staticly linked and ported to other platforms.
Leadwerks is a cool engine that runs amazingly well on pixel shader 3.0 cards. But its focus on cutting edge tech means that probably 70% of people with pixel shader 2.x or lower can not run the engine. It's really a engine aiming for hardware maybe 2 years into the future and almost requires you to purchase 3D world studio to use it efficiently.
#27
06/20/2008 (8:47 am)
Ahh, some things never change :)
#28
Where torque is concerned that is very true. Not to mention disappointing. The multiple UV is so basic and opens so many doors that it's an incredible omission.
06/20/2008 (9:25 am)
Quote:Ahh, some things never change
Where torque is concerned that is very true. Not to mention disappointing. The multiple UV is so basic and opens so many doors that it's an incredible omission.
#30
I actually used the Blender exporter with my own XML parser for .scene files, which blender exported. I know there are a couple of parsers already on the wiki, but both seemed incomplete at the time.
What I've really loved about OGRE is its material system and the compositor framework though... I'm really hoping the DX10 renderer will get me back, and of course get me an excuse to buy a more powerful GPU ;)
06/21/2008 (11:29 pm)
Oh ok... I used the second/ third maintenance release of Eihort a while back, that was the last. I had used Dagon quite a bit before that though. I'm really waiting for the DX10 renderer in Shoggoth, I suppose its in SVN (heard they switched from CVS) already, but I can really give myself an excuse for moving away from Torque once a stable package is released. I'd love to get my hands on it.I actually used the Blender exporter with my own XML parser for .scene files, which blender exported. I know there are a couple of parsers already on the wiki, but both seemed incomplete at the time.
What I've really loved about OGRE is its material system and the compositor framework though... I'm really hoping the DX10 renderer will get me back, and of course get me an excuse to buy a more powerful GPU ;)
#31
Still, expensive if your not working on a funded project. Were actually releasing a Ogre scene editor that uses .OSM scene loader and scene serializer libs, but also loads ogre native .scene files so its compatible with most exportes .scene export.
06/22/2008 (10:55 am)
I paid $600 for a commercial pro ogre 3dsmax exporter. Worth every penny though since it renders ogre in a 3dsmax viewport for WYSIWYG level editing. And has realtime support for the shaderfX node based shader material editor. Creates ogre optimized HLSL shaders with all Ogres native shader paramaters, and very easy to convert to CG.Still, expensive if your not working on a funded project. Were actually releasing a Ogre scene editor that uses .OSM scene loader and scene serializer libs, but also loads ogre native .scene files so its compatible with most exportes .scene export.
#32
I'm seriously tired of the "Holier than thou" attitude from the Garage Games staff, affiliates and some of the community members.
I've held my tongue for the most part, but I'm sick of it.
Torque is not the end-all-be-all game engine with a monopoly on Indie game developers.
I've literally paid over a thousand dollars for this low quality piece of crap (and related artwork)... and I'm very disappointed.
I'm also sick of the "Oh, but you get the source code."
With the amount of code I have to write to make Torque do what I want, I might as well start from scratch.
Edit: formatting
Edit 2: ok, so the original post was quite harsh, so I toned it down a bit.
06/25/2008 (5:50 pm)
Quote:Ahh, some things never change :)
I'm seriously tired of the "Holier than thou" attitude from the Garage Games staff, affiliates and some of the community members.
I've held my tongue for the most part, but I'm sick of it.
Torque is not the end-all-be-all game engine with a monopoly on Indie game developers.
I've literally paid over a thousand dollars for this low quality piece of crap (and related artwork)... and I'm very disappointed.
I'm also sick of the "Oh, but you get the source code."
With the amount of code I have to write to make Torque do what I want, I might as well start from scratch.
Edit: formatting
Edit 2: ok, so the original post was quite harsh, so I toned it down a bit.
#33
The whole lack of physics is what drives me away from TGE/A
Do you have any suggested engines Tony?
06/25/2008 (8:24 pm)
I like your comment and I've felt the same way many times. After hours of engine research it seems to me that there are a lot of engines that are comparable to the torque engine. It's almost like a teeter totter in the sense that some engines are good in one area but lack in another and it keeps going back and forth. Every company that puts out an indie engine always claims there the best.....obviously. The thing that drives me bonkers is that indie game engines seem to range from free to a couple hundred bucks and the next step up are the console engines that start at $50,000 up to a cool million. Is there an engine out there that's pretty darn good and oh let's give it a range of......$2000 - $6000?The whole lack of physics is what drives me away from TGE/A
Do you have any suggested engines Tony?
#34
A few of us decided that what's currently available for Indies just isn't good enough, so we've struck out on our own and we're putting together our own framework, game engine and game development IDE.... and it's free.
The framework allows you to make choices of which type of components you want to use... one company is even planning on using Torque as the rendering engine and resource manager integrated with our framework so they can use the ZPhysX and ZPython plugins for physics and scripting.
They are having to tear Torque to shreds and put it back together, but if more people are interested then we could probably turn it into a community project.
Another group is using ZBullet, ZOgre, ZRakNet, ZLua and a bunch of our custom plugins for creating a fantastic MMO game.... no Torque involved in that project and nearly all of it is open source and free. (RakNet is $100 if you go that route).
The framework and related game engines are not finished yet, but the more programmers we get on board to contribute, the faster we'll be done.
If you like Torque but you want to add physics or you want to create an online Arcade, Racing, Fighting, Casual, FPS, RPG, RTS, or even an MMO game and you don't want to have to wrangle Torque into shape, you should really check it out.
If you don't like Torque and you want a great, flexible game engine, you should definitely check it out... at this point, even though it's not complete, it's still your best choice.
06/26/2008 (4:18 am)
@DALO - You should check out IndieZen.org.A few of us decided that what's currently available for Indies just isn't good enough, so we've struck out on our own and we're putting together our own framework, game engine and game development IDE.... and it's free.
The framework allows you to make choices of which type of components you want to use... one company is even planning on using Torque as the rendering engine and resource manager integrated with our framework so they can use the ZPhysX and ZPython plugins for physics and scripting.
They are having to tear Torque to shreds and put it back together, but if more people are interested then we could probably turn it into a community project.
Another group is using ZBullet, ZOgre, ZRakNet, ZLua and a bunch of our custom plugins for creating a fantastic MMO game.... no Torque involved in that project and nearly all of it is open source and free. (RakNet is $100 if you go that route).
The framework and related game engines are not finished yet, but the more programmers we get on board to contribute, the faster we'll be done.
If you like Torque but you want to add physics or you want to create an online Arcade, Racing, Fighting, Casual, FPS, RPG, RTS, or even an MMO game and you don't want to have to wrangle Torque into shape, you should really check it out.
If you don't like Torque and you want a great, flexible game engine, you should definitely check it out... at this point, even though it's not complete, it's still your best choice.
#35
@Pat - My apologies for going off like that. The blog was actually very good, but you're using a "Promise" (or delayed execution design pattern) in the wrong way. Your code for the most part has always been great... but if you're interested in a few facts about multithreaded coding, I could help you fix the problems you're encountering. Feel free to email me trichards at indiezen dot org. I've been doing multithreaded programming professionally for about 20 years now and it's fairly easy for me to identify the source of the problems related to race conditions and deadlocks.
I'm just seriously frustrated.... I see the correct answer but I don't know how to make it happen.
[on topic]
Leadwerks is a decent enough game engine, but it still has quite a few of the same problems that Torque has.... the primary problem is the inflexibility. If you want to make something the author(s) intended to let you create then you're golden, but if you want to step outside of the box and make something different, you're completely screwed.
[/on topic]
I wish I could convince Garage Games that using Zen Framework is their best option... think about it. Outside free programmers doing most of the hard work while the GG staff concentrates on improving what Torque does best.
A refactored version of Torque, made to work with the Zen Framework would give the Torque user base a fantastic option without leaving familiar territory and without taking any customers away from the Garage, which I'm sure is a very high priority.
Instead of everyone having to post code enhancements as resources, they could write new plugins or contribute to the open source portions of the code.... kill thousands of birds with a single stone.
There are tons of programmers willing to contribute... just look at the significant number of coding resources on this website.
But... Instead of having to wrangle with the code, we simply make an extension point at the appropriate locations to facilitate enhancements, then people are free to write and distribute their extensions without having to worry about having to distribute a bunch of patches to Torque that will break with the next release.
It's a significantly more elegant approach...
06/26/2008 (4:48 am)
@everyone else - Sorry for the rant and the off topic post@Pat - My apologies for going off like that. The blog was actually very good, but you're using a "Promise" (or delayed execution design pattern) in the wrong way. Your code for the most part has always been great... but if you're interested in a few facts about multithreaded coding, I could help you fix the problems you're encountering. Feel free to email me trichards at indiezen dot org. I've been doing multithreaded programming professionally for about 20 years now and it's fairly easy for me to identify the source of the problems related to race conditions and deadlocks.
I'm just seriously frustrated.... I see the correct answer but I don't know how to make it happen.
[on topic]
Leadwerks is a decent enough game engine, but it still has quite a few of the same problems that Torque has.... the primary problem is the inflexibility. If you want to make something the author(s) intended to let you create then you're golden, but if you want to step outside of the box and make something different, you're completely screwed.
[/on topic]
I wish I could convince Garage Games that using Zen Framework is their best option... think about it. Outside free programmers doing most of the hard work while the GG staff concentrates on improving what Torque does best.
A refactored version of Torque, made to work with the Zen Framework would give the Torque user base a fantastic option without leaving familiar territory and without taking any customers away from the Garage, which I'm sure is a very high priority.
Instead of everyone having to post code enhancements as resources, they could write new plugins or contribute to the open source portions of the code.... kill thousands of birds with a single stone.
There are tons of programmers willing to contribute... just look at the significant number of coding resources on this website.
But... Instead of having to wrangle with the code, we simply make an extension point at the appropriate locations to facilitate enhancements, then people are free to write and distribute their extensions without having to worry about having to distribute a bunch of patches to Torque that will break with the next release.
It's a significantly more elegant approach...
#36
I don't have much information except what I've read in your comments/blogs and on the IndieZen site itself about what you're doing, but I like what little I've seen. I have zero sway in decisions made at GG, but I've liked what I've seen so far. I just need time to check out more of what you're doing. I've spent a lot of time at Unity, C4, Blitz, TheGameCreators, Irrlicht, and 3D Game Studio's sites, but those have been pretty much my primaries. I need to sit down and spend some time with IndieZen to get up on what you're offering.
06/26/2008 (7:17 am)
Wow. This topic jumped up like crazy.I don't have much information except what I've read in your comments/blogs and on the IndieZen site itself about what you're doing, but I like what little I've seen. I have zero sway in decisions made at GG, but I've liked what I've seen so far. I just need time to check out more of what you're doing. I've spent a lot of time at Unity, C4, Blitz, TheGameCreators, Irrlicht, and 3D Game Studio's sites, but those have been pretty much my primaries. I need to sit down and spend some time with IndieZen to get up on what you're offering.
#37
06/26/2008 (7:36 am)
Ya sorry about the topic switch... we can take this offline via e-mail or phone if you like.
#38
I would like to know how you think our engine suffers from inflexibility. The command set is quite low-level and allows the creation of any kind of game, so I am not sure how this statement can be made by an informed person. Perhaps I do not understand you, and I can use your suggestions to improve the API.
There are other valid criticisms that can be made. Some people do not like that the minimum system requirement is a Shader Model 3.0 card, and they may wish to use an engine which supports older hardware. However, the accusation of inflexibility does not make sense to me, as I have made great effort to avoid the inflexibility I see in other engine designs, and sometimes I feel like I am the only person who sees the importance of this. I do not think the designs of the Torque and Leadwerks engines are in any way comparable. I will not argue that either is better, but again I do not understand how the comparison above can be made.
06/26/2008 (10:40 am)
Quote:Leadwerks is a decent enough game engine, but it still has quite a few of the same problems that Torque has.... the primary problem is the inflexibility. If you want to make something the author(s) intended to let you create then you're golden, but if you want to step outside of the box and make something different, you're completely screwed.I do not normally comment on discussions like this, except in the case when I see statements made that create confusion and disinformation.
I would like to know how you think our engine suffers from inflexibility. The command set is quite low-level and allows the creation of any kind of game, so I am not sure how this statement can be made by an informed person. Perhaps I do not understand you, and I can use your suggestions to improve the API.
There are other valid criticisms that can be made. Some people do not like that the minimum system requirement is a Shader Model 3.0 card, and they may wish to use an engine which supports older hardware. However, the accusation of inflexibility does not make sense to me, as I have made great effort to avoid the inflexibility I see in other engine designs, and sometimes I feel like I am the only person who sees the importance of this. I do not think the designs of the Torque and Leadwerks engines are in any way comparable. I will not argue that either is better, but again I do not understand how the comparison above can be made.
#39
What I meant by inflexible is this:
You've made certain decisions within your game engine... what if someone doesn't agree with those decisions or needs something else?
Could I easily drop in a different audio library, physics library, network library, scripting language, etc? What if I wanted to use DirectX or some other rendering pipeline? What if I am targeting other platforms?
Granted, those are far-fetched requirements (one of which is a show stopper for me... cross platform).
So, what does that mean? Exactly what I stated...
Your box is significantly larger than Torque's box, don't get me wrong... but you've still defined a box and if someone needs something else then they cannot use your game engine.
That's all I meant.
I'm a fan of your applications... I'm not using Leadwerx Game Engine primarily because I mostly write cross-platform code, but I use 3D World Studio all the time and I love it.
I didn't mean to insult you or your game engine.... it's fantastic, the documentation is great and I'm sure the support is just as good as what you provide for 3D World Studio.
06/26/2008 (11:27 am)
@Leadwerks - My sincere apologies... I didn't meant to insult you by comparing Leadwerx to Torque.What I meant by inflexible is this:
You've made certain decisions within your game engine... what if someone doesn't agree with those decisions or needs something else?
Could I easily drop in a different audio library, physics library, network library, scripting language, etc? What if I wanted to use DirectX or some other rendering pipeline? What if I am targeting other platforms?
Granted, those are far-fetched requirements (one of which is a show stopper for me... cross platform).
So, what does that mean? Exactly what I stated...
Quote:If you want to make something the author(s) intended to let you create then you're golden, but if you want to step outside of the box and make something different, you're completely screwed.
Your box is significantly larger than Torque's box, don't get me wrong... but you've still defined a box and if someone needs something else then they cannot use your game engine.
That's all I meant.
I'm a fan of your applications... I'm not using Leadwerx Game Engine primarily because I mostly write cross-platform code, but I use 3D World Studio all the time and I love it.
I didn't mean to insult you or your game engine.... it's fantastic, the documentation is great and I'm sure the support is just as good as what you provide for 3D World Studio.
#40
Tom and I *very* quickly had ragdolls (I think it was ~2 weeks, one week of cleaning up the existing PhysX resource and getting it to be server/client, and another week of misc. figuring out transforms and setting up our first stab at the ragdoll loading) in PhysX, "dropped" into Torque. I believe Tom had it ported to newer versions of the engine *very* quickly(days, or possibly a single day). We even managed to figure out a solution for getting our ragdolls to be fairly accurately synced between the server and clients.
Replacing PhysX with wouldn't be very hard, from what I've seen. Right now, we could easily have a *lot* of objects in our scenes (and we do, if you look at the screenshots of Be the Dinosaur, every tree there has collision in PhysX, and the dinos have upwards of 100 bones each (50ish for triceratops, 100ish for t. rex)). So there are typically around 30k actors in our scenes. The main bottleneck to having say, a stack of 1000 boxes with a DTS representation is the DTS rendering path being somewhat clunky.
I really think that people that are having trouble just need to put their nose to the grindstone and just get something working, instead of expecting whatever feature they "need" to be written by GG and put in as part of the core.
I also don't think Leadwerks is comparable, but that's just because I wouldn't be able to bear not having source code.
IMO most of what is lacking in Torque is a more optimal rendering path (esp. with lights and shadows, and the base DTS rendering) and tools. The former could be remedied by putting in the partially deferred rendering that Pat has worked on for RokkitBall, and the later could be done by restructuring how the tools are currently added to the mission editor.
As to the multi-threaded skinning, I'm honestly surprised Pat got that working without having to rewrite things somewhat, since the skinning code right now uses a lot of static arrays as temporaries, which is also the case with the DTS rendering (the TSMesh:setXXX calls). But then again, I've not done almost any multi-threaded code so that's not something I can comment on like I can with physics.
06/26/2008 (11:50 am)
@Tony, we've discussed this to some degree before (and of course, I don't agree that "Torque is the worst game engine ever" nor do I think other people that have shipped games with it would either.... I also don't see starting over from scratch as the real answer here). One thing I certainly have to disagree with though, is your mention of not being able to "drop a physics lib" into Torque. Tom and I *very* quickly had ragdolls (I think it was ~2 weeks, one week of cleaning up the existing PhysX resource and getting it to be server/client, and another week of misc. figuring out transforms and setting up our first stab at the ragdoll loading) in PhysX, "dropped" into Torque. I believe Tom had it ported to newer versions of the engine *very* quickly(days, or possibly a single day). We even managed to figure out a solution for getting our ragdolls to be fairly accurately synced between the server and clients.
Replacing PhysX with
I really think that people that are having trouble just need to put their nose to the grindstone and just get something working, instead of expecting whatever feature they "need" to be written by GG and put in as part of the core.
I also don't think Leadwerks is comparable, but that's just because I wouldn't be able to bear not having source code.
IMO most of what is lacking in Torque is a more optimal rendering path (esp. with lights and shadows, and the base DTS rendering) and tools. The former could be remedied by putting in the partially deferred rendering that Pat has worked on for RokkitBall, and the later could be done by restructuring how the tools are currently added to the mission editor.
As to the multi-threaded skinning, I'm honestly surprised Pat got that working without having to rewrite things somewhat, since the skinning code right now uses a lot of static arrays as temporaries, which is also the case with the DTS rendering (the TSMesh:setXXX calls). But then again, I've not done almost any multi-threaded code so that's not something I can comment on like I can with physics.
Torque 3D Owner Pat Wilson