Torque and modifications
by Stefan Lundmark · 10/09/2006 (11:37 am) · 29 comments
I purchased Torque back in 2004. At that time, I had no clue it would change my life. This is not a fanboy blog praising all of Torque, but an honest opinion of someone that, 2 years ago, had no programming experience whatsoever. I have always had problems with math and left school with quite bad grades.
Still, it worked out just fine for me. I hear many experienced programmers saying Torque is a mess and hard to learn, and I can not help but wonder how much time they have spent with it until they dismissed it.
Now, I'm going to talk about some of the modifications I have made recently, and to some degree: why I made them.
FMOD
I very recently implemented this into Torque and replaced OpenAL completely. As our game has a very focus on sounds, we felt it was needed. I'm currently playing around with LowPass filters. FMOD has so far been wonderful to code with, and reminds me about Torque alot.
I felt that the OpenAL implementation had a long way to go before it can be considered useful and I did not find its structure easy to understand so I did not bother to rewrite it.
ShapeBaseImage & a new MuzzleFlash class
This one was a tough nut to crack. We have alot of fast fireing machine guns in our game, and ShapeBaseImage does not seem to have been designed with that in mind. It is great for equipment though so we ended up creating a seperate class - we can call it weaponImage for the sake of this plan.
There are too many changes to name them all here, but the key ones are:
[*] Seperate 1st/3rd person images, much like HL2's system with one worldShape and a viewShape (different shape files, not to be confused with LOD).
[*] Multiple threads, so you can play more than one thread at once.
[*] The viewShape is static to the viewer, but moves side-to-side when looking around, and back/forward when looking up/down. There is also a seperate thread for move animations - again very much similiar to HL2's system.
[*] A callback into shapeBase which (in simple terms) creates a hitbox to the shapeBase object (and not to the image since it does not tick) if isCollidable is set to true in the image datablock. This way you can interact with the image.
I also designed a seperate client-only muzzleFlash class, that is built up by one single plane that changes texture depending on the direction of the viewer and the eyeVector. No need for complex shapes there. Big thanks to Melv May's documentation about rendering objects!
A new simple flying vehicle class, based on ShapeBase.
This is the one that took most of my time away during June-August. I had a simple flying vehicle class using clippedPolyList, and simplePolyList from the TankPack (which was VERY useful in understanding how collisions are handled on player-like shapes) but I ended up not using it because the physics were too simple, even for our arcade-like needs.
Martin Schultz and I discussed a little bit about flying vehicle issues by email and this awoke my interest in the subject again. So I redesigned the class and ended up with what I have now: A pretty simple flyer, yet that behaves as you would expect a flyer to. It does not have a rigid body, though - but is even lighter on CPU than the player itself.
Conclusion
I've got a few more major modifications that I have made, but time is running out and I think the above already illustrates my final point: ANYONE can learn this stuff (Torque :P) and go far, given sufficent time and dedication!
Thanks!
Still, it worked out just fine for me. I hear many experienced programmers saying Torque is a mess and hard to learn, and I can not help but wonder how much time they have spent with it until they dismissed it.
Now, I'm going to talk about some of the modifications I have made recently, and to some degree: why I made them.
FMODI very recently implemented this into Torque and replaced OpenAL completely. As our game has a very focus on sounds, we felt it was needed. I'm currently playing around with LowPass filters. FMOD has so far been wonderful to code with, and reminds me about Torque alot.
I felt that the OpenAL implementation had a long way to go before it can be considered useful and I did not find its structure easy to understand so I did not bother to rewrite it.
ShapeBaseImage & a new MuzzleFlash classThis one was a tough nut to crack. We have alot of fast fireing machine guns in our game, and ShapeBaseImage does not seem to have been designed with that in mind. It is great for equipment though so we ended up creating a seperate class - we can call it weaponImage for the sake of this plan.
There are too many changes to name them all here, but the key ones are:
[*] Seperate 1st/3rd person images, much like HL2's system with one worldShape and a viewShape (different shape files, not to be confused with LOD).
[*] Multiple threads, so you can play more than one thread at once.
[*] The viewShape is static to the viewer, but moves side-to-side when looking around, and back/forward when looking up/down. There is also a seperate thread for move animations - again very much similiar to HL2's system.
[*] A callback into shapeBase which (in simple terms) creates a hitbox to the shapeBase object (and not to the image since it does not tick) if isCollidable is set to true in the image datablock. This way you can interact with the image.
I also designed a seperate client-only muzzleFlash class, that is built up by one single plane that changes texture depending on the direction of the viewer and the eyeVector. No need for complex shapes there. Big thanks to Melv May's documentation about rendering objects!
A new simple flying vehicle class, based on ShapeBase.This is the one that took most of my time away during June-August. I had a simple flying vehicle class using clippedPolyList, and simplePolyList from the TankPack (which was VERY useful in understanding how collisions are handled on player-like shapes) but I ended up not using it because the physics were too simple, even for our arcade-like needs.
Martin Schultz and I discussed a little bit about flying vehicle issues by email and this awoke my interest in the subject again. So I redesigned the class and ended up with what I have now: A pretty simple flyer, yet that behaves as you would expect a flyer to. It does not have a rigid body, though - but is even lighter on CPU than the player itself.
Conclusion
I've got a few more major modifications that I have made, but time is running out and I think the above already illustrates my final point: ANYONE can learn this stuff (Torque :P) and go far, given sufficent time and dedication!
Thanks!
About the author
#2
Very impressive, especially love the muzzle flash's.
Keep up the good work!
- Tim.
10/09/2006 (11:46 am)
About time you leaked some information about your project :PVery impressive, especially love the muzzle flash's.
Keep up the good work!
- Tim.
#3
10/09/2006 (11:49 am)
Awesome stuff. Are you releasing it or part of it as resources by any chance? :) 
#4
Excellent work, excellent.
10/09/2006 (11:52 am)
WHOA. CODE. NOW. LOOKS AND SOUNDS ABSOLUTELY BRILLIANT!!!1oneExcellent work, excellent.
#5
10/09/2006 (12:11 pm)
Good stuff Stefan! Post more screenshots :)
#6
@Rubes:
I recommend it. There is a resource already on GG that shows how to implement FMOD 3, though a bit simple - it is a good start if you're curious! FMOD Ex is more expensive, but easier (IMO) to use. I'm using the latter.
@Tim:
Hopefully I did not leak too much. Most of it is still up in the air and not set in stone yet.
I need better graphics for those muzzle flashes, right now they look too solid. You should write a plan about your progress. I'm always curious but never see anything, just samples were you post your little tutorials on the forums :)
@Oliver & C2:
This is always a pushing question. We do not use the same ShapeBase class as stock Torque, for instance. I am honestly not very motivated to spend the time and make it work with stock Torque, simply because it would take alot of time that I can not afford. It took me several months to get it all working, and it is an integral part of our game. I will help anyone with pointers and suggestions though, if you are going to try yourself.
Edit: I want to be clear. I am unemployed and I live very sparingly. Getting our project up is highest priority and I find myself sacrificing stuff for the game, *let alone* rewriting and releasing stuff for free. I might get impopular for saying that, but I am just being honest with you guys.
The muzzleFlash might get resourced, simply because it is seperate from everything else and requires very few changes in shapeBaseImage.
10/09/2006 (12:13 pm)
Hi guys,@Rubes:
I recommend it. There is a resource already on GG that shows how to implement FMOD 3, though a bit simple - it is a good start if you're curious! FMOD Ex is more expensive, but easier (IMO) to use. I'm using the latter.
@Tim:
Hopefully I did not leak too much. Most of it is still up in the air and not set in stone yet.
I need better graphics for those muzzle flashes, right now they look too solid. You should write a plan about your progress. I'm always curious but never see anything, just samples were you post your little tutorials on the forums :)
@Oliver & C2:
This is always a pushing question. We do not use the same ShapeBase class as stock Torque, for instance. I am honestly not very motivated to spend the time and make it work with stock Torque, simply because it would take alot of time that I can not afford. It took me several months to get it all working, and it is an integral part of our game. I will help anyone with pointers and suggestions though, if you are going to try yourself.
Edit: I want to be clear. I am unemployed and I live very sparingly. Getting our project up is highest priority and I find myself sacrificing stuff for the game, *let alone* rewriting and releasing stuff for free. I might get impopular for saying that, but I am just being honest with you guys.
The muzzleFlash might get resourced, simply because it is seperate from everything else and requires very few changes in shapeBaseImage.
#7
10/09/2006 (12:42 pm)
that looks really nice Stefan, I love that shot in the dark with the light coming off of the vehicle.
#8
10/09/2006 (12:47 pm)
I've been wondering what other options there are for upgrading the sound in torque. Good job on it all! 
#9
It's pretty exciting, though. I'm especially interested in your viewShape and worldShape changes. They sound pretty damn cool!
Can't wait to see more on this!
10/09/2006 (1:10 pm)
Nice. I have recently been looking at FMOD as well, though for my purposes the environmental sound resources have been working very nicely with stock AL.It's pretty exciting, though. I'm especially interested in your viewShape and worldShape changes. They sound pretty damn cool!
Can't wait to see more on this!
#10
10/09/2006 (1:19 pm)
Great work, cant wait to find out more about your project
#11
10/09/2006 (1:33 pm)
Looking great Stefan! Your bringing sexy back to torque :P, can't wait to hear more about it. I wish you well with it!
#12
Aye, thanks! Looking forward to seeing more about the Lounge, too.
@Tom:
The possibilities are endless. I can not talk much about this, and do not know much about it either - but there is another community member working on a FMOD implementation in Torque. I would had released mine as a Content Pack, but he has been working on his for a while and he was first. Keep your eyes out for news! :)
@David:
I have not seen the enviormental resource for AL before, interesting. Part of the reason for my choice of FMOD is because of the virtual voices though. That's one seller for me.
As for the viewShape/worldShape stuff, it's not really rocket science :) Just two different shapes, the worldShape being authorative, and the viewShape mimicing animations and states. The viewShape is also predicted on the client, which makes for a more smooth experience when there is alot of latency to the server - but sacrifices accuracy in that the client might be wrong.
@James & Max
Thanks guys!
10/09/2006 (2:38 pm)
@Clint: Aye, thanks! Looking forward to seeing more about the Lounge, too.
@Tom:
The possibilities are endless. I can not talk much about this, and do not know much about it either - but there is another community member working on a FMOD implementation in Torque. I would had released mine as a Content Pack, but he has been working on his for a while and he was first. Keep your eyes out for news! :)
@David:
I have not seen the enviormental resource for AL before, interesting. Part of the reason for my choice of FMOD is because of the virtual voices though. That's one seller for me.
As for the viewShape/worldShape stuff, it's not really rocket science :) Just two different shapes, the worldShape being authorative, and the viewShape mimicing animations and states. The viewShape is also predicted on the client, which makes for a more smooth experience when there is alot of latency to the server - but sacrifices accuracy in that the client might be wrong.
@James & Max
Thanks guys!
#13
The OpenAL audio system is actually quite simple. It basically boils down to :
1) It manages a fixed number of sources (i.e. objects which control where the sound is, where its pointing, how far away you can hear it, etc), which are created with the OpenAL api when the audio system starts.
2) There are two types of sounds: Static and Streaming. The Static sounds are played from a buffer obtained by the AudioBuffer class. The streaming sounds are played from multiple, queued buffers managed by the AudioStreamSource class. Each update the buffers are refilled for streaming sound's if neccesary.
2) Each update the sources are scored according to distance. The ones with the lowest score (typically the furthest away) are the ones that get turned off (culled) first if the sources are used up (e.g. in heavy gunfire). Streaming sounds are scored highest, so they are less likely to be culled off.
3) Usually when a source is culled, it is will be forgotten. Unless of course it loops, or is streaming. There are two objects which can retain information about a source when it is culled.
4) A Static looping sound is managed by the looper list. This list is also scored as with the other sound's. It is also checked each update to see if any loopers are a candidate for re-activation. If so, they are reactivated according to the information stored.
5) A Streaming sound is managed by the streamer list. This list is pretty much managed in the same way as the looper list.
6) When you reference a playing or otherwise active sound, you use an AUDIOHANDLE. This is essentially just a number which is assigned from an incremented count variable. AUDIOHANDLE's are associated with source's via a reference list, and also in the looper and streamer lists.
7) The Audio::Description struct is used as a handy container for specifying values of various variables to set for the OpenAL Sources.
I should also mention that the streamer list is a bit of a hack. It'd probably be better if it was merged into the looper list.
That's about it. Of course, there's a whole lot more to the audio system (e.g. the volume channels), but that just about sums up the basic concept.
10/09/2006 (3:19 pm)
@Stefan:The OpenAL audio system is actually quite simple. It basically boils down to :
1) It manages a fixed number of sources (i.e. objects which control where the sound is, where its pointing, how far away you can hear it, etc), which are created with the OpenAL api when the audio system starts.
2) There are two types of sounds: Static and Streaming. The Static sounds are played from a buffer obtained by the AudioBuffer class. The streaming sounds are played from multiple, queued buffers managed by the AudioStreamSource class. Each update the buffers are refilled for streaming sound's if neccesary.
2) Each update the sources are scored according to distance. The ones with the lowest score (typically the furthest away) are the ones that get turned off (culled) first if the sources are used up (e.g. in heavy gunfire). Streaming sounds are scored highest, so they are less likely to be culled off.
3) Usually when a source is culled, it is will be forgotten. Unless of course it loops, or is streaming. There are two objects which can retain information about a source when it is culled.
4) A Static looping sound is managed by the looper list. This list is also scored as with the other sound's. It is also checked each update to see if any loopers are a candidate for re-activation. If so, they are reactivated according to the information stored.
5) A Streaming sound is managed by the streamer list. This list is pretty much managed in the same way as the looper list.
6) When you reference a playing or otherwise active sound, you use an AUDIOHANDLE. This is essentially just a number which is assigned from an incremented count variable. AUDIOHANDLE's are associated with source's via a reference list, and also in the looper and streamer lists.
7) The Audio::Description struct is used as a handy container for specifying values of various variables to set for the OpenAL Sources.
I should also mention that the streamer list is a bit of a hack. It'd probably be better if it was merged into the looper list.
That's about it. Of course, there's a whole lot more to the audio system (e.g. the volume channels), but that just about sums up the basic concept.
#14
10/09/2006 (4:28 pm)
those ships in the last pic look like cylon ships...
#15
10/09/2006 (7:21 pm)
The muzzle flash is my biggest desire, an easier implementation, especially one that is able to be randomized. 1st/3rd difference without LOD is not a priority; I know my LOD code/script and I am able to use it to its fullest extent with no problem. I'd love to see a resource though on the muzzle items.
#16
Jon Jorajuria added the resources when working on Todd Picken's FPS content pack.
Shapebase animation trigger
Embedded DTS sound
They're both two "duh, why wasn't this in there in the first place" type additions. I love the simple little things that add so much.
10/09/2006 (7:22 pm)
@StephanJon Jorajuria added the resources when working on Todd Picken's FPS content pack.
Shapebase animation trigger
Embedded DTS sound
They're both two "duh, why wasn't this in there in the first place" type additions. I love the simple little things that add so much.
#17
I want to try your flyingvehicle class!!! :-) (if possible) I'm very much interested how it "feels" to fly with your vehicle class compared to mine. I'm currently relocating back to Hamburg so I'm a bit short in time (and don't have Internet at home atm), but I'm really interested in this. I guess I should wrap up my Subsonic prototype and send it over to you.
Best,
Martin :-)
10/10/2006 (12:52 am)
Hey Stefan! Nice read and good progress on your stuff! I want to try your flyingvehicle class!!! :-) (if possible) I'm very much interested how it "feels" to fly with your vehicle class compared to mine. I'm currently relocating back to Hamburg so I'm a bit short in time (and don't have Internet at home atm), but I'm really interested in this. I guess I should wrap up my Subsonic prototype and send it over to you.
Best,
Martin :-)
#18
10/10/2006 (3:39 am)
what are the pros and cons in using fmod instead of openAL?
#19
Thanks for your comment. I was thinking more along the lines of structure, ie the code. I guess I have never worked with anything like that, but it does seem to remind me of OpenGL. OpenAL definatly looks powerful, but to build a layer ontop of it which handles everything a game needs sounds like a lot of work.
@Josiah Wang.
What's a cylon? You got me curious! :)
@David Blake
Oh, it is recent? Another reason to get that pack then.
@Martin Schultz
I will be sending you an email as soon as we have another weekend test. Should be soon.
@Juha E.
Depends who you ask. OpenAL is a rather small crossplatform API which is very lightweight at the expense of features. You need to write your own layer ontop of it which handles channel priority and whatever features you need.
FMOD is not a API, but one of those layers - kind of. It talks with a driver, while openAL talks directly to the hardware.
In regards of features, here is a list of FMOD's features.
10/10/2006 (4:48 am)
@James U.Thanks for your comment. I was thinking more along the lines of structure, ie the code. I guess I have never worked with anything like that, but it does seem to remind me of OpenGL. OpenAL definatly looks powerful, but to build a layer ontop of it which handles everything a game needs sounds like a lot of work.
@Josiah Wang.
What's a cylon? You got me curious! :)
@David Blake
Oh, it is recent? Another reason to get that pack then.
@Martin Schultz
I will be sending you an email as soon as we have another weekend test. Should be soon.
@Juha E.
Depends who you ask. OpenAL is a rather small crossplatform API which is very lightweight at the expense of features. You need to write your own layer ontop of it which handles channel priority and whatever features you need.
FMOD is not a API, but one of those layers - kind of. It talks with a driver, while openAL talks directly to the hardware.
In regards of features, here is a list of FMOD's features.
#20
Yeah, i know what you mean. Regarding OpenAL itself, i don't think its that bad. Just need to read the documentation on openal.org, which is quite to the point :)
I seem to recall they recently incorporated a generic effects api (to replace EAX) into the latest release, so it seems to be going places at least.
Sadly, most game's i've seen recently don't make advanced usage of 3d sound - except of course games such as Half-Life 2. But then again, not every game needs such advanced gimmicky features :)
Regarding time to implement, considering i've redone the audio code twice in my little projects, both times using openal, i could probably cook up another quick implementation in a day or two. Though then again, i could probably say the same for FMOD, provided of course i knew the api :)
10/10/2006 (6:46 am)
@Stefan,Yeah, i know what you mean. Regarding OpenAL itself, i don't think its that bad. Just need to read the documentation on openal.org, which is quite to the point :)
I seem to recall they recently incorporated a generic effects api (to replace EAX) into the latest release, so it seems to be going places at least.
Sadly, most game's i've seen recently don't make advanced usage of 3d sound - except of course games such as Half-Life 2. But then again, not every game needs such advanced gimmicky features :)
Regarding time to implement, considering i've redone the audio code twice in my little projects, both times using openal, i could probably cook up another quick implementation in a day or two. Though then again, i could probably say the same for FMOD, provided of course i knew the api :)
Torque 3D Owner Rubes