What would you like to see addressed in Torque 2D?

#181 So, your spritesheets were each 12800x12800 and you were loading around 200 of them at what bitdepth? That is something that would brick most high-end machines and any engine I've used out of the box. You would need a very structured load/unload system to ensure that you were never pushing way too much to the GPU or memory at any given time.

To do this in any editor would require asset loading/unloading on a discrete scale. Basically, it would only load a preview image and then only load the animation while you were actively in the view. So you could not scan several animations at once quickly, but it would be more performant for what you were trying to accomplish.

Adobe has some nice caching that you can see in effect if you open a lot of PSD's and do a lot of work in the top-level PSD's and then switch to one of the older ones you haven't touched for a while. There's some noticable slow-down while it caches in and out data for use. Most programs that deal with extremely large datasets need to work in a similar fashion. GIS datasets deal with a ton of data and need to have an effective cache and scansion system in-place to deal with it realistically. It is an interesting problem to tackle.

#182 Implementing some physics engine like Box2D within TGB's environment would be a huge improvement. Many people ends adding it to their games, and having some tools as powerful as those under TGB would be just perfect, and save many hours of additional programming.

#183 1) I would really like to see the ability to mount objects together with a mount point from each object. For instance, I might have a mount point on the hitch of a trailer and a mount point on the back-end of a truck.

2) The ability to change the center-of-gravity (or pivot point, if you prefer) of a scene object

3) The ability to use concave polygons that get split into triangles

4) An improved polygon editor where you can mirror geometry to the opposite of each quadrant and manually set indices

EDIT:

5) The ability to rotate Shape3D objects like you can regular 2D objects (rotating the shape itself yields strange results)

6) A function like setImpulseAngularVelocity() or such would be great. I don't know why it's not there, as it's a pretty common thing.

#184 It would be great if T2D supported fading and playlists for .ogg music files.

I haven't attempted to integrate the VMPlayer resource into the latest version of T2D but it seems to have many features that should be standard out-of-the-box:

http://www.garagegames.com/community/resource/view/9560/

The only official documentation for audio appears to be here:

http://docs.garagegames.com/tgb/official/content/documentation/Tutorials/Feature/Audio%20Tutorial.html

This is somewhat ... skimpy.

#185 The platformer kit has a music system. You can do some crossfading with clever use of scheduling and whatnot. But it would be nice to have examples of fancier things like these out of the box.

#186 I would like to see the addition of console logs in Mac builds.

#187 @Laura
The Mac build has the same console log as the PC build. The outputted log file is console.log found in the root of the game directory alongside the game exe. If you meant opening the in-game console, the Mac shortcut is slightly different than PC. Either ctrl+~, fn+~ or command+~, can never remember which one.

#188 Can you give me a basic path to the console log?

#189 The next update of the Torque 3D will be paid. This also happens with the next update of Torque 2D too?

Read in this blog:
http://www.garagegames.com/community/blog/view/21294/1

#190 We are working on a quick release of Torque2D to make sure it is Lion compatible. It will not be paid, but it's more of a hotfix then a release.

#191 Support for browser based games would be nice. I don't want to buy Game Maker HTML just for that lol.

#192 As I tinker with the engine, I find myself really wishing for some more advanced animated sprite control.

As it is right now, I have to have each and every cell be a whole complete image, which also means I have a whole lot of whitespace around my characters. I have to get each frame lined up between each other in relation to where the character is seen in the frame.

The quick demo I have been working on has frames for the character falling over if he dies or gets knocked on his back. That means each and every frame has to be large enough to fit the character lying on his back, but not just laying down, but laying down with his feet still in the middle of the frame, which means extra blank space in front of the character.

It may not be much of a worry for extra memory for a few drones that only walk back and forth, but my main character could have dozens of special moves with unique animations. And a second player would double that load. I tried to save on memory costs by having three animation image maps with differing cell sizes, but the engine wound up stretching/compressing the frames to fit the same size of the original actor I put in the scene.

Now old-school 2D engines had a myriad of tricks to save on memory costs. For one thing, they would take all of the frames and chop them up into little 8x8 squares, and save data about how to reassemble them. This way blank squares didn't take up memory, and cells that repeated portions on an animation (i.e. the legs don't move when he punches) all reference back to one set of graphics.
Later games would save each frame of animation as a single whole image, allowing each individual image to be a different size. Each frame would also have a point of data to specify a single texel as the center of the frame, so when the frames were drawn they would all be lined up properly.

One thing that comes to my mind is that the first method I mentioned could lead to anti-aliasing issues where the blocks do not line up properly in their arranged format. The first solution I see to this problem is by adding some padding to the squares; for example the image could be divided into 14x14 squares but saved into the system as 16x16 squares that include the texels surrounding that square. (Tests would need to be performed to find the optimal size to use.)

Now you may be thinking "Those tricks won't save you any worth-while space on today's systems; the engine can use file formats that compresses data for repeating squares already!"
But you might do well to remember that Torque has to take all of these texture maps and recompile them into images that fit power-of-two squares. So a character animation sheet that is 1235x798 ultimately takes up the space of a 2048x2048 image. What a waste. But if the game engine itself could recompile the data into smaller squares it could cut out the wasted empty space and reduce the animation possibly to a 512 square. And certainly if the game combined several animation cells it could save even more room.

I would be fine with supplying the editor a sprite sheet with large oversized cells so long as the engine still reconfigures that material into a more efficient format for the game to use; there is no need to supply a special interface for building cell parts.

Another old-school trick I would want to execute would be how those sprites could be divided into separate sections that were layered together. For example, a character could have sprites for his torso, sprites for his head, sprites for his arm, etc. Thus animations where one part moves more than another don't repeat extra data. (Like, how much does the head move when he attacks?)
Additionally, this technique allows a couple other tricks. Parts can be animated to just move differently than the other parts, giving unique mechanical motions. (Used subtly, like moving a torso one or two pixels, it can create a natural breathing animation with no additional graphics. Used in more deliberately it can make a good robot. Used in the extreme, it could animate a creature made out of many smaller parts.)Another cool trick: parts can be replaced independently from the rest of the animation, so heads can be swapped out for enemies wearing the same outfit, or the hero can upgrade his armor piece by piece.

Theoretically, this could already be done through mounting actors to each other, but controlling them would be obscenely difficult without an integrated system. It also denies the developer the ease of manipulating a single object.

#193 The only remaining old-school advantage I find missing is to be able to change a sprite's palette. Granted, unless the sprite used an indexed color system (256 colors or less) it becomes tricky to have colors swapped out. But (1) for a single object 256 colors is in fact plenty (2) Even for true-color objects there are relatively few colors that need to be swapped out, and if these colors could be specified along with their replacements it would still require very little additional memory costs compared to adding an entire texture map. (If you need to change 320 shades of blue into 320 shades of green you'd only need an image file that was 320x2.)
Barring both of these options, it still ought to be relatively easy to perform an algorithmic change to the colors of a sprite. Perhaps adjusting the hue map or specifying ranges within the RGB channels along with how they would be altered. If these algorithmic operations were combined with a mask to show where the changes apply on the texture map, it still allows the ability to create dozens of almost-new sprites with only an additional 25% or 33% of memory costs.

Not to mention the development time it saves.

#194 Are there news about T2D development?

#195 We'll have more to share in about two or three months. Expect a roadmap to be shared as well. We are working towards a more transparent development model.

#196

Quote:
We'll have more to share in about two or three months. Expect a roadmap to be shared as well. We are working towards a more transparent development model.

Sounds great!

#197 This might involve a bit more than just T2D but...Android support. The market's growing fast. And with QWERTY smartphones or others like Xperia Play we could port our non-touch oriented games making more sense heh.

#198 Support for browser based games, and Android support as a bonus :)

T2D is fantastic, but with weird limits on platform targetting. I almost decided to go the Unity3D route (even for 2D games) just for the web browser deployment option. Since T3D has it already, I assume it wouldn't be a massively challenging thing for the developers to implement.

#199 Linux support

#200 I think that Steam support will be a good feature.