Long time no blog...

#1 For those who don't know me, I'm the lead developer for TGB and would love to hear your comments on my blog.

Sorry for the noise but now's the time to have your say! :)

#2 Who? ;)

Every Torque user is recommended to view the blog. Every TGB user SHOULD read the blog!

#3 I guess I deserved that. ;)

Melv.

#4 You've read this before Melv, but I'll try to kick start things here:

What I would like to see from the next major TGB release is the user having more control over project management, both in editor and run-time. There are things that have been left out of the current editor (like sound datablock management) that users should be able to control in the editor itself. I think it should start with a comprehensive asset library and asset management system. We can start with the basics:

- An asset library structure (folders or groups)
- The ability to filter, search or sort assets
- Don't display each sprite/animation, have the list of assets and a preview window (or give the user a choice)

These are just a few very small additions that can make managing a project much easier, especially when you start importing dozens, if not hundreds of art assets into the editor.

I would also like to see the user be able to choose when assets are loaded/unloaded during runtime. Not all scenes require each asset so loading/unloading resources during runtime could be pretty important for larger games. One way of doing something like this is having multiple managed sets.

I have recently explored TGE and TGEA and have been withdrawn from further exploration within because of the learning curve. Mainly the vast differences between editors. I know that there is a huge difference between the requirements of a 2d and a 3d engine, but I think that if there were a greater level of similarity between the editors and their usage, the learning curve would be reduced. This relates to Torque as a whole, not just TGB, but I think that further development of Torque's tools should have the view that we can make them as similar as possible, at least in terms of interface and scene/project management.

Maybe we can steal ideas.

#5 Bah, long overdue my foot...some of us are working on 2 years without a .plan ;)

#6 Well, I didn't want to say anything Pat... ;)

Melv.

#7 Phillip has a tremendous point with those suggestions. I think his suggestions are the most fundamental things missing from TGB currently. I think having sound datablock management is slightly more important than the asset tree idea, but that's probably because I try to really limit the art assets that go into a game.

Another aspect missing from TGB is sound options. Currently we can play a sound and stop a sound. Some really basic functions would be nice like pausing, minor pitch changes and audio playback that doesn't pop when you start to play a sound. There's a real issue with sound bytes popping or not being loud enough in TGB.

$0.02

#8 Much of what you propose there Kevin is available in TGEA's new sound library. I cannot say for certain, but I recon that this will make its way into TGB in the future.

#9 Well, if and when TGB gets the SFX sound layer - it will certainly be a much welcomed improvement. But with TGB that is often times only half of the puzzle. Having the ability to place editable "sound objects" (similar to what the NWN toolkit offered, as an example) into a scene through the editor is also needed in my opinion.

#10 Phillip,

That's good to know my friend!

Mike,

Yeah, that'd be perfect for ambient sound effects! I fell in love with modding NWN.

That wouldn't work for sound effects based on a player action or NPC action though.

#11 TGB wishlist...

Adopt Box2D for physics / collision detection / response.
Specifically, this would add cool stuff like: multiple collision shapes per "body" and joints / springs. Including breakable joints and motor joints.



Ability to write to either the current users appdata folder OR the all-users appdata folder.

#12 Didn't you attempt to integrate Box2D with TGB, James? I did too, but my efforts were so fruitless that they could hardly be called an attempt.

It would be undoubtedly cool to have the capabilities of Box2D in TGB, and if anyone stood a chance of successfully integrating them, it'd be the people who made TGB; still, I must wonder if the task is too hard even for them. I know Melv said that the job would be really tough for a really experienced programmer.

That'd be an update I'd gladly pay for! ;)

#13 The real problem here isn't the physical endeavour of doing it or simply the complexity. The real problem is that TGB already has what's called a broad-phase container which is used to accelerate picking and collision detection.

Box2D has its own broad-phase. The problem here is that you can't get Box2D to use TGBs broad-phase and you can't get TGB using Box2Ds broad-phase (without loosing picking). To do this you'd have to use Box2Ds and then extend Box2D to provide the sophisticated picking routines that TGB provides (which Box2D doesn't).

Box2D doesn't provide off-the-shelf a method to seperate the two, at least not as far as I've seen. If anybody knows how to do that easily then please send me an email. I know I could drill under the hood and make the changes but there's no clear seperation without doing that and we certainly don't want to do double-book keeping where objects are in the TGB container as well as the Box2D container.

Another "issue" is that Box2D uses a strict MKS (metres, kilograms, seconds) setup. You must set the properties of your objects to be these units. If you create objects of excessive size or mass then you get terrible results ... try it. This is a discipline that a TGB/Box2D user would have to master. Lots and lots of people who purchase TGB don't understand these issues and would experience real problems unless they were carefully guided.

You must not forget as well that Box2D only does rigid-body and less than 50 lines of code in TGB is dedicated to that task. People often say why can't we stack rigid-bodies. Well to do that you need more than 50 lines of code. TGB only has a basic rigid-body response and doesn't try to provide all the myriad of functionality to support that.

On top of this, TGB doesn't just support rigid-body, it supports lots of different types of responses which although you can constrain or configure Box2D to do, it'd be less than optimal.

With that said, I have looked at Box2D and Chipmunk, both of which are very nice.

It's not that difficult to setup and I'd estimate about two weeks solid work but it'd involved quite drastic changes to the API to unify everything down to a rigid-body interface. Adding in the extra support into Box2D such as picking and stuff like "castCollision" would take extra time. This would of course break the editor so that'd take much more time than the code changes for the physics.

As soon as you start thinking about this you want to modify the way certain other features in TGB work. For instance, the "mount" function would need to be ripped out and replaced by constaints or joints which would take more time and lots of API changes. Anything else that just modifies the position of objects would need to be carefull modified to work with the new physics.

We're talking about a major rewrite of lots of the API covering a couple of months. Doing this you might as well rewrite to be componentized throughout and the time goes up.

I guess if you wanted to integrate Box2D and have isolated rigid-bodies that didn't interact with anything other than other rigid-bodies but could be rendered within a standard scene, that's really, really simple. It's when they need to interact with non Box2D-based objects that the cascade of development inevitably happens.

Melv.

#14 Melv,
I am also interested in Box2D - I've (slowly) implementing it on my own time, butas you mention, the real problems are the interactions between box2d/non-box2d objects.

However, I am not really interested in the rigid bodies or collision response of Box2D. My primary interest is adding links and constraints so that I can make a dynamic rope system and 2D rag doll.

#15 Well you don't have to go to Box2D to do that.

You could easily create a class of object thats job is to bind other objects or simply add it to the t2dSceneObject.

You could work out what you need to do by following how the rigid mounting works.

A slightly hacky but easier way would be to modify the existing mounting by adding an extra parameter. In this way you could add your own code directly in the mounting code called each iteration.

Try for something simple at first which is a fixed distance constraint or something.

Melv.

#16 Melv,
Given my lackluster C++ skills, I thought it would easier to integrate box2d than creating a new derived class and replicated the same functionality found in Box2D :) But I'm certainly willing to try what you suggest.

#17 @Melv

Those are all the same issues I noticed while working on box2d integration the last week.

I went the easier route of giving all t2dsceneobjects a box2d object representation that is completely separate without any changes to t2dsceneobject. But I did modify the scenegraph to set the t2dsceneobject position to that of the box2d object each integration. As you mention, this means objects are in both container systems, which is not efficient.

The main reason I stopped work on it, however, is I realized it wouldn't be very usable without any editor support for box2d objects. Probably the proper way to integrate box2d is to make simObject derived classes for all the box2d classes and then they could be saved/loaded in the level like everything else. Alternatively some classes could be encapsulated by others, like t2dSceneWindow encapsulating the camera in t2d.

"Rip out the mounting system and use box2d joints, rip out the broad-phase and use box2d."

That would be the work required, but in the end you would have something better, and something being actively developed by a whole other community.

@Patrick

I second Melv's reccomendation. It sounds easier (to me) to implement a rope class than to integrate box2d. You can always look at the box2d code for inspiration, its free!

#18 @Melv - I would deal with Box2D like i deal with PhysX: i create the rendering object in Torque, i create the physics representation in PhysX, each tick i update the rendering object to the position of the PhysX state.

This could let you maintain the existing TGB physics support side by side with Box2D.

I would avoid having physics between TGB and Box2D interact, but you could make static (or kinematic) collision shapes placed in the TGB scene also appear in the Box2D scene.

#19 Tom,

I'm not implementing this, I'm just offering suggestions. ;)

I totally agree though and there are a number of ways of doing this and it all comes down to what folks want. Grabbing Box2D and having TGB render the objects is a real easy approach if you can live with only that class of objects being able to interact. This is particularly easy if it's just for show although rigid-body is an expensive scene decorator.

Replacing the TGB physics engine with another takes more work. ;)

Melv.

#20 Melv,

Just read your blog post. Quite the story! I had no idea T2D -> TGB was written by someone who was not a Garage Games employee. And I never would have been interested in Garage Games had a 2D engine not existed.

What would I like to see in the future? Most of it would be things not related to your own work:

- Mac support for joysticks
- Mac support for modifier key detection

But there are also TGB things, such as:
- Camera rotation (of the entire view)

But to be honest, the main thing I'm interested in is improvement in the ability to produce a commercial-quality game that runs well even on older computers (say, as low as 1.0 GHz... that's not too old). Currently, throwing a couple hundred or so sprites into a scene, with various script callbacks and timers for various things, makes the game lurch on somewhat older computers at times when those script callbacks get called more often than not. I'm sure there is room for some optimization here, I'm just not sure where.

For example, I just discovered that my onCollision() callback gets called any time my enemies overlap. I have a lot of enemies overlapping. But, I *only* need to check for collisions between my enemies and the player's bullets, NOT enemies with enemy bullets, and not enemies with other enemies. Yet, my script callback is called for everything that overlaps, and the check for what class the srcObj and dstObj is is done within script. It'd probably be a bit more efficient to specify up-front, via some console function, which classes I want to check for collisions between. And my callback is only called when those classes get checked.

This would probably provide only a minor speed improvement, but the point is, there are probably many things like this that could be done that would add up. Currently, I don't think there's any way I could write a bullet shooter in Torque that runs on anything but the very latest computers (1.8 GHz or faster), simply due to the sheer number of sprites in the thing. So the types of games I can write is limited by Torque's performance.

Optimizing TGB is the #1 thing on my list. It really has all the other features I need. Struggling to get my current game, with only 100-200 sprites on the screen at once, to perform well on 1.0 to 1.5 GHz computers has been enough of a struggle that I'm seriously wondering if I want to continue to use TGB for future projects, despite everything else that I love about it.

And to clarify: it's not that the overall frame rate is bad. It's that there are frequent "jumps" in the animation where something happens internally that causes the game to skip a few frames at that moment, at least on older computers that can't handle everything the engine is trying to do that that time. This lurching makes the game rather unenjoyable and seem unprofessional.

Melv, it's great to hear you're getting more actively involved again!!! I look forward to seeing more being done on TGB!!!