Torque Dynamic Linking and Threading

#21 Josh, I've been a Software Engineer for 20 years. Run-Time Libraries are nice, but hardly transcendent :-).

But you've got the fire-in-the-belly, you've done the legwork, and you don't need our permission, so go do it !
The more you write about it, the longer it will take... :-)

#22 If you'd like to compare, um, integers... I have 9 retail games published... the last engine I wrote was REUSED in 6 of these titles... the last game scoring a 7.3 on Gamespot last week... I believe I am qualified to comment on this subject...

Again:

I stated above that I would do the work... but as it is a MINOR change to about every header file... there probably is a better candidate...

And Again:

Dynamic linking allows multiple people working on multiple projects to use Torque in a consistant manner ... and not as some mutation of Torque Demo... we can use Torque consistantly in our projects and subprojects(tools)... we are not limited in any way WHERE we can use Torque functionality... AND code can be more readily shared...

In addition, there are some nice side effects like: other development environments and languages being opened to use Torque via the dll.

All of this for just 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!"

-J

#23 And the people who wrote this engine have how many commercial retail games under their belts?

Reusable, Modular code does not require being in a DLL files.

But as was pointed out to you:

1. You have the plan
2. You have the desire
3. You have the source code

Make the changes and show that it:

1. Does not harm performance
2. Does not prevent cross-platform compiling without special case coding for the other platforms
3. Does not blur the function of the modularized code sections
4. Does not complicate the install process

#24 ... Flame retraction ...

Damned I love the forum's modify function...

"Torque on Top!"

-J

#25 YOU brought up the number of retail games YOU had done.

YOU are the one preaching that torque is written wrong and should be written with DLL's

'I' am happy with the way it is written, other then the fact that the windows build does not use SDL for CD-Audio, which creates a difference in the cross-platform code.

But the biggest point you keep ignoring is:

You don't have to ask anyone to convert torque to be DLL based.

If that is what you want.... Do it. If you feel others will benefit from what you have done.... share it.

But what you don't need to do is come here and keep harping on the subject until someone else does it for you.

And yes I have compiled torque as multi-threaded and added third party DLL's to it. It worked fine for the short time I tested.

#26 All of the information is here if you are willing to wade for it...

There is a summary in my .plan if you don't "get it" and want to...

I am very serious about the technology I use... if I am going to use Torque I want it to be everything it can be... for myself and others... I don't make arbitrary battles... but I will fight for what is important and this is... others know it, I will have to be satisfied that not EVERYONE knows it...

I would be happy to talk to anyone from GarageGames on this matter... let's see what can be done to move this forward...

I am willing to do the work of getting the visual studio environment setup to use dynamic linkage... this includes adding the export declarations to the header files (whoopee)... and creating a nifty Torque DLL project... this doesn't alter anything for anybody so shaddup already...

I also believe strongly enough in this, that if need be, I offer to fly myself to GarageGames, put myself up in a hotel, and work on getting this adopted onsite.. like I said, I am very serious... it's the only way I have found to get anywhere in the industry...

And remember:

"Torque on top!"

-J

#27 Cool stuff man ..
and dont forget to make it a stdafx project for vs while your at it :)
would prolly make it easier..
you should fly up here and help me finish the door :)

*is just here to mellow things out*

#28 On a side note, just cuz someone has done something a million times before, it by no means makes them right...
The important thing to remember here, is that no matter what, there's no need to get pissy. I'm not gonna name names, lol, because we're all trying to better the engine, even tho I myself may not be capable of mind boggling 3d work as of yet, I'd like to help any way I can.

If you wanna fly out, I'll drive up... Ps, I don't think anyone is "harping until someone else" does it for anyone. After all I don't recall Joshua asking anyone to do this for him...

#29 Joshua,

Clearly you care a whole lot about this issue. Clearly, it is very important to you. You also have spent way more time responding to posts here than it would take to actually make the changes in the code. Why don't you make the changes to the header files and send them off to the GG guys? As long as it is an easy change, and as long as it is #define'd down to no change in the default exe build, I don't see why anyone would have a problem with it.

I still don't see the gain in it, but then again, I also don't see any gain in fighting with you over it.

Josh

#30 The Torque Coding Community,

I have spent hours on this subject... please allow me to present it in the clearest form I have come up with... I sincerely hope that others see the value:

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 as this is what everyone must do... it means cramming any other source you would like to use 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

#31 Am I missing someting, or isnt there a problem with DLL's being windows only?

I'm all for reorganisation into a lib. But (given I'm totally ignorant of our other platforms) I was under the impression DLL's were windows only.

Which kind of makes the DLL idea a bit of a no-go.

How about just making a lib.

Phil.

#32 Linux and Mac both have dynamic linking... a .dll is simply the windows extension for a dynamically linked library...

A static library, other than not working for some of the code in the engine... isn't a very good solution... as per my exhaustive description above and elsewhere...

-J

#33 I have worked with the Half-Life engine for about 3 years now, and I love the way it is setup. Infact I am trying to do something similar to its design with Torque. Basically I am making my EXE load a dll where all the weapons and gameplays will be coded. This will allow my project to have mod support like many other games ( HL, Q3A, UT, SS ). I think this will only better this engine.

So I hope you do this. It does save memory, and it can speed up development in some ways I think. So Josh, if you are still willing to do this, then please do it for the few that would use it. And for the few that don't think it is a good idea they dont have to use it.

#34 and make it easier to hack and cheat!

focus on supporting mods and plugable gameplay thru the scripting engine, with properly designed C++ classes exposed thru the scripting language there is no reason to have to write a single line of C++ to mod the game!

If you are an old time HL'er you know the state of the HL community, cheating and hacking is more rampant than ever with every mod being able to be hacked by just one cheat that integrates into the game so cleanly and smoothly that it can not be detected and appears to be part of the engine from a users standpoint.

#35 I am in the middle of trying to build Torque as a set of multiple libraries on OS X (while simultaneously working on a game, which is dumb, I know....so it is going slow). I have to agree that it is clearly the most efficient way to develop while also being the safest. My problem is the exporting of symbols. I have made multiple module assemblies in Windows but things are different on my Mac.

I think this is not only a good discussion, but a very important one, not only for developers using Torque but for those who are working on it. Frankly, I am surprised that this conversation died here.

#36 Wow, bring out your dead!!!

I am using Torque as a shared library on both OSX and Windows... actually, it's compiled as a standard Python module and combined with a TON of other technology in this manner... C, C++, and Python... :)

-Josh Ritter
Prairie Games

#37 I have not programmed with Python so I am a bit unfamiliar with what you are talking about. However, I am familiar with your *Monty* Python reference ;)