Plan for Melv May
by Melv May · 11/18/2005 (3:49 pm) · 43 comments
Hi,
It's me again; the strange guy from the UK who keeps turning up, posting some snazzy images then disappears again! No, I'm not Phil Carlisle, I'm Melv May and if you've not been keeping up with current events, I'm the chap who, for his sins, started a little thing called "Torque Retro" which has grown into a monster known has T2D!
As a continuation from my last few blogs of Jul 27, 2005 and Sep 01, 2005, here's some more info on what I've been doing on this product since v1.0.2 was released. This isn't by any stretch of the imagination a complete summary of what'll be in the v1.1.0 release as there's a whole bunch of stuff I can't demonstrate without breaking the T2D Eula but most of that stuff are just cool ways of doing big things with very little script. More power, less typing and all that. Some of it would only really be appreciated by the early-adopter crowd god bless them.
Onwards...
Well, TGE v1.4 is a big thing in the news at the moment and so it should be as it's a huge technological step from v1.4 not just visually but functionally. The great news is that the T2D v1.1.0 release will come out merged with TGE v1.4 so T2D owners will get all that yummy TGE goodness as part of their investment.
Hard to choose what to demonstrate to T2D owners or how this will affect them but I chose a couple of the more immediately interesting things you'll notice when firing-up your spanking-new T2D SDK...
Yep, you're seeing that right, 600+fps in T2D. You got a better card than a 6800 Ultra? Yes? Well, you'll get a higher FPS then. If you didn't know, previously T2D frame-rate was implicitly capped at approximately 300fps. Now, whether your game runs at 300fps or 600fps won't make a hill-o-beans difference but not having an overhead that ultimately caps your frame-rate can. More professionally, you can give other people frame-rate envy. ;)
Next-up is the GUI system. This has had a major revamp and makes changing GUI elements much more intuitive and just damn slick. Not much to say here apart from showing you it working with T2D...
Something else that GG has been working extremely hard on is the new TDN Wiki. If you've not already been there, go now! On there you'll find info on all GG's products including T2D. As you can see, TDN is an online facility with lots of tutorials/references emerging all the time but what about the T2D SDK itself? Well, between working on T2D I've been adding PDF documentation for systems such as the particle-engine and the new image-map system (see below). If you've never written documentation before then I'd recommend giving it a try; it's so much harder than it looks. For instance, writing the 30-page reference guide for the image-map system took me nearly 3-weeks part-time (including creating/organising all the images)!
I'd be breaking the EULA if I post any of that documentation here but so much work has gone into documentation that I thought it deserved an image! Here's one of the new documents but you'll need a magnifying-glass to read it correctly...
T2D Image-Map PDF
Whilst I'm on the subject of Image-Maps, let me talk a little about the serious amount of work that has gone into the new image-map system.
Before I do though, for those who haven't got a clue what I'm talking about, image-maps are a setup in T2D that allows you to specify how frames are located within an image. These frames are then used by sprites etc. The previous SDK used this system well but it wasn't without problems.
One of the problems came about because T2D utilises your 3D hardware. One of the constraints, on alot of graphics cards, is that imagery has a size constraint in that it must be a power-of-two (POT) in width/height. Also, there's a maximum supported size on every graphics card that varies from an older 256 to a modern 4096. Now all this is a right-royal-pain, particularly for those coming from other 2D engines that simply 'blitted' the bitmaps to video-memory. Well, there's not alot we can do about this in your hardware but what we can do is make T2D smarter by automatically 'dealing' with this type of imagery for you.
For example, it's common for an artist, particularly ones not aware of these technological limitations of graphics-cards to produce an image like this...
I've actually scaled this down but this image was originally 4000x200 pixels in size. Now as you can see, neither the width/height is a POT in size but more serious is that one of the dimensions is huge. Only the more modern graphics cards could even begin to handle this size texture but lots of cards would just bail. The next release of T2D wouldn't even blink at this because it passes it through it's new frame-packing routine and sends an image to the graphics-card like this...
This kind of improvement is part of our new "just-do-it" (tm) technology. ;) Seriously though, what we don't want to see on the forums is people struggling with the little things. You want T2D to use your image in a sprite, just use it. No need to worry about the size. If you're a veteran and want to know what exactly is going on and take control of key stages either per image-map or globally then no problem; we expose all sorts of stuff that'll excite veterans and scare to death novices. Choice is the key here.
Another problem that has been causing problems for people has been graphics artifacts. These artifacts are not caused by bugs in T2D but by filtering on the graphics card. This kind of thing is hard to explain to those who know very little about graphics-cards but essentially, when a graphics-card renders a pixel it can sample the neighbour texels in your images. The problem with this is when you're using an image such as this...
If you we're using the 'water' frame in the bottom-right, everything would be fine but if you used this frame in something like a tile-map the graphics-card, when rendering the edges of the frame would actually average texels from the adjacent frames e.g. both the 'wooden' tiles in the top-right and bottom-left. You'd end up with artifacts like this...
This is a nightmare problem but luckily there is a nice solution, you can get your artist to place a single-pixel border around your frames so that when the graphics-card samples neighbour texels, it gets a similar texture-colour and you don't get the artifact. Well, this sounds like something that a computer is good at and quite frankly, is a stupid thing to ask a user to do.
To this end, I developed a new feature that you can turn on/off which does this frame-padding for you, selectable per image-map. Just turn it on and the artifacts are gone. It doesn't change your art, it's done in memory before uploading to your graphics-card.
Not all the development has been to solve problems in image-maps. On the contrary, we've added features that extend the functionality that you've already been using. One of these features is the ability to link image-maps. What does this mean? Well, an image-map defines a set of frames in a single-bitmap. These frames can be 'acquired' in different modes such as regular cells or colour-keying. The point here is that an image-map gets it information from a single-bitmap. I wanted to change this limitation but I did it in a slightly different way than expected that gives you a whole bunch of other possibilities.
T2D now lets you link image-maps together, irrelevant of what images they use, how many frames they have, the sizes of the frames or what mode they use for acquisition. You can link as many image-maps together as you want and use it for animations, sprites ... whatever. If you've got a whole bunch of images that define your 'player' you can define a set of image-maps that are linked together as a single name and use that for whatever you want. The great thing is that you can use many different methods to acquire these frames but still use them seemlessly as one. On-top of this, T2D will also deal with all the other options such as the 'padding' described above.
One of the most-used image-map modes was "CELL" mode. In this mode, you define a regular array of cells (frames) and T2D goes away and uses these. Because this is the bread-and-butter image-map mode, it's been extended to a point where it's bursting! You can leave it in its default state and it'll work as before but you can specify all sorts of other things. For example, you can define the scan directions independantly horizontally and vertically, the cell stride so frames can have spacings between them, the start-point for acquiring cells and much more. For instance, there's no way you could extract the four frames from the following image in the previous release...
... without grabbing the famous character hidden behind the tiles. You now can! You could also grab those frames from different directions and even get T2D to automatically worry about how many tiles to expect in either direction.
Okay, you've seen me talk about 'acquiring' frames from images above but what the hell am I talking about here? Well, take the previous image with 'homer' in the background. If you used this in the previous release, the whole image would've gone to the graphics card even though you were only interested in the four frames. Worse, if the image wasn't a POT in size then T2D would be forced to resize it to the next POT in size and upload that! As the sizes get bigger, the next POT can be huge resulting in a massive waste of video-memory. No fear, if you used this in T2D now, you'd get this...
... minimal use, minimal waste. This is the new image-map packing system working. When you get your sticky hands on the new release you'll be able to browse the code yourself but for now, I'll just say that I'm pretty god damn happy with it. The system first looks at your graphics-card to determine the constraints in which it has to work. It then uses this information when you create an image-map. It takes your frames and uses a special tree-algorithm similar to that used when packing lightmaps and packs your frames into a texture that most suits your graphics-card. T2D will also split-up the frames across textures if they absolutely will not fit into a single supported texture on the current graphics-card.
On top of this, it takes parameters (that you can configure) such as whether you prefer performance or least wasted-space. Ultimately, a single frame cannot be larger than the maximum supported by the graphics-card that T2D is running against and so this brings up another feature that I've developed, image-map runtime information.
The new system hasn't just added a bunch of features with no regards to how the system reacts when something goes wrong either trivially or seriously. The new system has a huge array of functions available to both scripts and C++ that allow you to interrogate and control image-maps. You can control the more obvious things like filtering-modes but also fetch frame-counts/sizes, texture-pages, frame-counts in specific texture-pages and much, much more.
Some great features are the image-map callbacks. There's a handful of callbacks that'll interest people who want to both manage image-maps in detail but more importantly want the ability to manage situations where an image-map is not supported by the current hardware and possibly switch to another one or specify other parameters. T2D provides callbacks when packing begins/ends for each image-map as well as an error-callback if something goes wrong. The error callback is very informative and provides a plain-english string for the error as well as a fixed error number that you can programatically use to recover somehow. A basic use for the packing callbacks would be to show a progress bar if you were uploading alot of images.
A new feature in T2D are the system variables. These are preferences that make system-wide changes to the way T2D works. In this context, there are half-a-dozen for image-maps alone. These control things such as telling T2D to dump complete statistics for each and every image-map that is processed (all source to destination frame sizes, texture-page counts etc), echoing errors to the console, overriding the maximum texture size (as reported by the graphics card), dumping all the resultant packed images (before they go to the graphics-card) to disk and much more.
Enough about image-maps I hear you say!! Okay, what shall I show you now? Hmm ... I know, the particle-engine.
One of the things asked for in the forums was the ability to use the hardware blending-modes in the particle-engine and this is what I've done. The possibilities this produces are fairly endless. Now, when you're editting a particle-emitter (within a particle-effect), it can have it's own source/destination blend modes just as all the other objects can. You don't set this at the effect-level but at the emitter-level meaning that a particle-effect can comprise of many emitters, each with its own hardware blending just like tile-maps/layers can. This can lead to very cool effects, none of which I've had time to produce. ;)
Here's a simple image showing the option in the particle-editor and a movie showing it working...
Per-Emitter Hardware Blending Movie
Another feature that was asked for was the ability to simply specify a target position/rotation and automatically get the object to move to that location/rotation. This I've done for you but as you should expect by now, I've try to go a little further for you. You can now go to an object and do something like this...
... and this will do exactly what has been asked for. What it won't do is rigidly move to that point! What I mean by this is that I never want to put in a feature that temporarily bypasses all the other systems that apply to an object. When you do this, if the object responds to collisions, it will react and possibly not get to the point. How does T2D know it was interrupted? It doesn't! What's going on here is split up into two levels. The first level are a couple of new options for all objects; these are setting a target position/rotation. You do this using something like...
These commands (plus their many options) allow you to specify a location/rotation at which point a set of things can optionally happen such as stopping the object from moving and/or actioning a callback. This means that you can tell T2D to inform you when a specific position/rotation is reached and/or automatically stop. What has this to do with the "moveTo"/"rotateTo"? Well, these commands are really a hybrid of the target-commands shown. When you use them, they automatically set the target position/rotation you specify and calculate the required velocities to move to the position/rotation. The great thing here is that you can use the features seperately for all kinds of things. All these commands have a "fuzzy" option that allows you to specify a region that counts as hitting the target so you don't have to be exactly at the specified position/rotation.
Here's a very basic image of me pointing to a location and simply issuing a "moveTo" command on a particle-effect. The thing to remember is that this is done with almost no code. As you can see, it simply moves to the location that I specify, not exciting but I had to show you something right? ...
Move-To Movie
Okay, it's getting very late here and I've been working on T2D all day so I'm going to talk about one more feature. The one I've chosen should have an appeal to almost anyone on these forums but especially to the existing T2D owners who have either asked for it or have spoken about games that would need it ... it's the ability to used standard TGE DTS objects fully-featured in T2D. By this, I don't mean get a static DTS and just render it on the screen over/under T2D objects, I mean, render inside layers, move around using all the standard physics/collisions, blending, sizing, positioning etc. By fully-featured I'm referring to compatibility with DTS features. Here I've tried to get everything in that I can!
Before I say anymore, here's T2D with a whole bunch of Strategem#1 and Strategem#2 DTS objects up and running. Here's a list of things that I've added support for when using the new t2dShape3D object...
- Load arbitrary shape files (*.dts)
- Load/Associate animation files (*.dsq)
- Play by animation name or sequence number e.g. "move", "idle", "fight" etc
- Animation time-scale
- Smooth-blended animation transitions
- Override object render scale
- Override object render center (offset)
- Multiple skin/skin-set support
- 3D Quaternion rotation
- 3D Quaternion angular velocity
- Full Animation Trigger support (custom callback per trigger)
- Full Detail level (plus intra detail level) support
The use of these shapes is totally seamless with what you've used before. The great thing is that they fully integrate with everything else so physics, camera, blending, moving, mounting is all done using the core functions. As an example, here's a bunch of movies showing me selecting 3D shapes with the mouse, zooming-in on them, moving them around, mounting them to each other etc...
t2dShape3D Move #1
t2dShape3D Move #2
t2dShape3D Move #3
Phew! It's nearly midnight here and I've been working since 5.30am so that's like, err, lots of hours so I need some sleep. I'd just like to say that I'm sorry that I hadn't done a plan earlier but sometimes it's easier to sit and work on T2D than to put out a plan. Both are working for T2D owners but I guess one is more visible than the other. We've promised to put out an early beta version of T2D but it is unlikely that this'll include everything, certainly not the TGE v1.4 merge but at least everything I've mentioned in this plan.
All in all, lots of hard work has got us to this point. We've had to make hard decisions on what goes in and what doesn't. With the best will in the world, you can't do everything so not everyone will be happy but we're hoping that we've covered 95% of what we feel is needed to allow people to put out a solid product using T2D.
The great news is that when this is shipped, we've got a whole bunch of further development on the books and to say that work will be exciting is an understatement!! All you have to do is take this release, make a whole bunch of games and get them distributed. In the meantime, we'll be making your investment worth even more to you.
- Melv.
T2D Dev
It's me again; the strange guy from the UK who keeps turning up, posting some snazzy images then disappears again! No, I'm not Phil Carlisle, I'm Melv May and if you've not been keeping up with current events, I'm the chap who, for his sins, started a little thing called "Torque Retro" which has grown into a monster known has T2D!
As a continuation from my last few blogs of Jul 27, 2005 and Sep 01, 2005, here's some more info on what I've been doing on this product since v1.0.2 was released. This isn't by any stretch of the imagination a complete summary of what'll be in the v1.1.0 release as there's a whole bunch of stuff I can't demonstrate without breaking the T2D Eula but most of that stuff are just cool ways of doing big things with very little script. More power, less typing and all that. Some of it would only really be appreciated by the early-adopter crowd god bless them.
Onwards...
Well, TGE v1.4 is a big thing in the news at the moment and so it should be as it's a huge technological step from v1.4 not just visually but functionally. The great news is that the T2D v1.1.0 release will come out merged with TGE v1.4 so T2D owners will get all that yummy TGE goodness as part of their investment.
Hard to choose what to demonstrate to T2D owners or how this will affect them but I chose a couple of the more immediately interesting things you'll notice when firing-up your spanking-new T2D SDK...
Yep, you're seeing that right, 600+fps in T2D. You got a better card than a 6800 Ultra? Yes? Well, you'll get a higher FPS then. If you didn't know, previously T2D frame-rate was implicitly capped at approximately 300fps. Now, whether your game runs at 300fps or 600fps won't make a hill-o-beans difference but not having an overhead that ultimately caps your frame-rate can. More professionally, you can give other people frame-rate envy. ;)
Next-up is the GUI system. This has had a major revamp and makes changing GUI elements much more intuitive and just damn slick. Not much to say here apart from showing you it working with T2D...
Something else that GG has been working extremely hard on is the new TDN Wiki. If you've not already been there, go now! On there you'll find info on all GG's products including T2D. As you can see, TDN is an online facility with lots of tutorials/references emerging all the time but what about the T2D SDK itself? Well, between working on T2D I've been adding PDF documentation for systems such as the particle-engine and the new image-map system (see below). If you've never written documentation before then I'd recommend giving it a try; it's so much harder than it looks. For instance, writing the 30-page reference guide for the image-map system took me nearly 3-weeks part-time (including creating/organising all the images)!
I'd be breaking the EULA if I post any of that documentation here but so much work has gone into documentation that I thought it deserved an image! Here's one of the new documents but you'll need a magnifying-glass to read it correctly...
T2D Image-Map PDF
Whilst I'm on the subject of Image-Maps, let me talk a little about the serious amount of work that has gone into the new image-map system.
Before I do though, for those who haven't got a clue what I'm talking about, image-maps are a setup in T2D that allows you to specify how frames are located within an image. These frames are then used by sprites etc. The previous SDK used this system well but it wasn't without problems.
One of the problems came about because T2D utilises your 3D hardware. One of the constraints, on alot of graphics cards, is that imagery has a size constraint in that it must be a power-of-two (POT) in width/height. Also, there's a maximum supported size on every graphics card that varies from an older 256 to a modern 4096. Now all this is a right-royal-pain, particularly for those coming from other 2D engines that simply 'blitted' the bitmaps to video-memory. Well, there's not alot we can do about this in your hardware but what we can do is make T2D smarter by automatically 'dealing' with this type of imagery for you.
For example, it's common for an artist, particularly ones not aware of these technological limitations of graphics-cards to produce an image like this...
I've actually scaled this down but this image was originally 4000x200 pixels in size. Now as you can see, neither the width/height is a POT in size but more serious is that one of the dimensions is huge. Only the more modern graphics cards could even begin to handle this size texture but lots of cards would just bail. The next release of T2D wouldn't even blink at this because it passes it through it's new frame-packing routine and sends an image to the graphics-card like this...
This kind of improvement is part of our new "just-do-it" (tm) technology. ;) Seriously though, what we don't want to see on the forums is people struggling with the little things. You want T2D to use your image in a sprite, just use it. No need to worry about the size. If you're a veteran and want to know what exactly is going on and take control of key stages either per image-map or globally then no problem; we expose all sorts of stuff that'll excite veterans and scare to death novices. Choice is the key here.
Another problem that has been causing problems for people has been graphics artifacts. These artifacts are not caused by bugs in T2D but by filtering on the graphics card. This kind of thing is hard to explain to those who know very little about graphics-cards but essentially, when a graphics-card renders a pixel it can sample the neighbour texels in your images. The problem with this is when you're using an image such as this...
If you we're using the 'water' frame in the bottom-right, everything would be fine but if you used this frame in something like a tile-map the graphics-card, when rendering the edges of the frame would actually average texels from the adjacent frames e.g. both the 'wooden' tiles in the top-right and bottom-left. You'd end up with artifacts like this...
This is a nightmare problem but luckily there is a nice solution, you can get your artist to place a single-pixel border around your frames so that when the graphics-card samples neighbour texels, it gets a similar texture-colour and you don't get the artifact. Well, this sounds like something that a computer is good at and quite frankly, is a stupid thing to ask a user to do.
To this end, I developed a new feature that you can turn on/off which does this frame-padding for you, selectable per image-map. Just turn it on and the artifacts are gone. It doesn't change your art, it's done in memory before uploading to your graphics-card.
Not all the development has been to solve problems in image-maps. On the contrary, we've added features that extend the functionality that you've already been using. One of these features is the ability to link image-maps. What does this mean? Well, an image-map defines a set of frames in a single-bitmap. These frames can be 'acquired' in different modes such as regular cells or colour-keying. The point here is that an image-map gets it information from a single-bitmap. I wanted to change this limitation but I did it in a slightly different way than expected that gives you a whole bunch of other possibilities.
T2D now lets you link image-maps together, irrelevant of what images they use, how many frames they have, the sizes of the frames or what mode they use for acquisition. You can link as many image-maps together as you want and use it for animations, sprites ... whatever. If you've got a whole bunch of images that define your 'player' you can define a set of image-maps that are linked together as a single name and use that for whatever you want. The great thing is that you can use many different methods to acquire these frames but still use them seemlessly as one. On-top of this, T2D will also deal with all the other options such as the 'padding' described above.
One of the most-used image-map modes was "CELL" mode. In this mode, you define a regular array of cells (frames) and T2D goes away and uses these. Because this is the bread-and-butter image-map mode, it's been extended to a point where it's bursting! You can leave it in its default state and it'll work as before but you can specify all sorts of other things. For example, you can define the scan directions independantly horizontally and vertically, the cell stride so frames can have spacings between them, the start-point for acquiring cells and much more. For instance, there's no way you could extract the four frames from the following image in the previous release...
... without grabbing the famous character hidden behind the tiles. You now can! You could also grab those frames from different directions and even get T2D to automatically worry about how many tiles to expect in either direction.
Okay, you've seen me talk about 'acquiring' frames from images above but what the hell am I talking about here? Well, take the previous image with 'homer' in the background. If you used this in the previous release, the whole image would've gone to the graphics card even though you were only interested in the four frames. Worse, if the image wasn't a POT in size then T2D would be forced to resize it to the next POT in size and upload that! As the sizes get bigger, the next POT can be huge resulting in a massive waste of video-memory. No fear, if you used this in T2D now, you'd get this...
... minimal use, minimal waste. This is the new image-map packing system working. When you get your sticky hands on the new release you'll be able to browse the code yourself but for now, I'll just say that I'm pretty god damn happy with it. The system first looks at your graphics-card to determine the constraints in which it has to work. It then uses this information when you create an image-map. It takes your frames and uses a special tree-algorithm similar to that used when packing lightmaps and packs your frames into a texture that most suits your graphics-card. T2D will also split-up the frames across textures if they absolutely will not fit into a single supported texture on the current graphics-card.
On top of this, it takes parameters (that you can configure) such as whether you prefer performance or least wasted-space. Ultimately, a single frame cannot be larger than the maximum supported by the graphics-card that T2D is running against and so this brings up another feature that I've developed, image-map runtime information.
The new system hasn't just added a bunch of features with no regards to how the system reacts when something goes wrong either trivially or seriously. The new system has a huge array of functions available to both scripts and C++ that allow you to interrogate and control image-maps. You can control the more obvious things like filtering-modes but also fetch frame-counts/sizes, texture-pages, frame-counts in specific texture-pages and much, much more.
Some great features are the image-map callbacks. There's a handful of callbacks that'll interest people who want to both manage image-maps in detail but more importantly want the ability to manage situations where an image-map is not supported by the current hardware and possibly switch to another one or specify other parameters. T2D provides callbacks when packing begins/ends for each image-map as well as an error-callback if something goes wrong. The error callback is very informative and provides a plain-english string for the error as well as a fixed error number that you can programatically use to recover somehow. A basic use for the packing callbacks would be to show a progress bar if you were uploading alot of images.
A new feature in T2D are the system variables. These are preferences that make system-wide changes to the way T2D works. In this context, there are half-a-dozen for image-maps alone. These control things such as telling T2D to dump complete statistics for each and every image-map that is processed (all source to destination frame sizes, texture-page counts etc), echoing errors to the console, overriding the maximum texture size (as reported by the graphics card), dumping all the resultant packed images (before they go to the graphics-card) to disk and much more.
Enough about image-maps I hear you say!! Okay, what shall I show you now? Hmm ... I know, the particle-engine.
One of the things asked for in the forums was the ability to use the hardware blending-modes in the particle-engine and this is what I've done. The possibilities this produces are fairly endless. Now, when you're editting a particle-emitter (within a particle-effect), it can have it's own source/destination blend modes just as all the other objects can. You don't set this at the effect-level but at the emitter-level meaning that a particle-effect can comprise of many emitters, each with its own hardware blending just like tile-maps/layers can. This can lead to very cool effects, none of which I've had time to produce. ;)
Here's a simple image showing the option in the particle-editor and a movie showing it working...
Per-Emitter Hardware Blending Movie
Another feature that was asked for was the ability to simply specify a target position/rotation and automatically get the object to move to that location/rotation. This I've done for you but as you should expect by now, I've try to go a little further for you. You can now go to an object and do something like this...
%obj.moveTo( %pos, %speed, ...... );...or...
%obj.rotateTo( %pos, ....... );
... and this will do exactly what has been asked for. What it won't do is rigidly move to that point! What I mean by this is that I never want to put in a feature that temporarily bypasses all the other systems that apply to an object. When you do this, if the object responds to collisions, it will react and possibly not get to the point. How does T2D know it was interrupted? It doesn't! What's going on here is split up into two levels. The first level are a couple of new options for all objects; these are setting a target position/rotation. You do this using something like...
%obj.setTargetPosition( %pos );...or...
%obj.setTargetRotation( %pos );
These commands (plus their many options) allow you to specify a location/rotation at which point a set of things can optionally happen such as stopping the object from moving and/or actioning a callback. This means that you can tell T2D to inform you when a specific position/rotation is reached and/or automatically stop. What has this to do with the "moveTo"/"rotateTo"? Well, these commands are really a hybrid of the target-commands shown. When you use them, they automatically set the target position/rotation you specify and calculate the required velocities to move to the position/rotation. The great thing here is that you can use the features seperately for all kinds of things. All these commands have a "fuzzy" option that allows you to specify a region that counts as hitting the target so you don't have to be exactly at the specified position/rotation.
Here's a very basic image of me pointing to a location and simply issuing a "moveTo" command on a particle-effect. The thing to remember is that this is done with almost no code. As you can see, it simply moves to the location that I specify, not exciting but I had to show you something right? ...
Move-To Movie
Okay, it's getting very late here and I've been working on T2D all day so I'm going to talk about one more feature. The one I've chosen should have an appeal to almost anyone on these forums but especially to the existing T2D owners who have either asked for it or have spoken about games that would need it ... it's the ability to used standard TGE DTS objects fully-featured in T2D. By this, I don't mean get a static DTS and just render it on the screen over/under T2D objects, I mean, render inside layers, move around using all the standard physics/collisions, blending, sizing, positioning etc. By fully-featured I'm referring to compatibility with DTS features. Here I've tried to get everything in that I can!
Before I say anymore, here's T2D with a whole bunch of Strategem#1 and Strategem#2 DTS objects up and running. Here's a list of things that I've added support for when using the new t2dShape3D object...
- Load arbitrary shape files (*.dts)
- Load/Associate animation files (*.dsq)
- Play by animation name or sequence number e.g. "move", "idle", "fight" etc
- Animation time-scale
- Smooth-blended animation transitions
- Override object render scale
- Override object render center (offset)
- Multiple skin/skin-set support
- 3D Quaternion rotation
- 3D Quaternion angular velocity
- Full Animation Trigger support (custom callback per trigger)
- Full Detail level (plus intra detail level) support
The use of these shapes is totally seamless with what you've used before. The great thing is that they fully integrate with everything else so physics, camera, blending, moving, mounting is all done using the core functions. As an example, here's a bunch of movies showing me selecting 3D shapes with the mouse, zooming-in on them, moving them around, mounting them to each other etc...
t2dShape3D Move #1
t2dShape3D Move #2
t2dShape3D Move #3
Phew! It's nearly midnight here and I've been working since 5.30am so that's like, err, lots of hours so I need some sleep. I'd just like to say that I'm sorry that I hadn't done a plan earlier but sometimes it's easier to sit and work on T2D than to put out a plan. Both are working for T2D owners but I guess one is more visible than the other. We've promised to put out an early beta version of T2D but it is unlikely that this'll include everything, certainly not the TGE v1.4 merge but at least everything I've mentioned in this plan.
All in all, lots of hard work has got us to this point. We've had to make hard decisions on what goes in and what doesn't. With the best will in the world, you can't do everything so not everyone will be happy but we're hoping that we've covered 95% of what we feel is needed to allow people to put out a solid product using T2D.
The great news is that when this is shipped, we've got a whole bunch of further development on the books and to say that work will be exciting is an understatement!! All you have to do is take this release, make a whole bunch of games and get them distributed. In the meantime, we'll be making your investment worth even more to you.
- Melv.
T2D Dev
About the author
#42
01/31/2006 (2:53 pm)
Melv - It's amazing what you have done with T2D. The technology is insane! I spend the weekend creating a simple game and I have to applaud you for what you have brought into existence! It is easy and fun to with it! Keep it coming!
#43
It's cool that you're enjoying it. I'm kinda' jealous; I wish I had time to create a game with it myself. Maybe I'll spend this weekend doing so. :)
*evil capitalist mode on*
We're always looking for people to post on the reviews section of the T2D product page! *hint hint*
*evil capitalist mode off*
- Melv.
02/01/2006 (12:26 am)
Hey, thanks! This has definately been a group effort though; the GG team and associates have done some great work with it as well. T2D definately wouldn't be what it is without the guidance of GG. :)It's cool that you're enjoying it. I'm kinda' jealous; I wish I had time to create a game with it myself. Maybe I'll spend this weekend doing so. :)
*evil capitalist mode on*
We're always looking for people to post on the reviews section of the T2D product page! *hint hint*
*evil capitalist mode off*
- Melv.
Torque Owner Jason Swearingen