Long time no blog...

#41 A few more suggestions:

1) I don't know if this is even possible, but if it is: a deformable camera, or a camera with built-in special effects. So instead of warping an individual texture or doing special effects on it, you can do that for an entire scene, by selecting a special camera effect.

2) Camera rotation.

3) Better texture management. See this post:

http://www.garagegames.com/blogs/53436/12318

I'm not currently using certain sprites because they're too large, but they'd become quite manageable with this system in place, due to the huge amount of white space I have.

4) Torque could also combine sprites from separate imageMaps onto the same texture. Let's say you have a sprite whose frames take up 480 pixels of a 512x512 imageMap. Let's say you also have a sprite with fifteen 30x30 frames. This could easily fit in the unused space of the 512x512 imageMap.

Yes, there are difficulties to overcome here, such as: what should Torque do if it needs more space on the graphics card, and only the 30x30 sprite is used? Does it create a new texture just for that sprite, so it can get rid of the large one? Perhaps. Or another option is for a scene management system (as suggested much earlier in this thread) where the developer can specify what sprites he's going to use in a given scene, and Torque combines imageMaps from that scene with eachother onto the same imageMaps.

#42 Oh yeah, the link I posted above also mentions something about compressed textures on the GPU... I don't know anything about this, but if it *is* possible to compress textures further engine-side, I'd really like to see that as an added feature! If it degrades image quality, it could be an added checkbox, just like preload, filter pad, etc. are options for each imageMap. And you can decide on a per-image basis if it's compressed or not.

#43 Hi Melv, nice blog post. It is interesting to see the genesis of TGB, hoping for more from you in the future. FOr my part, I too have a few suggestions.

1.) The animation system. It's nice a simple at the moment, however, I'd like to see some basics such as dynamic speed alterations to animation streams and the ability to pause a stream.

2.) Changes to the animation builder. Celled images with a lot of frames need to be scaled up in the builder, allow the window to scroll or resizing of the window so we can more easily see individual frames of animation.

3.) Camera/world rotation. Been asked for a million times before.

4.) More information in the object tree, such as a hierarchical listing of objects, so we can easily see mounts. Or, perhaps a mode that shows all links via the builder window. Also, the ability to move objects in the object tree by default would be nice.

I think that's all I have for now. Keep up the good work guys.

#44 Simple points i could think of:

-CTRL+G to group objects on editor so we could move them all at once
-a treeview or something to organize the art better, its horrible now tbh :s

#45 @Shutt: I'd definitely agree with your second point. For TGB to further appeal to larger and more advanced games, one of the things it needs to provide is more advanced management of assets in the level builder. Allowing the user to hierarchical organise assets would be a good start. We have a pretty large number of animation streams, and the scrolling is becoming somewhat of a nuisance.

#46 Melv,

How about a tool to automatically generate navigation mesh from the level data (after we defined collision polylist and other relevant collision data) and manually fine tune it?

#47 Another suggestion: The ability to specify the copying of mounted objects when calling clone, cloneWithBehaviors etc. This would have been convenient a number of times.

#48 A real TorquScript array object. Eg. Expose Vector, Vector, and Vector. The push_back, pop_back, insert, find, and other methods would be very useful in many cases.

#49 Declare "callbacks" and global-script variables that are initialized in C++ (eg. ConsoleInit) in such a way that they will be listed by dump() for a similar ConsoleFunction. This would allow self-documenting C++ code and the possibility of Torsion collected and listing that information in addition to consoleFunction/methods.

#50 I've been thinking about this lately, and was looking into doing something with the code which seems to be way over my head :-), but it would be good to have an iterations scheduler I guess you would call it. Basicly what I mean by that is if I had a processing loop, I could "schedule" that loop to run through x amount of times per tick until the process has been done. I have mainly been thinking about this while playing around with the A* pathfinding and I'll use that as an example.

Basicly, when you have a significantly sized A* grid that you try and get a long path from point A to point B that whole game will "lock up" as it processes the path. Now looking at the code (and I could be wrong here) but the path is generally worked out by looping through each node to do the processing on. Now if you split this processing up so that you could call this loop say 10 times each tick until complete, the game could keep running while you do some background processing to find the path.

With something like path finding, it doesn't particularly matter if the path doesn't come up straight away if the player has clicked a long distance, but it does matter if the game looks like it has locked up while it is trying to process. Even better than doing it each iteration, I would imagine, would be a background process that would only process without slowing the game, although even thinking about doing something like that gives me a headache :-P

Does any of the above make sense or am I just talking nonsense again ?

#51 Camera rotation would be very nice to have.
Another cool thing every now and then would be to have texture-mapped deformable quads. Just 4 vertices that can be positioned anywhere with a texture mapped to them. Of course, that brings up the whole nonlinear distortion issue (where you can "see" the seam between the two triangles in the quad with the right texture and when the deformation is nonlinear). But hey, even full linear deformation would be nice to have (rotation, scale, and skew).

#52 Wow that is exactly the problem I'm having right now ( Texture mapping to a quad without a seam ).
www.gamedev.net/community/forums/topic.asp?topic_id=500595

If anyone knows how to do this correctly please drop a post or email jamesf42[at]gmail.

#53 Melv,
I know that Neo is working on isometric addon and I can't wait for it to come out.
In the meantime I started working on my own little fake 3d game using pre-rendered 3d objects on sprites. unfortunately, I can't do interactive lighting.
It may not be as high priority as other suggestions in this blog but I'd love to see these addition:
1. pixel shaders! this would allow us to do full blown pre-rendered 3d games with interactive lighting. just think of the possibilities... we could make the best detailed/shaded/interactively lit 3d games and nobody will even know it's 2d :) . we'll have the best looking particles system/ procedural fx and most flashy games. an EA producer wants told me that flashiest games sales the most. I believe him.
2. 3dShapes with perspective using a seperate camera space (so they can be moved around). This will help too, but not as cool as pixel shaders.
Thanks,
Eyal.

#54 Sorry I'm late to the party here. I don't mean to make this sound like a rant... hopefully my suggestions are helpful. Anyway, here's my TGB wish list.. followed by my Torque wish list as they are related and yet not specific to just TGB:

1. Better control over memory management or at least smarter memory management. This is specifically as it relates to image maps, but it also applies to sounds and such as well. I've not been following this religiously but better support for compressed textures was something that was missing for some time too (or at least I never figured out how to do it). It seems silly NOT to do it. Automating memory management could probably be done using some sort of "dependency" framework so that an image could be tied to any variable that would then automatically trigger the load or unload of the image.

2. Effective NAT punch through. Not to get into the realtime versus turned based or whatever argument. I'm okay with what's in there as far as what kind of games you can make using it... but it's almost deceitful when saying that you can make a game using the turned based networking, but no one ever says "oh, and by the way, since 99% of your users are going to be behind NAT based firewalls you won't be able to have your users connect to each other unless they manually open up the firewall ports necessary to allow hosting the game". It's a shame as the networking that's in there is good enough for many game types, but the fact that you don't have built in NAT punch through makes it completely useless for commercial game development (GG knows this because they put the nat punch through into the billiards game but as far as I can tell it's never been included in any TGB release).

3. Asset management - as Phillip mentioned - would be huge. As I think I understood him, the "library" of assets shouldn't be defined in a level and instead should be defined for the project and then just "related" to the level. A number of objects should really fall into this "library" as they wouldn't need to be level specific (particle effects and animations, I'm looking at you). This could also be tied into the better memory management side of things. And then as far as UI is concerned, having them be searchable/filterable instead of all displaying at once in the side bar/toolbar would be huge.

4. Shaders. Shaders. Shaders.

5. ISO - Neo was doing some really cool stuff. GG should back it up officially or just do it themselves, even if it requires a separate purchase... but leaving such a big gaping hole for so many people seems like a mistake.

Torque wish list:

1. UI overhaul and improved documentation of UI controls. I think this is already being discussed in the grander "torque 2" vision, but building anything more complicated than a splash screen or simple options dialog is just tedious and often times pretty ugly. Again, see how the billiards game eschewed the UI system in favor of just making the splash screen a "level".

2. My one and only "never going to happen" item on this list, but I feel like I have to mention it - I want torquescript to get a serious upgrade. Writing console methods in c++ and then calling them from script is functional (for those with source), but it's basically saying "yes we know our script is only good for little things and we're okay with that". I'm NOT okay with that. :) Ideally torquescript would "compile" to IL (.net/mono). You'd get a huge performance improvement and access to the entire .net/mono suite of languages, tools, libraries, etc. You'll never get rid of torquescript entirely obviously, but compiling to IL and embedding mono would really improve the development story for all Torque products.

Thanks Melv. I've always been appreciative of the work that you and the other GG'ers have put into TGB and I've advocated it highly every chance I've got. I really do hope some of these issues are addressed so that TGB can go to the next level.
-Andrew

#55 Those are really great suggestions, Andrew.

If I may add one more myself: eliminate the distinction between static and animated sprites. It's been a source of constant frustration to me that I have this "Enemy" superclass from which my enemy sprites inherit, so they can all share common functions. But the frustration is that once I've created a t2dAnimatedSprite that inherits from Enemy, I then get "can't unlink" errors when I try to create t2dStaticSprites that also inherit from enemy. There is no good reason why I can't do this.

More frustrating is that while I can get around this problem by simply creating an animation of my static sprite that has only 1 frame, and then passing this animation name to t2dAnimatedSprite when creating it, the T2D editor doesn't let me create animations from single-frame ImageMaps. I have to actually go into managed.cs and do it there. So it's possible to do what I want, but Torque makes it much harder than it should be. If I have lots of static sprites, then I have to create a single-frame "animation" for each one manually.

EDIT: Actually, creating an animation in managed.cs doesn't work after all. Leaving me no solution for the problem, other than re-save all single-frame ImageMaps as two-frame ImageMaps (wasting memory with duplicate images), which *then* allows me to use it as an animated sprite. This is a pretty bad workaround.

EDIT #2: Apparently, by using Linked ImageMaps, I can also partially get around the problem. That is, create a linked imageMap which contains all the static images I want to use, and then I can create an "animation" from this linked imageMap. However, only a few of the single-frame ImageMaps that I want to use are available in the linked imageMap editor... why are some available, and others are not?

EDIT #3: I just thought of another possible solution: create the animated sprite that inherits from its parent, but is invisible. Then create a static sprite like I want, and mount this to the invisible animated parent. That just might work. But the fact that I have to resort to stuff like this shouldn't be necessary.

#56 Wouldn't the simplest solution be to create an EnemyAnimated class that's just a copy of Enemy instead? Seems to me like creating weird ImageMaps would be more work.

Definitely is a problem, though.

#57 I'm not sure I quite follow what you mean by "a copy" of Enemy. You mean duplicating all methods? That would be a big mess... there are 1900 lines of code in "Enemy". And having to update both copies of a method when making changes? Ugh. But maybe I'm misunderstanding your suggestion.

#58 Well, behaviors would help with that too, no? I wouldn't suggest creating a class that big to begin with though as I would think it would be a pain to maintain it.

Anyway, as to your initial point of removing the distinction, my understanding from previous posts by Melv is that there are some performance benefits that static sprites get (maybe it was just memory saved?) that wouldn't make sense to lose just for "convenience"... especially considering that there are work arounds to the issue.

Maybe with the component based architecture of torque 2 we can see some of these issues addressed though.
-Andrew

#59 Success! Mounting a static sprite on top of an invisible animated sprite works!

Perhaps instead of removing the distinction, there can be some way of allowing both to inherit from a common parent class? I don't know.

Haven't used behaviors, so I'm not sure if that would solve my problem or not.

So far my Enemy class has been very easy to maintain, so no problem due to size.

#60 Easy to see, rigid body dynamics is a major concern for some people. I am certainly not an exception.

To make the type of games for which I have purchased TGB (1.7.4), TGB must have good rigid body dynamics integration!

Since I also arrived late to the party, I would love to hear that Box2D is currently being integrated into a release of TGB. Certainly most of us software developers have a clear grasp of the cost and benefit of going forward with a full Box2D integration into TGB, but in my opinion, I have seen a drastic increase in popularity of physics-based games and the benefit would outweigh the cost. Especially if properly marketed.

I understand TGB 1.7.3+ has upgraded rigid body support that would stop the jittery behavior of the bodies, but I have yet to configure the objects just right to completely stop the jitter. I would truly appreciate someone sharing a link to a detailed description of how to see the fixes to rigid body dynamics in action for 1.7.4, because I have not found the right tweaks in settings to accomplish it.

Lastly, I would like to congratulate and thank GarageGames employees and associates for all they do. I believe in this company.