Plan for Melv May

Well it's been quite a while since the last T2D update and seemingly nothing is happening behind the scenes but the reality is quite different! Our original plan of action still stands but, not suprisingly, we've been sidetracked by the need to fix reported bugs and make improvements to areas that were considered only placeholders. Lots of this has been driven by community feedback in one form or another and very valuable this has been. This has obviously slowed things down and the timetable of work has had to change to accomodate this. I've also had a tough time of late what with being busy at work and some pretty bad back problems and just general fatigue but through all this, I've been proud to be developing T2D as it is starting to really take shape!

So what exactly have we been doing then? Well, there have been a number of areas we've focused on but a large chunk of work has been fixing-up bugs and making improvements such as clearer documentation which just seems to eat-up time!

One of the more noticable changes to T2D users will be the change of nomenclature for objects. When I developed the original T2D, I used my "fx" prefix but this doesn't really suit a GG branded product and to be honest, T2D isn't really an "fx"! Unfortunately, we didn't have the time to do this earlier but it was always a high priority and we absolutely wanted to get this change out the way early. So previously we were using fxWoot2D but this has now changed to t2dWoot so we've got a prefix of "t2d" only for all objects. Sounds like a simple change but this involves changing of the existing documentation, tutorials, demo-code etc.

Alongside this change was another that we desperately wanted to get out the way. This was to implement a more flexible method to load/save objects e.g. object-serialisation. We looked at various strategies for this considering script-user usage as well as extendability for C++ developers and finally came up with a method to deal with this. The end result of this work was such that any object can load/save its state to/from disk. You can also setup a set of objects and get them to save. As previously, you can also load/save a whole scene-full of objects to/from disk. Another goal of this new system was to allow each object to load/save itself via an arbitrary stream meaning that object state can be transfered in-memory (or potentially via the network). This gives rise to some new features which are the ability for one object to copy its state into another object with "obj1.copy(obj2)". This can be very handy but there's a little more which is the ability to clone an object with "obj2 = obj1.clone()", the difference being that a new object is created with clone and therefore the scripts don't necessarily need to know what the object class is.

Another small improvement but handy enough to mention here is the ability for any T2D object to start its own periodic timer using "setTimerOn(time)". This will produce a script callback to "object::onTimer(%this)" in the specified period. When you're finished you can just turn it off. This can be very handy in many situtations.

In my previous plan I mentioned the huge chunk of work on the collision detection/response framework but at that point, I had only worked on the response side of things. To recap slightly, each object can select from a set of stock collision responses. These are Bounce, Rigid-Body, Clamp, Sticky and Kill. Here's a set of images detailing these modes...

Bounce Mode

Rigid Body Mode

Clamp Mode

Sticky Mode

Kill Mode

Lots of Object Collision Modes

Movies...

Bounce Mode Movie

Rigid-Body Mode Movie

Clamp Mode Movie

Sticky Mode Movie

KillMode Movie

Lots of Object Collision Modes Movie

These modes not only make things much easier as they cover lots of standard case responses needed in games but they obviously perform much better than doing this stuff in scripts. All this done using "setCollisionResponse( bounce );"! Another benefit is that the framework allows for extending the collision responses in a number of ways, something which I'll go into more detail below.

With that work finished, I moved onto the more complex collision detection side of things. The existing system used a two-stage (broad/narrow) phase detection method. The broad-phase used a container bin system which allocated objects into configurable-sized bins within the world. This gave a very fast method for counting/discounting objects from subsequent, more detailed detection. The narrow phase we had used a swept-polygon detection which was very fast. This allowed objects to defined convex polygons as their collision boundary which were swept through the world meaning that no matter how fast the objects were moving, they wouldn't step through another object. Now with a handful of bugs aside, this worked extremely well.

Now being as T2D is trying to be a 2D game engine for lots of different types of games, we needed to make a few improvements in a few areas. The first was to allow the collision boundary to be defined not as a polygon but as a circle/ellipse. This would make the collision boundary much easier to define which can be very important when you're not interested in exact polygon detection. In-fact, if you wanted to define a circle/ellipse using a polygon, you had to ramp-up the polygon edge count quite high to get decent collision normals. These extra edges can degrade performance if used on hundreds of objects. Of course, we didn't want simple instantaneous detection, we had to make it a swept detection for the reason outlined above.

Something that we've tried to do with T2D is to not presume how people will use it but still try to put reasonable constraints in there. I'd hope that we can be accused of providing too much functionality, not too little. With this in mind, we decided to extend the idea of how to select the collision detection system therefore we decided not to restrict the detection method to simply swept ellipse or swept polygon but to provide a selectable tiered approach. The end result is that you can configure the collision detection for an object with different modes; these are... FULL, POLYONLY and ELLIPSEONLY. Poly/Ellipse only are obvious and tell the object to only use the selected method but FULL will tell the system to use ellipse first then, if sucessful, use the more accurate poly-detection. Now because the swept-ellipse is much, much faster than swept-polygon, you can use the swept-ellipse as a mid-phase detection method to potentially speed-up your detection in games where lots of collision are happening. As before you can scale both the polygon and ellipse detection areas in realtime with little/no performance hit. An additional option for the ellipse detection is to select from either a subscribed or superscribed ellipse e.g. covering the interior or exterior of the axially-aligned bounding-box, again, switchable in realtime. All this from "obj.setCollisionDetection( full );"!

This new detection method can be seen here (the movie shows the switching between super/subscribed ellipses)...

Swept-Ellipse Detection

Ellipse Detection Movie

The final thing I'll add about the new collision framework is the ability for the C++ developer to extend T2Ds collision detection/response system. As a developer you may want to interrupt/override the collision detection process at different points, possibly do your own broad-phase or use the broad-phase and develop your own swept detection method, perhaps add a method that extends the FULL mode so that you get swept-ellipse, swept-poly then swept per-pixel (*ahem*). More realistically, you may want to override the swept-polygon to implement concave support. All this you can do. On the response side, there is a CUSTOM mode which turns off the stock response and calls the custom method which a C++ developer can implement. This means that you can, without changes, refer to this mode as custom or even extend the list so that you have a script-named response.

Another feature that now works perfectly and will undoutably be used for some very cool things in the future is active-tiles. I posted a little information about these a while ago but I thought I'd repeat it a little here. Active-tiles allow the C++ developer to quickly and easily implement a new class based-upon the active-tile class. This allows tiles within a tile-layer to do almost anything from tracking other objects like a gun-turret or even bizarre rendering effects that are not limited to the tile area itself. Being as I posted about this before, I won't go into more detail but here are the simple movies illustrating a test active tile that tracks the mouse-cursor. Note that the active-tile does this autonomously without any need for script-interaction. Anyway, here are the movies...

Active Tiles

Active Tile Movie #1

Active Tile Movie #2


Well, onto some seemingly minor things but important non-the-less. There are lots of features that have been folded into TGE v1.4 which are extremely handy. Not soon enough for us, we'll merge with that codebase and the simply staggering amount of improvements will get folded into T2D but in the meantime, it seemed silly to deny T2D users at least some of these benefits. TGE users will already know about these but T2D owners won't. None of the following changes are down to me but have come from the guys @ GG such as Ben Garney, Justin'Dujardin and others. You can see some of the T2D specific work Justin has been involved in Here and Here.

One of the improvements was to the drop-down console. Previously, when you had a script-error, you wouldnt' know until either your code didn't work as expected or you searched through the console for a red warning.

One of the improvements here was to add a small drop-down window and status bar to the console which when dropped-down, immediately shows the number of warnings as well as a list of script line numbers where the problem occurs. This removes the need to scroll through the console searching for a potential error. Another issue was that the console was of fixed size which was a pain if you were running at higher resolutions and needed to see more information. The console can now be dragged to different sizes as required. All this is demonstrated here...

Console Warning/Grouping

Console Warning/Resize Movie


Well, I could extend this plan to many more pages with improvements in functional areas but I thought I'd finish this plan by detailing some of the documentation improvements made. TDN will address some of the main concerns of T2D users but we're trying to improve the shipped T2D SDK doco as well. We decided to stick to the PDF format for the documentation as it's the most widely accepted format. Some minor problems with the previous PDF doco was caused by using the OpenOffice (beta#2) PDF exporter. With the documentation reformat, a improvement was called for here and I decided to purchase pdfFactory pro which is a great product. One of the bigegst documents in the SDK is the reference documentation. I spent a huge amount of time reformatting this document to take into account the nomenclature changes but more importantly, the grouping of functions into logical groups by colour-coding them into blocks within tables like so...

note that I've obscurred these images so that I don't break the EULA myself!!

Functional Grouping

Another improvement was to index this very large document by object and then by function. pdfFactory Pro allows you to do this and so you get the standard bookmarks in your pdf viewer like so...

PDF Object/Function Index

An additional document that I created was one that details the particle-engine. Something that we didn't want to do was to detail either the particle/tile editors as these are subject to serious change in the future. Because the functions of the particle-engine are simply duplicated in the editor, understanding the particle-engine makes the editor almost obvious. Obviously I can't post the document here but here's one of the images from the document showing the kind of detail within it...

Particle-Engine Graph

Still on the documentation front, I recently submitted some config files for dOxygen that allow you to download dOxygen, load-up the config file and produce a complete engine document including image-graphs using GraphViz. I also took a handy resource and created a config that will also output a single windows CHM file for the whole codebase, obviously windows only. Very handy indeed!

Another improvement has been to the god-damn awful load/save dialogs in the engine. I believe that Justin has posted some of this stuff in one of his plans but I'd like to at least show it working within T2D so here it is...

New T2D Load/Save Dialogs

On a side-note to these dialogs, you should note that you can now load/save stuff from anywhere within your project. This makes using the particle/tile editors much more intuitive. Another background improvement which impacts this is the fact that T2D now loads/saves everything via the resource-manager meaning that as soon as you save an object, it's available for subsequent loading without either a restart or a hacky "setModPath()" call.

Well, what am I doing right this minute?

Well, I can tell you. I'm working on a considerable improvement to the way T2D handles imagemaps. For those who don't know, imagemaps are the core-object that provide an interface between your images on disk and textures that T2D objects need. It is the primary route to get hold of image data and it provides a mechanism to acquire frames from bitmap data. You can split-up a single bitmap into many frames either using a regular grid, a colour-keyed image or simply using the whole bitmap as a single frame. One of the issues here is that 3D accellerators (at least of old) like nice power-of-two sized bitmaps. T2D will automatically pad textures to comply with this requirement and issue a warning telling of the wasted texture memory. What we've set about to do is address this and many more issues by providing a system which can be set to automatically decided on the most efficient method to acquire these frames, even under circumstances where the bitmap exceeds the capbilities of the underlying hardware. Alongside this we want to provide a mechanism which allows power-users to fine-tune how this works. I'm not going to go into much more detail here as it'll get too boring too quickly, especially as I've not got any nice images to wake you up with. ;)

Well, I'm going to have to end this plan somewhere and now's a good a time as any. You can be assured that alongside the changes detailed above, are many, many others which should make development much easier. We've fixed a huge array of bugs as well, some of these relate to the underlying TGE and they have been submitted to the TGE v1.4 codebase.

All in all, lots of work and we're still going at it. Many other areas to improve such as animation, performance, new objects, memory etc. I'm sorry for the lack of information of late but as was posted recently on the T2D private forums, we'll address that ASAP.

All the best everyone and great T2D'ing!

- Melv.