C++ documentation? Where is it?
by Makumba Makumbre · in Technical Issues · 12/01/2006 (12:02 pm) · 10 replies
Hi,
I am just considering torque engine purchase. I would like to use it with VS 2005 and going to program purely in c++. Not interested in scripts and such thing. One of my friends have already purchased TGE 1.4, so I visited him and looked at the engine, and hardly believe my eyes - there is not any documentation for C++ programmers (or, at least, I was unable to find it). It is OK for my friend, because he is using Torque script language and some book concerning script programming, and he could not tell me either such thing like torque C++ documentation exist in the world. I have looked at the source code, files are commented, but it is simply not sufficient. I am not going spent months reviewing source files and reinventing a wheel. I would appreciate much, if somebody answers following questions:
1. Where in the world C++ documentation (i mean offline documentation) is?
2. How TGE 1.5 differs from TGE 1.4? is there any features comparition chart? And does it contain sufficient C++ documentation\beginners tutorials, or one have to purchase a book? And does such book (for C++ programmers only, not script language) exist?
I am just considering torque engine purchase. I would like to use it with VS 2005 and going to program purely in c++. Not interested in scripts and such thing. One of my friends have already purchased TGE 1.4, so I visited him and looked at the engine, and hardly believe my eyes - there is not any documentation for C++ programmers (or, at least, I was unable to find it). It is OK for my friend, because he is using Torque script language and some book concerning script programming, and he could not tell me either such thing like torque C++ documentation exist in the world. I have looked at the source code, files are commented, but it is simply not sufficient. I am not going spent months reviewing source files and reinventing a wheel. I would appreciate much, if somebody answers following questions:
1. Where in the world C++ documentation (i mean offline documentation) is?
2. How TGE 1.5 differs from TGE 1.4? is there any features comparition chart? And does it contain sufficient C++ documentation\beginners tutorials, or one have to purchase a book? And does such book (for C++ programmers only, not script language) exist?
#2
12/01/2006 (12:37 pm)
So, how a person can decide is the c++ documentation sufficient or not? I am going to create rather small project and planning to finish game in 2 or 3 weeks (about 1 week for learning engine). I have seen other engines, some of them are so badly documented that it is easier create own engine instead learning them.
#3
6. Engine Coding in C++ (Licensed Users Only)
Introduction
Basic Control Flow
Platform layer
Console
Simulation
Files, Streams and the Resource Manager
Input Model
Graphics
The Graphical User Interface (GUI)
3D Rendering
Networking
How to Regenerate the Torque Engine Reference
Additional Info
Is this the C++ documentation? Where is class, structure, functions refference? So all C++ documentation is a small chapter of some book?
12/01/2006 (1:50 pm)
I tried to read some C++ documentation, but it is for customers only. I managed to copy some table of contents:6. Engine Coding in C++ (Licensed Users Only)
Introduction
Basic Control Flow
Platform layer
Console
Simulation
Files, Streams and the Resource Manager
Input Model
Graphics
The Graphical User Interface (GUI)
3D Rendering
Networking
How to Regenerate the Torque Engine Reference
Additional Info
Is this the C++ documentation? Where is class, structure, functions refference? So all C++ documentation is a small chapter of some book?
#4
12/01/2006 (1:58 pm)
I know from BootCamp that there's documentation on TDN for the C++ hierarchy at least, but I don't have TGE so I can't access it on TDN ;)
#5
the header files are your doc.
clean organized relationships that stand out are your guidance.
you simply pick a high level object and follow it down.
it is Easier than reading doc, faster and more informative.
documentation gets out of date fast.
API documentation is a sleeper.
viewing procedures and objects is a much cleaner more concise method.
when using header files super class's and implementation details.
torque is heavily documented by example usage, which should be the most usefull to you.
sorry I could not resist to offer my opinion and method.
as I find it for me to be more usefull than pages of sleeping material.
just my 2 cents.
I am sure you would do just as well to study some of the base objects and thier implementation.
for example, the Item class, study the parent class here.
study the exposed functionality via the header.
dive into the implementation details, the scriptable attributes.
yadayada..
much easier, and higher pay.
12/01/2006 (2:12 pm)
I've always been facinated by people who think they need doc.the header files are your doc.
clean organized relationships that stand out are your guidance.
you simply pick a high level object and follow it down.
it is Easier than reading doc, faster and more informative.
documentation gets out of date fast.
API documentation is a sleeper.
viewing procedures and objects is a much cleaner more concise method.
when using header files super class's and implementation details.
torque is heavily documented by example usage, which should be the most usefull to you.
sorry I could not resist to offer my opinion and method.
as I find it for me to be more usefull than pages of sleeping material.
just my 2 cents.
I am sure you would do just as well to study some of the base objects and thier implementation.
for example, the Item class, study the parent class here.
study the exposed functionality via the header.
dive into the implementation details, the scriptable attributes.
yadayada..
much easier, and higher pay.
#6
As for me, I am a person who likes to build his own work from beginning to the end and control every aspect of game. I hate learning sdk by samples, because I need to know what every single line of program does - not counting that other guy wrote it correctly.
As for header files - there are hundreds of headers in source - and how long it will take to review them? at least months. And a group of programmers surely can write average 3d engine in about 6 monts. That is why I need docs - not header files. You see, using engine must make work easier, not harder. at least, from my point of view. :)
12/01/2006 (2:22 pm)
BadguyAs for me, I am a person who likes to build his own work from beginning to the end and control every aspect of game. I hate learning sdk by samples, because I need to know what every single line of program does - not counting that other guy wrote it correctly.
As for header files - there are hundreds of headers in source - and how long it will take to review them? at least months. And a group of programmers surely can write average 3d engine in about 6 monts. That is why I need docs - not header files. You see, using engine must make work easier, not harder. at least, from my point of view. :)
#7
you have chosen a Really long road in development.
using an engine it is not required you know nor understand every component.
it is huge.
a more practical analysis would be to only analyze related components relative to the task at hand.
if you choose the undertaking that you must know and understand all code involved in the entire system
I am afraid you will grow old trying to accomplish the simplest things.
and given that you have only alloted a week to get to know the engine, you are really pushing the limits.
you can rest assured that when you attempt to do something, it either works or it does not.
so relying on the code that lays your foundation is the first logical step.
the whole reason to pick up an SDK and not hand roll the whole solution is a solid piece of logic representing your desire to not write the whole thing from scratch.
if what you do is take the sdk and examine all the code from all the header files.
there really is not alot of point by the time you understand each component and the code behind it you have wasted enough time to get your own stuff a good start.
when I stated use the header files and implementation, I left an example referencing the Item class.
this is a good case study, as sure the heirarchy is fairly long, but you dont need the whole thing.
you simply examine a couple of the base class's to find the functionality and then study the current derived class for the final implementation.
you do not need to perform this for each header in the project.
only the ones that pertain to the portion of the heirarchy you are currently actively studying.
please dont get me wrong I am not trying to trump your point of view, it is valid and many many developers prefer it to my method.
I'ts just that my method is not always considered, and concerning development speed.
I can guarantee it is faster.
12/01/2006 (3:02 pm)
Hmm,you have chosen a Really long road in development.
using an engine it is not required you know nor understand every component.
it is huge.
a more practical analysis would be to only analyze related components relative to the task at hand.
if you choose the undertaking that you must know and understand all code involved in the entire system
I am afraid you will grow old trying to accomplish the simplest things.
and given that you have only alloted a week to get to know the engine, you are really pushing the limits.
you can rest assured that when you attempt to do something, it either works or it does not.
so relying on the code that lays your foundation is the first logical step.
the whole reason to pick up an SDK and not hand roll the whole solution is a solid piece of logic representing your desire to not write the whole thing from scratch.
if what you do is take the sdk and examine all the code from all the header files.
there really is not alot of point by the time you understand each component and the code behind it you have wasted enough time to get your own stuff a good start.
when I stated use the header files and implementation, I left an example referencing the Item class.
this is a good case study, as sure the heirarchy is fairly long, but you dont need the whole thing.
you simply examine a couple of the base class's to find the functionality and then study the current derived class for the final implementation.
you do not need to perform this for each header in the project.
only the ones that pertain to the portion of the heirarchy you are currently actively studying.
please dont get me wrong I am not trying to trump your point of view, it is valid and many many developers prefer it to my method.
I'ts just that my method is not always considered, and concerning development speed.
I can guarantee it is faster.
#8
Yes there a some reference documentation of the SDK, but I wouldn't put the name documentation on it.
Yes there a tutorials, but none that brings you into the engine in a structured manner.
The engine is great, as far as I can grasp at this moment, but the missing documentation is a huge downside of the product.
I can understand that it might be hard to keep up a documenation for this product, but still.... I did expect more.
So please, if anyone have a answer to this question I, and probably the author of this thread, would be very happy.
04/11/2007 (12:41 pm)
But the question of this thread is still not answer. The author has a valid point in the missing of documentation. I find it amazing that not even the code it self has almost not having comment at a bare minimum of what you should be able to expect for a product like this.Yes there a some reference documentation of the SDK, but I wouldn't put the name documentation on it.
Yes there a tutorials, but none that brings you into the engine in a structured manner.
The engine is great, as far as I can grasp at this moment, but the missing documentation is a huge downside of the product.
I can understand that it might be hard to keep up a documenation for this product, but still.... I did expect more.
So please, if anyone have a answer to this question I, and probably the author of this thread, would be very happy.
#9
http://www.garagegames.com/docs/tge/general/ch06s12.php
04/11/2007 (12:51 pm)
Http://www.garagegames.com/docs/tge/general/http://www.garagegames.com/docs/tge/general/ch06s12.php
#10
Some of us dont have programming degrees, but we still want to have fun and enjoy the experience, Im not descourging a person from using the search function or interacting with the great community here. But you have to see that newpeople or people who are being frustrated by the lack of or conflicting code for both the engine and the Torque scripts. I personally have been lucky and took a few months to get my bearings within torque and have learned quite a bit (enough to enter the Mydreamrpg 1 year contest).
Just my 2 cents
04/11/2007 (1:03 pm)
I have to agree, with the author and carl, while there has been a bit of resent improvement in TDN, and tons of information in regards information within header. It would be much simplier for a novice game maker, to understand what is inside The hood of Torque. It true that some people wont touch much of the engine while theyare making thier game, but having the ability to make a informed decision, and thus make a more complete use of the items in the engine. Since 1.2 the engine as i have gathered, has had hundred of changes and objects added to it. as noted above to go through it all true does take time. But it would be nice to have a some further progress to detail some of the engine functionaility. Some of us dont have programming degrees, but we still want to have fun and enjoy the experience, Im not descourging a person from using the search function or interacting with the great community here. But you have to see that newpeople or people who are being frustrated by the lack of or conflicting code for both the engine and the Torque scripts. I personally have been lucky and took a few months to get my bearings within torque and have learned quite a bit (enough to enter the Mydreamrpg 1 year contest).
Just my 2 cents
Associate David Montgomery-Blake
David MontgomeryBlake
2. There is not a C++ book available for Torque. TDN has a what's new section for 1.5. The bug fixes have been rolled into 1.4.2.