Just bought the SDK and... well... SDK it aint...
by Tim Bolin · in Torque Game Engine · 02/26/2004 (7:12 pm) · 115 replies
At least, thats how it seems to me... i had previously been using OGRE, and within an hour of downloading and unzipping the source, i had managed to start a blank project (in vc++ 2003), import a mesh, draw a plane as a "ground" surface, draw a skydome, slap a texture on everything, toss out a light, drop in a camera, compile it, and see the finished product rendered out of the resulting exe...
contrast that with torque, where i have spent the last 8 hours trying to figure out where the FPS demo ends and the engine begins, and im no closer now than i was... and i have to say, WTF?? it is beginning to look like the "demo" is inextricably entwined with the engine itself, and that pretty much anything i do is going to be a mod of the demo... and pretty much all the tutorials support this suspicion...
i have absolutely ZERO interest in modding a demo, example, tutorial, or anything else... i want the class libraries, documentation, and ideally a blank template project so i can do in torque the equivilant of what i did with OGRE...
the main reason i purchased the engine was to have access to the code for audio, physics, network, etc... and i had hoped that it would be pretty clear what did what, what needed to be included where, and how to just initialize a rendering window and start adding objects to a scene, then in time as needed add in the other bits and pieces of the engine code...
so, in short, have i wasted my money? is there any way to just delete the "examples" directory and any and all "demo" code/script/assets/etc and still be able to use the engine? and if so, what is the bare minimum in the way of files i need to link in to my project to simply render a single object on screen as a starting point? if there is no way to do this, im just going to have to suck up the money spent and go back to ogre... it is starting to look like this may not be the best development choice for a turn-based strat game...
maybe the problem is ive gone into the whole torque thing without grasping the big picture... for example, the whole scripting thing... when and where and WHY would i ever want to do anything in script when i could do it in native c++? the scripting seems pretty central to the engine but i cant for the life of me understand why... i suppose it would be handy if you wanted your game to be moddable by its users... which i dont... or handy if you didnt want to code in c++... but i do...
if anyone could point me in the right direction, or point me at a tutorial explaining how to use the engine itself (and not one that touches in even the remotest form the demo code) id certainly appreciate it...
contrast that with torque, where i have spent the last 8 hours trying to figure out where the FPS demo ends and the engine begins, and im no closer now than i was... and i have to say, WTF?? it is beginning to look like the "demo" is inextricably entwined with the engine itself, and that pretty much anything i do is going to be a mod of the demo... and pretty much all the tutorials support this suspicion...
i have absolutely ZERO interest in modding a demo, example, tutorial, or anything else... i want the class libraries, documentation, and ideally a blank template project so i can do in torque the equivilant of what i did with OGRE...
the main reason i purchased the engine was to have access to the code for audio, physics, network, etc... and i had hoped that it would be pretty clear what did what, what needed to be included where, and how to just initialize a rendering window and start adding objects to a scene, then in time as needed add in the other bits and pieces of the engine code...
so, in short, have i wasted my money? is there any way to just delete the "examples" directory and any and all "demo" code/script/assets/etc and still be able to use the engine? and if so, what is the bare minimum in the way of files i need to link in to my project to simply render a single object on screen as a starting point? if there is no way to do this, im just going to have to suck up the money spent and go back to ogre... it is starting to look like this may not be the best development choice for a turn-based strat game...
maybe the problem is ive gone into the whole torque thing without grasping the big picture... for example, the whole scripting thing... when and where and WHY would i ever want to do anything in script when i could do it in native c++? the scripting seems pretty central to the engine but i cant for the life of me understand why... i suppose it would be handy if you wanted your game to be moddable by its users... which i dont... or handy if you didnt want to code in c++... but i do...
if anyone could point me in the right direction, or point me at a tutorial explaining how to use the engine itself (and not one that touches in even the remotest form the demo code) id certainly appreciate it...
#22
@Tim,
Sounds to me like your mind has been made up. Based on the above comments, I think the decision you made was a bad choice for you. This is not to say that the TGE is a bad choice for what you want to do, but it sounds like the approach you want to take is not compatible with what the TGE is. I get the sense that you are coming to this with a preconcieved notion of how the engine ought to be, and how you want to approach working with it. I am not going to makea value judgement on your point of view, but it appears to me that you are not willing to change your development approach, and that this will lead you to give up on the TGE without trying to see whether or not your game can be done with this engine.
02/27/2004 (8:31 am)
Quote:the problem is, based on my digging through the code and (unsuccessfully) attempting to get to that boilerplate state, (snip) more time stripping away and/or retooling the fps/engine (snip) im not thrilled at the prospect of trying to integrate disparate third-party libraries for sound/physics/input handling etc (snip) but i cant see how that would be any more time consuming or difficult than trying to find, isolate, deconstruct, and implement the same features from the torque codebase..(snip)engine seems clearly geared towards fps development(snip)
@Tim,
Sounds to me like your mind has been made up. Based on the above comments, I think the decision you made was a bad choice for you. This is not to say that the TGE is a bad choice for what you want to do, but it sounds like the approach you want to take is not compatible with what the TGE is. I get the sense that you are coming to this with a preconcieved notion of how the engine ought to be, and how you want to approach working with it. I am not going to makea value judgement on your point of view, but it appears to me that you are not willing to change your development approach, and that this will lead you to give up on the TGE without trying to see whether or not your game can be done with this engine.
#23
If you are only give it two more days, don't bother wasting the next two days, you are not going to "get it" in two days, or even two weeks . . . most likely
Examples of all that is easily available in the demo code that you so want to throw out.
02/27/2004 (8:33 am)
Quote:im going to whack away at it for another day or so just to see if i can get to the point where i can put together a simple scene, light it, render it, overlay some kind of 2d elements and make it respond to some kind of input, but im afraid if i cant get to that point im just going to have to chalk it up to a lesson learned...
If you are only give it two more days, don't bother wasting the next two days, you are not going to "get it" in two days, or even two weeks . . . most likely
Examples of all that is easily available in the demo code that you so want to throw out.
#24
I think he is just dealing with the initial frustration of realizing he has a lot to learn. He will be back. Seems to me he has the right aspiration of making a game. I think the TGE is the best thing out there for him. Sooner or later he will figure out that the $100.00 was the best deal he could get.
Maybe we need some sort of high level beginners book. You know the basics: What are the components of a game? What is C++? Whats a game engine? Whats a scripting language? Why do I need a scripting language?
There are a lot of people like Tim that may be able to code but dont have the bigger picture. You kind of have to hold their hand and give them little baby steps just to help them over the initial hurdle.
We put togther some useful links at Game Beavers to just try to point them in the right direction.
02/27/2004 (9:00 am)
Joe, Jarrod,I think he is just dealing with the initial frustration of realizing he has a lot to learn. He will be back. Seems to me he has the right aspiration of making a game. I think the TGE is the best thing out there for him. Sooner or later he will figure out that the $100.00 was the best deal he could get.
Maybe we need some sort of high level beginners book. You know the basics: What are the components of a game? What is C++? Whats a game engine? Whats a scripting language? Why do I need a scripting language?
There are a lot of people like Tim that may be able to code but dont have the bigger picture. You kind of have to hold their hand and give them little baby steps just to help them over the initial hurdle.
We put togther some useful links at Game Beavers to just try to point them in the right direction.
#25
I'm not accusing OGRE of this and haven't used that software, but it is just a general experience.
The other problem is the paradigm changed required by an engine technology switch. Strategies and techniques that were productive in the other technology may be the opposite in the new technology, or may need to be translated to the new technology's idioms. During this migration the user is less productive, which can be frustrating. The fact that your complaint originates from trying to use both engines in exactly the same way is very symptomatic of the syndrome. Again, this is general experience, as when a neophyte uses structured decomposition in an object oriented language, and then complains that the OO just makes it harder to code :) .
Scripting is generally used to shorten workflows on volatile code, cutting out the build cycle from the code-test-debug workflow. In game development, more specifically, professional studios often have separate engine and script developers, the former coding the stable engine base, the latter creating gameplay code that executes outside of critical paths (like the render pipeline). The usual strategy is to script until perfomance becomes an issue, and then promote performance critical function from (bytecode-)interpreted scripts to compiled engine code (a JIT can largely obviate the need for this except in rare instances). The scripting is a bit idiosyncratic, but so is every scripting language I've ever used because they generally start as tiny interpreters with limited syntax and library support, and end up as gargantuan systems with tons of features hacked into very fragile architectures (*cough*Perl*cough*). Torquescript fortunately is robust and more contained (its class/namespace implementation and datablocks are probably the most difficult features to get comfortable with).
Lastly, FPS engines are really just graphical simulators in disguise, which makes them the most generic of engines (imagine trying to use an RTS or MMORPG engine to create an FPS). Torque could be used for architectural walkthroughs, visualization of engineering simulations, or creating pretty landscapes. I'm familiar with Torque, and it took me about a day to strip out the FPS elements. Once this is accomplished it takes some lateral thinking on how to leverage the tools in the toolkit in service to the subject matter at hand. As I said in earlier posts, with such lateral thinking the vehicle code can be the foundation for realistic dice. I haven't done it, but I would guess it would take less than a day for me to code that up. ShapeBase could be used to create squares on your gameboard, the game pieces could be ShapeBaseImages that get mounted on the ShapeBase gameboard squares.
OGRE could be the right solution for some users, but I thought I'd just provide some fodder so that the decision is better informed.
02/27/2004 (11:20 am)
There is a certain amount of 'culture shock' when entering the Torque multiverse. It's a big engine. It isn't a toy engine. It formerly existed as an in-house engine. These add up to Torque not being as user friendly as other engines out-of-the-box, but generally (IME) software packages in which it is possible to become productive quickly on toy examples don't scale well. The user quickly encounters limitations when attempting anything 'real'. These are best thought of as prototyping tools, where it is possible to create proof-of-concept mock ups quickly. Torque can be used for rapid prototyping once a user is familiar with the engine, but the entry costs are too high to use it for one-shot prototypes.I'm not accusing OGRE of this and haven't used that software, but it is just a general experience.
The other problem is the paradigm changed required by an engine technology switch. Strategies and techniques that were productive in the other technology may be the opposite in the new technology, or may need to be translated to the new technology's idioms. During this migration the user is less productive, which can be frustrating. The fact that your complaint originates from trying to use both engines in exactly the same way is very symptomatic of the syndrome. Again, this is general experience, as when a neophyte uses structured decomposition in an object oriented language, and then complains that the OO just makes it harder to code :) .
Scripting is generally used to shorten workflows on volatile code, cutting out the build cycle from the code-test-debug workflow. In game development, more specifically, professional studios often have separate engine and script developers, the former coding the stable engine base, the latter creating gameplay code that executes outside of critical paths (like the render pipeline). The usual strategy is to script until perfomance becomes an issue, and then promote performance critical function from (bytecode-)interpreted scripts to compiled engine code (a JIT can largely obviate the need for this except in rare instances). The scripting is a bit idiosyncratic, but so is every scripting language I've ever used because they generally start as tiny interpreters with limited syntax and library support, and end up as gargantuan systems with tons of features hacked into very fragile architectures (*cough*Perl*cough*). Torquescript fortunately is robust and more contained (its class/namespace implementation and datablocks are probably the most difficult features to get comfortable with).
Lastly, FPS engines are really just graphical simulators in disguise, which makes them the most generic of engines (imagine trying to use an RTS or MMORPG engine to create an FPS). Torque could be used for architectural walkthroughs, visualization of engineering simulations, or creating pretty landscapes. I'm familiar with Torque, and it took me about a day to strip out the FPS elements. Once this is accomplished it takes some lateral thinking on how to leverage the tools in the toolkit in service to the subject matter at hand. As I said in earlier posts, with such lateral thinking the vehicle code can be the foundation for realistic dice. I haven't done it, but I would guess it would take less than a day for me to code that up. ShapeBase could be used to create squares on your gameboard, the game pieces could be ShapeBaseImages that get mounted on the ShapeBase gameboard squares.
OGRE could be the right solution for some users, but I thought I'd just provide some fodder so that the decision is better informed.
#26
this is my fault, i know, i should have read closer, scrutinized the tutorials more, before my purchase... i only wish VERY MUCH that the documetnation was available BEFORE i had to pay, as that would have right away immediately informed me that this wasnt something i want.
i dont want the source to an app. i want to WRITE an app. i dont want to script an app, use tools inside an app, retool the source for an app, edit an app, script to modify the behavior of an app, etc... period. i was hoping to buy a mature, well documented, largely self-contained set of libraries for a number of useful game functions like physics, audio, complex 3d math, network code, etc that would power (as the engine) the game logic that i built to use those components... instead, i got a big honking app whose parts are anything but discreet, well documented, or self-contained... what i really want is to leverage someone elses work on the parts of the game that i dont feel like jacking with... ie ogre, a set of libraries to provide a single interface to directx and opengl without having to get down and dirty with directx and opengl itself... i need to get a scene on screen, so i write code to build the screen and ship it off to ogre to handle the display... id hoped to do the same with torque... i get to a point in code that i need, say, a bit of complex math done... or a bit of audio played... so i ship that off to the math or audio portion of the engine, knowing that theyre going to do what i need them to do because i have the documentation i need to know what to call out to... and get back to coding my game... and i had hoped that by getting a large set of these libraries from a single vendor, id have CONSISTANCY in the implementation, as opposed to using this open source physics library here and that open source audio library over there... i didnt want a worldbuilder app i could script to do stuff or start hacking into...
ive seen other posts in other threads with people quite seriously stating that they have worked with torque for two years and still arent completely comfortable with it... do you realize, in two years, i could build my game twice over? it might not have everything and the kitchen sink like torque, but it would have what it NEEDED to have, and nothing else, and it would do it exactly like i wanted it to.
im not trying to be an ass or anything, i think im just at cross purposes to what and who torque is meant for... and it will be something to play with from time to time when i want a break from coding... but it is absolutely not what i thought i paid for...
02/27/2004 (12:12 pm)
These have all been very interesting and well thought out responses to my initial post... and i now have a better understanding of torque and its uses... however, it not only does not change my opinion but actually reinforces it...this is my fault, i know, i should have read closer, scrutinized the tutorials more, before my purchase... i only wish VERY MUCH that the documetnation was available BEFORE i had to pay, as that would have right away immediately informed me that this wasnt something i want.
i dont want the source to an app. i want to WRITE an app. i dont want to script an app, use tools inside an app, retool the source for an app, edit an app, script to modify the behavior of an app, etc... period. i was hoping to buy a mature, well documented, largely self-contained set of libraries for a number of useful game functions like physics, audio, complex 3d math, network code, etc that would power (as the engine) the game logic that i built to use those components... instead, i got a big honking app whose parts are anything but discreet, well documented, or self-contained... what i really want is to leverage someone elses work on the parts of the game that i dont feel like jacking with... ie ogre, a set of libraries to provide a single interface to directx and opengl without having to get down and dirty with directx and opengl itself... i need to get a scene on screen, so i write code to build the screen and ship it off to ogre to handle the display... id hoped to do the same with torque... i get to a point in code that i need, say, a bit of complex math done... or a bit of audio played... so i ship that off to the math or audio portion of the engine, knowing that theyre going to do what i need them to do because i have the documentation i need to know what to call out to... and get back to coding my game... and i had hoped that by getting a large set of these libraries from a single vendor, id have CONSISTANCY in the implementation, as opposed to using this open source physics library here and that open source audio library over there... i didnt want a worldbuilder app i could script to do stuff or start hacking into...
ive seen other posts in other threads with people quite seriously stating that they have worked with torque for two years and still arent completely comfortable with it... do you realize, in two years, i could build my game twice over? it might not have everything and the kitchen sink like torque, but it would have what it NEEDED to have, and nothing else, and it would do it exactly like i wanted it to.
im not trying to be an ass or anything, i think im just at cross purposes to what and who torque is meant for... and it will be something to play with from time to time when i want a break from coding... but it is absolutely not what i thought i paid for...
#27
Your approach seems to be that you want to build that infrastructure yourself. As you said, this isn't exactly the approach that Torque encourages.
Even if you don't end up using Torque for your game, it might still be a handy reference for you. It is one of the only examples of a commercial level game engine whose source access is availble to anyone with less than a seven-digit budget.
02/27/2004 (12:47 pm)
Quote:I've seen other posts in other threads with people quite seriously stating that they have worked with torque for two years and still arent completely comfortable with it... do you realize, in two years, i could build my game twice over?Your frustration here is understandable, and I see where you are coming from, but you don't need to understand the entire codebase to make a game using Torque, as many developers have shown. They are just trying to write their game logic on top of a stable and well-tested infrastructure, and Torque provides this.
Your approach seems to be that you want to build that infrastructure yourself. As you said, this isn't exactly the approach that Torque encourages.
Even if you don't end up using Torque for your game, it might still be a handy reference for you. It is one of the only examples of a commercial level game engine whose source access is availble to anyone with less than a seven-digit budget.
#28
02/27/2004 (12:52 pm)
I agree with Alex. You could probably learn alot just by playing around with Torque. I think if you keep messing with it and maybe look into creating a game with it that you will be happy that you spent the money.
#29
www.opengl.org/
Open ML
EVAC Engine
www.mesa3d.org/
Here is a free C++ graphics library that you can use to make your own game engine.
sourceforge.net/projects/g3d-cpp/
I guess I'd ask for a refund if I were you, but you should have done some research first. Just about everyone knows there are tons of opensource game SDK's out there. There are more that are direct x specific if you prefer to work on windows only. Ther are litterally hundreds to choose from that will light a scene.
There are more big honking bloated engines with scripting in them too. But that will require lots of research and reading, which you might not be up for. And thats also why posting the sdk docs probably would not have helped you much either.
You can do search on source forge for "game engine" and check the box for require all words.
Neo Engine
Crystal Space
Quake
But now that I have a clear understanding of what you are after you probably just want a basic sdk.
openGL 3rd Party Tools
Free Game Libraries
You could also look at Fly3D
Fly 3d
But if you want to buy something conider Amp 2 it starts at $200 but you get a lot less stuff to learn
Amp2
Oh if you want the source you can get that too at $40,000.00
Personally I think you made the wisest choice you could by accident when you bought Torque.
02/27/2004 (12:53 pm)
Tim, You are right. Oh man, you got screwed. You can get all that for free..www.opengl.org/
Open ML
EVAC Engine
www.mesa3d.org/
Here is a free C++ graphics library that you can use to make your own game engine.
sourceforge.net/projects/g3d-cpp/
I guess I'd ask for a refund if I were you, but you should have done some research first. Just about everyone knows there are tons of opensource game SDK's out there. There are more that are direct x specific if you prefer to work on windows only. Ther are litterally hundreds to choose from that will light a scene.
There are more big honking bloated engines with scripting in them too. But that will require lots of research and reading, which you might not be up for. And thats also why posting the sdk docs probably would not have helped you much either.
You can do search on source forge for "game engine" and check the box for require all words.
Neo Engine
Crystal Space
Quake
But now that I have a clear understanding of what you are after you probably just want a basic sdk.
openGL 3rd Party Tools
Free Game Libraries
You could also look at Fly3D
Fly 3d
But if you want to buy something conider Amp 2 it starts at $200 but you get a lot less stuff to learn
Amp2
Oh if you want the source you can get that too at $40,000.00
Personally I think you made the wisest choice you could by accident when you bought Torque.
#30
as ive said, im not really trying to make a game as much as i am trying to learn HOW a game is made and put together, purely as an educational and hobbyist exercise... that, and the best way for me to stay sharp in a language is to actually write hard stuff in it... ive decided to make this way harder than it needs to be by attempting to write my portion of the code in managed c++ (.net) and get it to interoperate with the unmanaged c++ from sources like ogre and torque... why? because i can see it being professionally smart to learn how to handle this sort of interop in the future as MS moves towards its next OS release, which is supposedly going to be pure .net... that means theres going to be a whole mess of unmanaged code out there thats going to need to work with the new OS infrastructure, and a premium to be paid to the people who can make it work...
02/27/2004 (1:01 pm)
I have no doubt it will, and i intend to use it fully as such... in fact, as i am able, im going to chop out sections of it and try to integrate it into my codebase... assuming i can, anyway, i havent really dug into the license to see what it says about that, but i presume i dont have to use torque in it entirety if i dont want to... and dont worry, in the HUGELY unlikely event i actually complete and attempt to release this as a real piece of software, torque would receive full credit along with any other technologies used...as ive said, im not really trying to make a game as much as i am trying to learn HOW a game is made and put together, purely as an educational and hobbyist exercise... that, and the best way for me to stay sharp in a language is to actually write hard stuff in it... ive decided to make this way harder than it needs to be by attempting to write my portion of the code in managed c++ (.net) and get it to interoperate with the unmanaged c++ from sources like ogre and torque... why? because i can see it being professionally smart to learn how to handle this sort of interop in the future as MS moves towards its next OS release, which is supposedly going to be pure .net... that means theres going to be a whole mess of unmanaged code out there thats going to need to work with the new OS infrastructure, and a premium to be paid to the people who can make it work...
#31
I dunno dude. Is there anything out there for you?
02/27/2004 (1:13 pm)
Grrr.. Yeah you dont want to use the opensource stuff because of "consistency" and you dont want to use ORGE... hmm why dont you want to use ORGE... seems perfect for you. And you dont want to use Torque because it lacks documentation. Have you read the docs?I dunno dude. Is there anything out there for you?
#32
if you are refering to Torque, you need to read the Torque License better than you did the documentation on Torque, which is available to anyone, since this is specificaly mentioned in it as a no-no.
But that is a retorical exercise anyway, you will see what I mean if you actually try and seperate any of the code out.
That said, $100 US is a small price to pay to see commerically viable code base. Easily the price of 1.5 average programming books.
02/27/2004 (1:15 pm)
Quote:im going to chop out sections of it and try to integrate it into my codebase...
if you are refering to Torque, you need to read the Torque License better than you did the documentation on Torque, which is available to anyone, since this is specificaly mentioned in it as a no-no.
But that is a retorical exercise anyway, you will see what I mean if you actually try and seperate any of the code out.
That said, $100 US is a small price to pay to see commerically viable code base. Easily the price of 1.5 average programming books.
#33
02/27/2004 (1:23 pm)
Oh and while im thinking about it... FU britton... i DID read what docs were available, the faqsd, and a number of the tutorials PRIOR to purchase... i also exchanged email with a GG rep... i KNOW there are tons of open source libraries available... like i said, i was hoping to get a package of them from a single development source for the sake of consistancy of implementation, rather than trying to get one opensource library of questionable quality and implementation to talk to another opensource library of equally questionable origins... and i was prepared to pay a hundred bucks for it... to be honest, im prepared to pay a whole lot more than that for it... my point, and my biggest gripe, is that WHAT YOU GET WHEN YOU BUY THE ENGINE IS NOT ADEQUATELY REPRESENTED BEFORE THE TIME OF PURCHASE. had i known before purchase what i know now about the engine, i would not have made the purchase... not because i think it is an inferior product or bad code or anything like that, but because it isnt what *i* was looking for... period! i dont dispute its ability to serve as the foundation for any number of games, and do it well, and i dont doubt for a minute that torque is the best thing since sliced bread for SOME PEOPLE... i just happen to not be one of them! and that doesnt make me a valid target for your sarcastic scorn...
#34
That was probably your mistake right there, and I don't think Torque is advertised anywhere as a set of libraries, although some parts are autonomous enough to be used as such. Although I think you are placing too much emphasis on linker semantics over functionality. Everything you mention is possible in Torque, but sometimes uncommon because you are forcing a suboptimal solution on the engine, which few others would adopt. For instance, writing compiled source code for hard-coded scene description -- you can do it in Torque, but except for some special cases, why? Do you really want to go through a compile cycle to move a scene object three units to the left?. But if you are determined to do this, you can. And then you'll get tired of recompiling and reinvent data driven design. Then you'll realize that your data description language would be that much more powerful if it had function calling semantics and control constructs and you'll reinvent script driven design, then you'll realize that even the scripting is a pain when you are trying to position a scene object visually and you'll write a level editor, and over the course of a few years you'll have recreated the evolution of the modern game engine.
OGRE is simply a rendering engine (AFAICT). Torque also contains a rendering engine that abstracts OGL and D3D (DGL, DynamixGL I'm guessing), but most developers don't use it directly. Those that do are modifying the rendering pipeline or writing custom rendering for scene objects. You can dig that deep and ignore all the intervening levels of higher functionality. You might want to start with Melv May's fxRenderObject.
I guess you at least have an original complaint, that the engine is doing far too much for you that you'd rather do yourself the hard way.
02/27/2004 (1:23 pm)
Quote:
. . . set of libraries . . .
That was probably your mistake right there, and I don't think Torque is advertised anywhere as a set of libraries, although some parts are autonomous enough to be used as such. Although I think you are placing too much emphasis on linker semantics over functionality. Everything you mention is possible in Torque, but sometimes uncommon because you are forcing a suboptimal solution on the engine, which few others would adopt. For instance, writing compiled source code for hard-coded scene description -- you can do it in Torque, but except for some special cases, why? Do you really want to go through a compile cycle to move a scene object three units to the left?. But if you are determined to do this, you can. And then you'll get tired of recompiling and reinvent data driven design. Then you'll realize that your data description language would be that much more powerful if it had function calling semantics and control constructs and you'll reinvent script driven design, then you'll realize that even the scripting is a pain when you are trying to position a scene object visually and you'll write a level editor, and over the course of a few years you'll have recreated the evolution of the modern game engine.
OGRE is simply a rendering engine (AFAICT). Torque also contains a rendering engine that abstracts OGL and D3D (DGL, DynamixGL I'm guessing), but most developers don't use it directly. Those that do are modifying the rendering pipeline or writing custom rendering for scene objects. You can dig that deep and ignore all the intervening levels of higher functionality. You might want to start with Melv May's fxRenderObject.
I guess you at least have an original complaint, that the engine is doing far too much for you that you'd rather do yourself the hard way.
#35
i didnt want to reinvent the wheel, so i thought id go out and buy some wheels... i wanted to get the all in one place if possible, for smooth riding comfort... i saw torque, i thought "sweet! a buncha wheels!"
i just didnt realize what i actually bought was an 18-wheeler until it showed up in my driveway... and then i got annoyed when i realized the wheels were welded on...
02/27/2004 (1:29 pm)
And i am OK with using ogre, just a buddy of mine pointed me at the GG site, and i thought, well since im not too far along, it might be worth my while to see if i cant get all the stuff i wasnt looking forward to writing in one package... i also thought it would be nice to have a large community of developers familiar with the product as a resource... and now that i know that isnt the case, then im going back to what i was originally doing, which is using ogre and other libraries where possible, and writing from scratch everything else...i didnt want to reinvent the wheel, so i thought id go out and buy some wheels... i wanted to get the all in one place if possible, for smooth riding comfort... i saw torque, i thought "sweet! a buncha wheels!"
i just didnt realize what i actually bought was an 18-wheeler until it showed up in my driveway... and then i got annoyed when i realized the wheels were welded on...
#36
But like you said, you've made up your mind. I suggest cutting your losses and departing before this thread gets any uglier - debate without an open mind leads to bad things, and it sounds like you've made up your mind. :)
02/27/2004 (2:11 pm)
They're not welded, just bolted. You can replace the renderer in a few months, the sound library in less time, use ODE for the physics in a few weeks...But like you said, you've made up your mind. I suggest cutting your losses and departing before this thread gets any uglier - debate without an open mind leads to bad things, and it sounds like you've made up your mind. :)
#37
One of the most difficult experiences I have professionally is convincing developers how fundamentally counterproductive this approach is. But I have no stake in your project or productivity, so, have fun and good luck :) .
02/27/2004 (2:12 pm)
The stuff you seem to want is buried under another layer or two of value-added functionality. Most people do want that value-added functionality, and the demos are designed to showcase that (I'd be monumentally unimpressed by a demo that opened a window and rendered some scene objects). The degree of coupling between systems varies, and therefore so does the effort to either replace systems or use them autonomously. You may be overstating the case based on your initial impressions.Quote:
writing from scratch everything else...
One of the most difficult experiences I have professionally is convincing developers how fundamentally counterproductive this approach is. But I have no stake in your project or productivity, so, have fun and good luck :) .
#38
While I don't really want to get involved in this. Ogre is a nice rendering engine and if you look at oasis (badcamels engine layer using ogre as one of the components) then you may well find what you are looking for.
I am relatively new to Torque but I am just starting to figure out that the wheels as you put it are actually not welded on. Infact this may well be what you are wanting (well expect perhaps the instant results). Take a look at a tutorial called TicTacToe in the resouce section.
TicTacToe is done almost completely in c++ minus the startgame call. Also if you take a close look at the engine directory you will find that each of the sections are infact in there own directory.
I have been going over it for most of the day. The game directory is really just an example. I wrote my own controler and didn't use anything from the game directory. It worked fine and I just included the things I wanted.
For example, I need a gui control so I included gui/guiTSControl.h and started with that. Next on to scenemanager sceneManager/sceneManager.h. You get the idea. You want a project that is mostly in c++ then that is the way to go.
Create your own TSControl file (check the tictactoe tutorial) and GameInterface and you are off. You will still need a main.cs file but its like 10 lines of script. Just ignore it.
Later, Ben
02/27/2004 (2:15 pm)
Hello Tim, While I don't really want to get involved in this. Ogre is a nice rendering engine and if you look at oasis (badcamels engine layer using ogre as one of the components) then you may well find what you are looking for.
I am relatively new to Torque but I am just starting to figure out that the wheels as you put it are actually not welded on. Infact this may well be what you are wanting (well expect perhaps the instant results). Take a look at a tutorial called TicTacToe in the resouce section.
TicTacToe is done almost completely in c++ minus the startgame call. Also if you take a close look at the engine directory you will find that each of the sections are infact in there own directory.
I have been going over it for most of the day. The game directory is really just an example. I wrote my own controler and didn't use anything from the game directory. It worked fine and I just included the things I wanted.
For example, I need a gui control so I included gui/guiTSControl.h and started with that. Next on to scenemanager sceneManager/sceneManager.h. You get the idea. You want a project that is mostly in c++ then that is the way to go.
Create your own TSControl file (check the tictactoe tutorial) and GameInterface and you are off. You will still need a main.cs file but its like 10 lines of script. Just ignore it.
Later, Ben
#39
Ya, I know exactly what you mean. Often times you can develop something yourself in the same time as it takes to learn the interface to something. But that comes with a catch, its not well tested and you are the one left maintaining it. Just one more thing on the list of things you have to worry about.
Torque is solid and there are plenty of people working on bugs so I can stick to my own problems and not have to worry about the foundation. :)
Later, Ben
02/27/2004 (2:18 pm)
Hello Brad, Ya, I know exactly what you mean. Often times you can develop something yourself in the same time as it takes to learn the interface to something. But that comes with a catch, its not well tested and you are the one left maintaining it. Just one more thing on the list of things you have to worry about.
Torque is solid and there are plenty of people working on bugs so I can stick to my own problems and not have to worry about the foundation. :)
Later, Ben
#40
02/27/2004 (2:40 pm)
GG made all the documentation available to the general public last year some time. It is all there if you look. Even thou it says the owners get more documentation than available publicly, that is not the case. Even the next cut at expanded documenation is available to the public. Everythign is there available to the public. 
Torque Owner Ben Woodhead
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4837
Later, Ben