T2D ideas, suggestions, etc.
by Fenrir Wolf · in Torque Game Builder · 03/05/2005 (5:50 pm) · 10 replies
Okay, I've been making notes as I go along so here's an info dump for Melv and Josh on some things I noticed about T2D.
First off, I'm not going to go into the particle and tilemap editor too much, even though it's got a fair number of interface problems. (No actual bugs that I can see, though.) I understand these were added in pretty quickly and you guys are probably well aware of a lot of the usage issues. The only interface issue I will recommend, however, is that you allow cut and pasting of tiles in the tilemap editor.
fxAnimatedSprite2D - There are two types of animations, cycling and none. A flag should be added so the user can choose to have non-cycled animations either reset to frame #0 or hold the last frame. (This allows for visual state changes on objects that hold until they need to be changed again. For example, a player turns left, you want the last frame of the turn-to-left animation to hold.)
fxTilemap2D - tile-script callbacks should function even if the layer is set to invisible. I understand, from looking at the code, that setting a tilemap invisible completely overrides the tile checking code (where the tile-script functions live), but I would like to have a dedicated layer that acts like a control system. Right now, I can "fake" it by using tiny, blank tiles. In general, you could extend this system to make it so individual tile visibility can be flagged. This would be good for stuff such as, say a large wall the player needs to go push a button to destroy. You can then just set the wall invisible when he hits the button. (Yeah, you could spawn a seperate object to act as the wall, but a tilemap solution would be more elegant.)
fxSceneObject2D - setDampingMinVelocity(minvel), so that damping only slows the object down to minvel velocity. I use this in Cloudburst for bullets -- they fire at around 600 velocity, with damping enabled so they quickly slow down to around 200 or so, but never go below that.
fxTileMap2D - GetPanPosition() returns X/Y in world units, but setpanposition() deals with tile units. Kinda a bit confusing, might want to make getpanposition() return in tile units, then have a getpanpositionworld() to get it in world units.
All fxSceneObject2Ds - It would be nice if we could get the normalized mount position coordinates based on the object's pivot point. Using getlinkPoint() on a mount returns it in local coordinates that aren't normalized and I think are based on the Bbox. In other words, I want some way to get the same coordinates I passed into mount when I query that mount's location.
I also think we need more motion generators that feed into the dynamics system. While you can emulate most in script, it would be really nice to have a set of functions that could generate common motions without having to do script/mount-fu. (Such as rotation-around-point, sinewaves, move-to points with perhaps spline defomation.) Even better if these could be added on top of existing motions so they can make for more complicated motions. (For example, my boss in the demo could benefit from a very slight up-down wobble.) I plan on taking a stab at adding some this myself to T2D.
We need a colpoly editor, but again you guys probably already know that. Plus a mount-point visualizer. I'm sure the sceneobject editor I'm hearing about will address that. :)
Some of the things I talked about I've already modified in T2D. Though currently very hacky I could always clean it up and submit it to the code base?
UPDATE: Oh yeah. I would also like the ability to have a local rotation offset for mounted objects that are set to track rotation of their parent. I still want that child object to rotate in the same direction as the parent, but I'd love to be able to supply offsets so I can have it still rotate on its own if need be.
First off, I'm not going to go into the particle and tilemap editor too much, even though it's got a fair number of interface problems. (No actual bugs that I can see, though.) I understand these were added in pretty quickly and you guys are probably well aware of a lot of the usage issues. The only interface issue I will recommend, however, is that you allow cut and pasting of tiles in the tilemap editor.
fxAnimatedSprite2D - There are two types of animations, cycling and none. A flag should be added so the user can choose to have non-cycled animations either reset to frame #0 or hold the last frame. (This allows for visual state changes on objects that hold until they need to be changed again. For example, a player turns left, you want the last frame of the turn-to-left animation to hold.)
fxTilemap2D - tile-script callbacks should function even if the layer is set to invisible. I understand, from looking at the code, that setting a tilemap invisible completely overrides the tile checking code (where the tile-script functions live), but I would like to have a dedicated layer that acts like a control system. Right now, I can "fake" it by using tiny, blank tiles. In general, you could extend this system to make it so individual tile visibility can be flagged. This would be good for stuff such as, say a large wall the player needs to go push a button to destroy. You can then just set the wall invisible when he hits the button. (Yeah, you could spawn a seperate object to act as the wall, but a tilemap solution would be more elegant.)
fxSceneObject2D - setDampingMinVelocity(minvel), so that damping only slows the object down to minvel velocity. I use this in Cloudburst for bullets -- they fire at around 600 velocity, with damping enabled so they quickly slow down to around 200 or so, but never go below that.
fxTileMap2D - GetPanPosition() returns X/Y in world units, but setpanposition() deals with tile units. Kinda a bit confusing, might want to make getpanposition() return in tile units, then have a getpanpositionworld() to get it in world units.
All fxSceneObject2Ds - It would be nice if we could get the normalized mount position coordinates based on the object's pivot point. Using getlinkPoint() on a mount returns it in local coordinates that aren't normalized and I think are based on the Bbox. In other words, I want some way to get the same coordinates I passed into mount when I query that mount's location.
I also think we need more motion generators that feed into the dynamics system. While you can emulate most in script, it would be really nice to have a set of functions that could generate common motions without having to do script/mount-fu. (Such as rotation-around-point, sinewaves, move-to points with perhaps spline defomation.) Even better if these could be added on top of existing motions so they can make for more complicated motions. (For example, my boss in the demo could benefit from a very slight up-down wobble.) I plan on taking a stab at adding some this myself to T2D.
We need a colpoly editor, but again you guys probably already know that. Plus a mount-point visualizer. I'm sure the sceneobject editor I'm hearing about will address that. :)
Some of the things I talked about I've already modified in T2D. Though currently very hacky I could always clean it up and submit it to the code base?
UPDATE: Oh yeah. I would also like the ability to have a local rotation offset for mounted objects that are set to track rotation of their parent. I still want that child object to rotate in the same direction as the parent, but I'd love to be able to supply offsets so I can have it still rotate on its own if need be.
#2
fxAnimatedSprite2D - No, your idea is perfect! I can't think of any reason I'd want to swap an animation from hold-last to reset-to-beginning. And, if for whatever reason I did, I'd just define an extra datablock, having it inherit the settings from the first one and override the hold-last-frame.
fxTileMap2D - Yeah, I kinda figured this was gonna be hairy. I hadn't spent much time in the tile code, but initially that's what I saw just from glancing at it. As for course-tiles with no actual rendering but still processed by scenegraph, that sounds fine by me. I really can't think of a need for having invisible tile-script objects mixed in with ordinary tiles. If I did, I'd just attach it to a normal tile that I would want to be rendered, anyway. Still like the individual invisibility flag idea though, but I understand if this isn't that easy to implement and breaks the scenegraph methodology.
fxSceneObject2D - Other limits I would like to see would be rotational damping, or even a set-rotation-to with an associated speed factor. I currently emulate that right now in script with this function:
But anything that can be handled in the main engine and is simple to implement, I'd say do it if you want to provide the best newbie-friendly solution. As for the rest being under the influence of limits -- Yeah, I can see why adding them would be hard. Damping was pretty easy, though to change.
fxTileMap2D - *cough* My error. There isn't a getPanPosition() in out-of-the-box T2D. I added it in myself, so I was complaining about a function I had written. :) It just returns mPanPositionX/Y. So, completely ignore my suggestion! However, I think getPanPosition() should exist as part of the interface. I used it to "rewind/fastforward" a level for debugging.
fxSceneObject2Ds + LocalPoint - That's weird, because when I asked getLocalPoint() about the mount point's pos returned by getLinkPoint(), it replied back with something like "1.342 3.842". The originally mount point was certainly not that. I can get you specific numbers/cases if you think this might be a bug.
As for using mounts as a way to emulate complex behaviors, yeah I did see that in the demo. In fact, that's one way you can simulate aribtrary rotation points, I've noticed. I like this idea of a path object, especially if you can specify such things as waypoints and such. (So it's kind of like AIPlayer.) :)
Offset rotations: Hmmmm, probably the easiest would be just use the object's rotation, and treat it as an offset. So, if you rotate it -20 degrees, and the mount is rotated 40 degrees, it will end up at 20 degrees.
Anyway, thanks for replying!
03/06/2005 (2:15 pm)
Hey, it's no problem. I know you guys are looking for valuable input, and anything I can do to help make T2D better, I'm game!fxAnimatedSprite2D - No, your idea is perfect! I can't think of any reason I'd want to swap an animation from hold-last to reset-to-beginning. And, if for whatever reason I did, I'd just define an extra datablock, having it inherit the settings from the first one and override the hold-last-frame.
fxTileMap2D - Yeah, I kinda figured this was gonna be hairy. I hadn't spent much time in the tile code, but initially that's what I saw just from glancing at it. As for course-tiles with no actual rendering but still processed by scenegraph, that sounds fine by me. I really can't think of a need for having invisible tile-script objects mixed in with ordinary tiles. If I did, I'd just attach it to a normal tile that I would want to be rendered, anyway. Still like the individual invisibility flag idea though, but I understand if this isn't that easy to implement and breaks the scenegraph methodology.
fxSceneObject2D - Other limits I would like to see would be rotational damping, or even a set-rotation-to with an associated speed factor. I currently emulate that right now in script with this function:
function fxanimatedsprite2d::rotateto (%obj, %goal, %factor)
{
if (isobject (%obj)) {
if (iseventPending (%obj.lastrotsched))
cancel (%obj.lastrotsched) ;
%r = %obj.getrotation() ;
if (mAbs (%r - %goal) > 1.0) {
if (%r > %goal) {
%r -= %factor ;
%obj.setrotation (%r) ;
%obj.lastrotsched = %obj.schedule (10, rotateto, %goal, %factor) ;
} else {
%r += %factor ;
%obj.setrotation (%r) ;
%obj.lastrotsched = %obj.schedule (10, rotateto, %goal, %factor) ;
}
}
}
}But anything that can be handled in the main engine and is simple to implement, I'd say do it if you want to provide the best newbie-friendly solution. As for the rest being under the influence of limits -- Yeah, I can see why adding them would be hard. Damping was pretty easy, though to change.
fxTileMap2D - *cough* My error. There isn't a getPanPosition() in out-of-the-box T2D. I added it in myself, so I was complaining about a function I had written. :) It just returns mPanPositionX/Y. So, completely ignore my suggestion! However, I think getPanPosition() should exist as part of the interface. I used it to "rewind/fastforward" a level for debugging.
fxSceneObject2Ds + LocalPoint - That's weird, because when I asked getLocalPoint() about the mount point's pos returned by getLinkPoint(), it replied back with something like "1.342 3.842". The originally mount point was certainly not that. I can get you specific numbers/cases if you think this might be a bug.
As for using mounts as a way to emulate complex behaviors, yeah I did see that in the demo. In fact, that's one way you can simulate aribtrary rotation points, I've noticed. I like this idea of a path object, especially if you can specify such things as waypoints and such. (So it's kind of like AIPlayer.) :)
Offset rotations: Hmmmm, probably the easiest would be just use the object's rotation, and treat it as an offset. So, if you rotate it -20 degrees, and the mount is rotated 40 degrees, it will end up at 20 degrees.
Anyway, thanks for replying!
#3
03/06/2005 (3:01 pm)
Oh yeah! One more idea -- how about for particles, we can specify a negative emissive force? Right now, negative values don't seem to do anything. Basically I am looking for a way to "suck in" all of the particles to a single point. (Imagine an item teleporting in, where all the particles merge at the center and the item then spawns at that point.) 
#4
fxTileMap2D - I actually read your post again and I missed the idea of making individual tiles invisible. That wouldn't be a problem at all. I think I posted somewhere else where I mentioned that I still need to tune the tilemaps so that they are much more efficient. I want to allow for the ability of blending-per tile and I can add invisibility as well. When rendering, I want to do a pre-sort of the tiles and batch them by texture so that we get minimal texture thrashing.
I'd love to discuss with you all sorts of cool ideas I originally had for the tilemaps. I think our implementation is cool but we do have some crazy cool ideas on where we could take them. Having seperate rectilinear, iso and hex layers isn't the most intuitive thing in the world and there has to be a better way of fusing them together. If you're interested in discussing a new way of thinking about tile-maps then we can start a discussion on the forums or privately. I'm thinking of more of a texture-splating / polygon soup-style technique where you've essentially got a virtual, scrollable world with movable objects, almost coming full circle with T2Ds existing scene. You could actually see this as a portal of a different scene, fully interactive though. I'm not saying we'd approach this anytime soon and I can see Josh frowning at me already! ;) *kidding Josh*
fxSceneObject2D + LocalPoint - I went back and tried this again and it seems to work perfectly. I should also take rotation/scale into account as well.
Path-Object: Defination on the books for a flexible path object. linear / Spline paths as well as some kind of parameterised waveform path generator as a suppliment that would generate these waveforms for you.
Offset Rotations: So you think just using the objects rotation rather than having another parameter on the mount is better? Not bothered either way but I can see that the "mount()" function is getting pretty parameter-heavy already so just using the objects rotation at the point its mounted makes sense.
Next Post: Particles - I actually came across this in the grav-demo. You'll see it soon but I wanted a similar effect and the way I achieved it was to have a particle texture with particles on it (nice way to get more particles for cheap) that shrunk and so looks liked they were being sucked ito oblivion. The negative-emissive force works as it should now; the problem is that to achieve the effect you want, particles need to be able to reference their "UP" with relation to the center of the effect. That way, when a particle has positive emission, it moves away from the center and negative moves towards it. It's pretty easy to add a flag to turn this center reference on and off.
I'll add that to the list of stuff to do on the particles.
Thanks Dave!
- Melv.
03/07/2005 (2:05 am)
Dave,fxTileMap2D - I actually read your post again and I missed the idea of making individual tiles invisible. That wouldn't be a problem at all. I think I posted somewhere else where I mentioned that I still need to tune the tilemaps so that they are much more efficient. I want to allow for the ability of blending-per tile and I can add invisibility as well. When rendering, I want to do a pre-sort of the tiles and batch them by texture so that we get minimal texture thrashing.
I'd love to discuss with you all sorts of cool ideas I originally had for the tilemaps. I think our implementation is cool but we do have some crazy cool ideas on where we could take them. Having seperate rectilinear, iso and hex layers isn't the most intuitive thing in the world and there has to be a better way of fusing them together. If you're interested in discussing a new way of thinking about tile-maps then we can start a discussion on the forums or privately. I'm thinking of more of a texture-splating / polygon soup-style technique where you've essentially got a virtual, scrollable world with movable objects, almost coming full circle with T2Ds existing scene. You could actually see this as a portal of a different scene, fully interactive though. I'm not saying we'd approach this anytime soon and I can see Josh frowning at me already! ;) *kidding Josh*
fxSceneObject2D + LocalPoint - I went back and tried this again and it seems to work perfectly. I should also take rotation/scale into account as well.
Path-Object: Defination on the books for a flexible path object. linear / Spline paths as well as some kind of parameterised waveform path generator as a suppliment that would generate these waveforms for you.
Offset Rotations: So you think just using the objects rotation rather than having another parameter on the mount is better? Not bothered either way but I can see that the "mount()" function is getting pretty parameter-heavy already so just using the objects rotation at the point its mounted makes sense.
Next Post: Particles - I actually came across this in the grav-demo. You'll see it soon but I wanted a similar effect and the way I achieved it was to have a particle texture with particles on it (nice way to get more particles for cheap) that shrunk and so looks liked they were being sucked ito oblivion. The negative-emissive force works as it should now; the problem is that to achieve the effect you want, particles need to be able to reference their "UP" with relation to the center of the effect. That way, when a particle has positive emission, it moves away from the center and negative moves towards it. It's pretty easy to add a flag to turn this center reference on and off.
I'll add that to the list of stuff to do on the particles.
Thanks Dave!
- Melv.
#5
03/07/2005 (8:40 am)
Sorting tilemaps by texture would give such a performance benefit. In one of my own experiments I was rendering a scene without having sorted by texture and I got somewhere around less than 60 fps, but when I sorted the textures I got a speed increase about 6 times. It was amazing.
#6
All work that will get done soon enough. :)
- Melv.
03/07/2005 (8:55 am)
@Seth: Absolutely. This also goes for the particles which need batching rather than pushing nasty quad-primitives through the pipeline.All work that will get done soon enough. :)
- Melv.
#7
Throw in some more docs and a platformer example in the next release and I'd buy T2D again!
03/07/2005 (12:56 pm)
This just keeps getting better and better. :^)Throw in some more docs and a platformer example in the next release and I'd buy T2D again!
#8
Documentation is very important to us. We've want to get lots of it out ASAP.
Lots of demos to come and a platformer is definatley a must!
- Melv.
03/07/2005 (1:20 pm)
Get some friends to purchase it, put a review on the product page and you've got a deal. LOL.Documentation is very important to us. We've want to get lots of it out ASAP.
Lots of demos to come and a platformer is definatley a must!
- Melv.
#9
@platformer demo: good to hear! I have to take a short 2-day hiatus from T2D as I have some midterms 'n junk. :\
03/07/2005 (5:18 pm)
I already got 2 people interested who have bought it, and a few more are interested as well. Too bad there's no affiliate program. Just telling other people about T2D could have already paid for me to have it. :)@platformer demo: good to hear! I have to take a short 2-day hiatus from T2D as I have some midterms 'n junk. :\
#10
And thanks for the idea about how to simulate the "sucking in" animation. I hadn't thought of that! :)
Heck, even unoptimized, the particles/tilemaps are blazingly fast...
03/09/2005 (1:21 pm)
Melv: Hmm, interesting idea about a less-rigid tile structure. While I'm sure that's within Torque's capabilities insofar as rendering is concerned, how did you plan on handling the collision detection/physics. Allow tiles to have Z-axis will mean you'll need to effectively re-create Torque's physics. (I can see why Josh is frowning. ;) As for something like iso, I've always treated it as a 2D world -- it's just that the bitmaps happen to extend "upwards" and can be rendered with Z-ordering. So, why not just calculate physics as normal, then when rendering the tilemaps, do a projection-style conversion. This, of course, would mean you'd need special classes for iso sprites, too -- which might not be the way you are looking to go, as you said you want to mesh these various types a bit more cleanly.And thanks for the idea about how to simulate the "sucking in" animation. I hadn't thought of that! :)
Heck, even unoptimized, the particles/tilemaps are blazingly fast...
Associate Melv May
fxAnimatedSprite2D - In the first release, the underlying animation-controller had a bug that moved non-cycling animations back to frame-one upon exit; this has been fixed. The non-cycling flag is currently defined in the datablock. Are you saying this would be better suited as another parameter in the "playAnimation" call? I just wanted to keep, what I considered static data, out of the functions. I'm quite happy to entertain that it is useful quite often to switch cycling on/off for animations.
fxTileMap2D - The problem with knowing whether which tiles have appeared involves processing the tiles as if they are rendering and this goes against the scene-graph. Also, this kind of functionality, although totally understandable, is definatley in the hack bin. One of the things I definatley would be open to would be to allow a tile to have a script without being forced to render anything. This would provide the functionality you want and to cut-down the processing, you could have large/coarse tiles here instead of the same size as the map. They could be rooms or just world-regions. Does this sound good enough?
fxSceneObject2D - You know, I've been thinking about the naming of the minimum-bounds stuff for the physics. The minimum linear/angular velocity settings are really the threshold at which point, the values are set to zero. This is kinda' misleading. Having a specific damping minimum linear velocity would be fine, even if very specific, but having any other non-zero limit could be problematic. I'll definately have a think about this one, don't see a problem with it in overview.
fxTileMap2D - There isn't a "getPanPosition()" although I guess there should be. :) There isn't really anything such as tile-units because tiles don't have any sense of scale. If a tile size is 40x20, it'll occupy 40x20 in world-units, the only thing you can control is how many fit within the tile-layers window size. Yes?
All fxSceneObject2Ds - Easy one this. We provide a function "getLocalPoint()" that will convert any world-point into one that's local to the object in the same coordinate system.
motion generators - Absolutely like the idea of this. We've already discussed the idea of path generation and it's definatley something we'll be looking at doing at a later date. There are certain ways to achieve this. For instance, in the Grav-demo, Flegg moves around in a sinusoidal movement. This is achieved by mounting to two mounted counter-rotating fxSceneObjects. We also do this in the fish-demo but in this case we mount the camera to the objects. The waves of enemy in the shooter are also mounted to the corner of a rotating fxSceneObject. This isn't the way we want to go but it does allow you to create "articulation frames" which you attach objects to. A path object is definately a cool idea.
Collision-poly editor - Absolutely. It's brutal doing this without one, we just ran out of time and didn't want to hold-up the release. An absolute must for the near future.
Offset Rotations - Like the idea of that. Would you prefer to just use the rotation of the object when you mount it, a specified offset or perhaps both?
Regarding code submission, sure send them to me. It does look like we've got most of this covered but at the very least, it'll ensure that we're both talking about the same things.
Okay them last thing, David, thanks for this submission. It's exactly the kind of condensed, well-informed material that we want from the EA release. It's nice to see that you've made something with T2D, thought about what could be better and then have passed it along.
I'd welcome a summation from anyone else in the same lines as what David's done here.
Many thanks,
- Melv.