by date
Torque and modifications
Torque and modifications
| Name: | Stefan Lundmark | |
|---|---|---|
| Date Posted: | Oct 09, 2006 | |
| Rating: |  3.8 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Stefan Lundmark |
Blog post
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.
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!
Recent Blog Posts
| List: | 07/03/07 - Improved Max2Dts Exporter 10/09/06 - Torque and modifications 08/14/06 - Thunderstorm, luck, and being alive. 07/26/05 - Plan for Stefan Lundmark 11/02/04 - Plan for Stefan Lundmark |
|---|
Submit your own resources!| Rubes (Oct 09, 2006 at 18:45 GMT) |
| Tim Heldna (Oct 09, 2006 at 18:46 GMT) |
Very impressive, especially love the muzzle flash's.
Keep up the good work!
- Tim.
| Oliver Rendelmann - DerR (Oct 09, 2006 at 18:49 GMT) |
| Chris \"C2\" Byars (Oct 09, 2006 at 18:52 GMT) |
Excellent work, excellent.
| Alienforce (Oct 09, 2006 at 19:11 GMT) |
| Stefan Lundmark (Oct 09, 2006 at 19:13 GMT) |
@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.
Edited on Oct 09, 2006 19:21 GMT
| Clint S. Brewer (Oct 09, 2006 at 19:42 GMT) |
| Tom Bentz (Oct 09, 2006 at 19:47 GMT) |
| David Montgomery-Blake (Oct 09, 2006 at 20:10 GMT) |
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!
| James Thompson (Oct 09, 2006 at 20:19 GMT) |
| Max Thomas (Oct 09, 2006 at 20:33 GMT) |
Edited on Oct 09, 2006 20:35 GMT
| Stefan Lundmark (Oct 09, 2006 at 21:38 GMT) |
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!
Edited on Oct 09, 2006 21:39 GMT
| James Urquhart (Oct 09, 2006 at 22:19 GMT) Resource Rating: 3 |
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.
| Josiah Wang (Oct 09, 2006 at 23:28 GMT) |
| Chris \"C2\" Byars (Oct 10, 2006 at 02:21 GMT) |
| David Montgomery-Blake (Oct 10, 2006 at 02:22 GMT) |
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.
| Martin Schultz (Oct 10, 2006 at 07:52 GMT) Resource Rating: 5 |
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 :-)
| Juha Eerola (Oct 10, 2006 at 10:39 GMT) |
| Stefan Lundmark (Oct 10, 2006 at 11:48 GMT) |
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.
| James Urquhart (Oct 10, 2006 at 13:46 GMT) Resource Rating: 3 |
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 :)
| Steve Flowers (Oct 10, 2006 at 18:37 GMT) |
A Cylon is a race of man-made enemies (evolved robots), established by the original Battlestar Galactica - revived by the coolest show on TV!:
www.scifi.com/battlestar/
I have the first and second seasons on my IPOD:) I recommend it to geeks and non-geeks alike.
Here's the ship that yours resembles closely (the cockpit is nearly identical from what I can see):
Edited on Oct 10, 2006 18:38 GMT
| Stefan Lundmark (Oct 10, 2006 at 20:04 GMT) |
That is funny! It does resemble the Cylon if you only think of the middle section. I have never seen or heard of that before though, gotta check it out! Thanks alot.
| Alienforce (Oct 10, 2006 at 20:31 GMT) |
I would like to know more and maybe see more screenshots from your project is there
any artfolio available somewhere ?
| Stefan Lundmark (Oct 10, 2006 at 21:26 GMT) |
There is very little information and screenshots currently for our project because of the simple fact that we have no dedicated webmaster. Our website was terribly outdated when we shut it down.
I will make sure to include ingame video footage the next time I post a plan. :)
Edited on Oct 10, 2006 21:27 GMT
| Alienforce (Oct 10, 2006 at 21:53 GMT) |
Looking forward to see the video :)
Please let me know if you would need any help mirroring or hosting the files.
| Steve Flowers (Oct 10, 2006 at 23:19 GMT) |
Do check it out. The new season just started on Friday and it just keeps getting better.
Steve
| Joshua Dallman (Oct 12, 2006 at 19:20 GMT) |
Quote:
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. ANYONE can learn this stuff (Torque :P) and go far, given sufficent time and dedication!
We love to hear stuff like this :)
| Jeremiah Fulbright (Oct 13, 2006 at 05:51 GMT) |
We haven't totally reimplemented everything that was originally a part of the game, but most of the core functionality has been ported and rewrote, including script hooks, as needed.
The one thing we want to do, but haven't spent time looking into, is the Sound Occlusion tie-in to BSP which is feasible with how things are done in Torque, but for right now, the design works
| Stefan Lundmark (Oct 13, 2006 at 08:26 GMT) |
I actually tried out the occlusion engine and could not really understand what the big deal with it was. CPU usage skyrocketed. So for now I am staying with simple range checks and lowpass.
You must be a member and be logged in to either append comments or rate this resource.
