by date
Plan for Joshua Ritter
Plan for Joshua Ritter
| Name: | Prairie Games | ![]() |
|---|---|---|
| Date Posted: | Apr 25, 2002 | |
| Rating: | Not Rated | |
| Public: | NO | |
| Comments: | NO | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Prairie Games |
Blog post
TORQUE ON TOP!
Preface: Torque is very powerful and extremely hard work has gone into it. The problem presented here has NOTHING to do with the way the engine is designed... it has to do with how it is linked...
An important news bulletin: Everything that uses Torque code in your project has to be contained within the same module... you can't link from another module to it... currently this means sticking the entire Torque source tree into the exe for your project... this also means that any of your code that uses Torque must reside here too... and since this is what everybody has to do... it means cramming their code in as well...
This is bad-> You CANNOT call a Torque function or derive a Torque class outside of the module the Torque source resides in... to use plain english: royal suckage
Sharing the tool's static library is out because the game can't use one... a static library also doesn't fix the linkage problem of using the code in more than one place:
Illegal:
My.dll linked to static Torque.lib
My.exe linked to My.dll AND static Torque.lib
Furthermore, there is NO NEED for the static library,or the seperate compilation step it necessitates:
Dynamic linking allows people from multiple projects to use Torque in a consistent manner... we can use Torque consistently in our OWN projects and subprojects(tools)... we are not limited in any way WHERE we can use Torque functionality... AND code can be more readily SHARED... as LIBRARIES and _not_ zip files of sources to MERGE INTO your (and Torque's) source tree.
In addition, there are some nice side effects: other development environments and languages being opened to use Torque via the dll. Loading and unloading of code for plugin support, Distribution of new code without a link step to an existing application... etc.
I realize that there is more work to be done and probably some hard changes in store for the API... this doesn't preempt dynamic linking... in fact, dynamic linking is just a step in the process of making Torque shine even brighter
There isn't much work to do: simply adding export declations which can be turned on or off with a define! So if anyone is convinced dynamic linking buys them nothing; they can go on with having the entire engine build down at the lowest level: the application.exe
"Torque on top!"
-Joshua Ritter
This thread has a more indepth though diluted discussion of the topic:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&q...
-J
An important news bulletin: Everything that uses Torque code in your project has to be contained within the same module... you can't link from another module to it... currently this means sticking the entire Torque source tree into the exe for your project... this also means that any of your code that uses Torque must reside here too... and since this is what everybody has to do... it means cramming their code in as well...
This is bad-> You CANNOT call a Torque function or derive a Torque class outside of the module the Torque source resides in... to use plain english: royal suckage
Sharing the tool's static library is out because the game can't use one... a static library also doesn't fix the linkage problem of using the code in more than one place:
Illegal:
My.dll linked to static Torque.lib
My.exe linked to My.dll AND static Torque.lib
Furthermore, there is NO NEED for the static library,or the seperate compilation step it necessitates:
Dynamic linking allows people from multiple projects to use Torque in a consistent manner... we can use Torque consistently in our OWN projects and subprojects(tools)... we are not limited in any way WHERE we can use Torque functionality... AND code can be more readily SHARED... as LIBRARIES and _not_ zip files of sources to MERGE INTO your (and Torque's) source tree.
In addition, there are some nice side effects: other development environments and languages being opened to use Torque via the dll. Loading and unloading of code for plugin support, Distribution of new code without a link step to an existing application... etc.
I realize that there is more work to be done and probably some hard changes in store for the API... this doesn't preempt dynamic linking... in fact, dynamic linking is just a step in the process of making Torque shine even brighter
There isn't much work to do: simply adding export declations which can be turned on or off with a define! So if anyone is convinced dynamic linking buys them nothing; they can go on with having the entire engine build down at the lowest level: the application.exe
"Torque on top!"
-Joshua Ritter
This thread has a more indepth though diluted discussion of the topic:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&q...
-J
Recent Blog Posts
| List: | 03/29/08 - TGEA 1.7 Build System and Embedded Python 03/14/08 - MegaTerrains - TGEA Update 01/18/08 - Minions of Mirth: Undead Wars Expansion 01/04/08 - Physics Overhaul - Video 12/26/07 - Web Integration - Video 12/21/07 - New MMO Client - Trees - Day/Night Video 12/18/07 - Minions of Mirth - 1.26 - Holiday Edition! 11/28/07 - TGB/TGEA integration first pass |
|---|
Submit your own resources!You must be a member and be logged in to either append comments or rate this resource.



Not Rated


