Tilemap positioning
by David House · in Torque Game Builder · 02/26/2005 (9:31 am) · 14 replies
OK, so I created a new tile map that is 50x50 ( just using the default that was created ). I saved it, then followed along with the tutorial to create the tilemap in the game. Here is the code:
My camera is setup as follows:
sceneWindow2D.setCurrentCameraPosition( "0 0 50 50" );
Now when the screen renders, the tilemap is shown like this:
If I change the .setPosition to use "0 0" then the tilemap doesn't render at all!
So exactly how does the setPosition relate to where the tilemap is rendered? I would think the setPosition would put the center of the tilemap at a certain spot based on the center of the map.
This question can also be asked another way. How do I render a 50x50 tilemap so that it covers the entire screen?
datablock fxImageMapDatablock2D(bgTileMap)
{
mode = full;
textureName = "~/client/images/tileMap";
};
%tileMap = new fxTileMap2D() { scenegraph = t2dSceneGraph; };
%tileMap.loadTileMap( "~/client/tMap.map" );
%tileLayer = %tileMap.getTileLayer(0);
%tileLayer.setPosition( "50 50" );
%tileLayer.setTileSize( "2 2" );My camera is setup as follows:
sceneWindow2D.setCurrentCameraPosition( "0 0 50 50" );
Now when the screen renders, the tilemap is shown like this:
If I change the .setPosition to use "0 0" then the tilemap doesn't render at all!
So exactly how does the setPosition relate to where the tilemap is rendered? I would think the setPosition would put the center of the tilemap at a certain spot based on the center of the map.
This question can also be asked another way. How do I render a 50x50 tilemap so that it covers the entire screen?
#2
02/26/2005 (9:58 am)
Thanks Melv. I'll find something else to do for the next 10 minutes.... :) 
#3
I'd definately recommend that you play with something simple like a fxStaticSprite2D before you mess with fxTileMap2D and fxTileLayer2D as the tile stuff is the harder of the two to understand and the simple sprites provide a good grounding for what's to come.
So, you understand that when you issue a command like...
Now, to the tile-layer. Another fundamental thing to remember is that the fxTileLayer2D is just another core fxSceneObject2D and therefore needs to be position and sized (as above) just like any other object so you end up using something like...
The critical mistake here is that if you use almost any other object in T2D, what happens is that T2D automatically scales the contents to fit exactly inside the objects window, in this case (60x60). With tiles, it's a little different and for good reason. The way tile-layers work are that you control them in two stages. The first is that you set the position and size which defines a window to which the contents will be rendered, just like any other T2D object.
The difference here is that rather than just scaling the tiles to fit, the tile-layer allows you to specify how big the tiles are with...
As you might then see, if we set our window to be 60x60 and our tiles are 10x10 in size and assuming we have say 3 x 3 tiles in the layer, the tiles will render from the top left and will take a total space of (10*3)x(10*3) = 30x30, only the top-left of our tile-layer window.
Now this all sounds complicated but why is it like this? Well, the reason is that if we were to remove the ability to control the width/height of tiles, the layer would only render the tiles once within the layer. What does this gobble-de-gook mean? Well, don't forget that you can do cool stuff like tell the tile-layer to wrap the tiles. The way this works is that it won't stop when it's rendered the tiles in the window, it will repeat then until all the window (as defined above) is filled with tiles and you can happily pan the tiles and it will automatically handle the tiles for you.
...
02/26/2005 (11:02 am)
Tile LayersI'd definately recommend that you play with something simple like a fxStaticSprite2D before you mess with fxTileMap2D and fxTileLayer2D as the tile stuff is the harder of the two to understand and the simple sprites provide a good grounding for what's to come.
So, you understand that when you issue a command like...
%mySprite.setPosition("10 20");... that your objects' center will placed at the world position (10,20). Simple to understand but then you also need to realise then when you issue a command like...%mySprite.setSize("50 60");... that your object is sized to be 50 wide and 60 high. All simple stuff but the critical part is that no T2D objects allow you to specify their top-left and bottom-right, you always use center position using "setPosition()" and size using "setSize()". This might sounds strange at first but when you think about it, most of the time all you need to do is have an object located at a certain position and be at a certain location.Now, to the tile-layer. Another fundamental thing to remember is that the fxTileLayer2D is just another core fxSceneObject2D and therefore needs to be position and sized (as above) just like any other object so you end up using something like...
%tileLayer = %tileMap.getTileLayer(0); %tileLayer.setPosition( "0 0" ); %tileLayer.setSize( "60 60" );... so this sets the tile-layer to be a (0,0) and be 60 wide and 60 height.
The critical mistake here is that if you use almost any other object in T2D, what happens is that T2D automatically scales the contents to fit exactly inside the objects window, in this case (60x60). With tiles, it's a little different and for good reason. The way tile-layers work are that you control them in two stages. The first is that you set the position and size which defines a window to which the contents will be rendered, just like any other T2D object.
The difference here is that rather than just scaling the tiles to fit, the tile-layer allows you to specify how big the tiles are with...
%tileLayer.setTileSize( "10 10" );...which, in this case, sets the tiles to be 10 wide and 10 high. Always remember that tiles always render from the top-left of the window you defined above.
As you might then see, if we set our window to be 60x60 and our tiles are 10x10 in size and assuming we have say 3 x 3 tiles in the layer, the tiles will render from the top left and will take a total space of (10*3)x(10*3) = 30x30, only the top-left of our tile-layer window.
Now this all sounds complicated but why is it like this? Well, the reason is that if we were to remove the ability to control the width/height of tiles, the layer would only render the tiles once within the layer. What does this gobble-de-gook mean? Well, don't forget that you can do cool stuff like tell the tile-layer to wrap the tiles. The way this works is that it won't stop when it's rendered the tiles in the window, it will repeat then until all the window (as defined above) is filled with tiles and you can happily pan the tiles and it will automatically handle the tiles for you.
...
#4
Okay, here's a few examples of controlling the tile-layer....
Here we've got the default camera window and I've added the logical coordinates at the corners of the screen (note that the menu overlays the screen). I've created a tile-layer with (5x5) tiles, each tile being (10x10) in size and I've set the tile-layer window so that it exactly matches the tiles within e.g. (50x50). Note that I've positioned it at (0,0) as well. You'll see the cyan border (I used $t2dSceneGraph.setDebugOn(BIT(1)); to do this - see ref guide) which shows you the bounding box for the tile-layer (remember it's just a standard fxSceneObject2D).
Okay then, next I've made the actual tiles bigger (14x14) instead of (10x10) and I've sized the object to match so it becomes (5*14)x(5*14) = (70x70).
Okay, that's all fine but how does this help with the previous explanation? Well, let's make things smaller rather than larger. Next-up I've set the tiles to that they're (5x5) but this time, I've set the fxTileLayer2D's size to (60x60). What this means is that the tiles only take up (5x5)x(5x5) = (25x25) which is less than a quarter of the area. Notice how the tilelayer renders the tiles at the top-left? This is important to understand. When you pan the tile-layer, this block of (5x5) tiles will pan around.
Okay, finally, this should help clarify exactly why you have control over the tile-sizes. The final configuration has the same number of tiles (5x5) and they are still the same size (5x5). Also, we've kept the tile-layer object size the same at (60x60) but this time, we've told the map to wrap the tiles (in this example, in both axis) so what it does this time is automatically repeat the tile-rendering over the objects window. How cool? Using automatic panning, you have an infinite tile-set to now scroll over. You can dynamically change the size of the tiles if you want. Don't forget though that tiles behave identical to other objects when you zoom in on the camera e.g. they get bigger/smaller as you zoom.
Hopefully, I've covered the topic here but they can be confusing. The golden rule is that you set the position and size of the tile-layer and then you configure tile-sizes. Note that the tile-sizes will be what you set in the editor but you can change them. Also note that there is absolutely no performance overhead of changing the tile-size so do it whenever and however often you want. If you're trying to achieve a zooming effect though, use the camera.
I hope this helps explain the tile-maps a little better.
We'll be doing much more comprehensive documentation covering individual objects like this.
- Melv.
02/26/2005 (11:02 am)
(...)Okay, here's a few examples of controlling the tile-layer....
Here we've got the default camera window and I've added the logical coordinates at the corners of the screen (note that the menu overlays the screen). I've created a tile-layer with (5x5) tiles, each tile being (10x10) in size and I've set the tile-layer window so that it exactly matches the tiles within e.g. (50x50). Note that I've positioned it at (0,0) as well. You'll see the cyan border (I used $t2dSceneGraph.setDebugOn(BIT(1)); to do this - see ref guide) which shows you the bounding box for the tile-layer (remember it's just a standard fxSceneObject2D).
Okay then, next I've made the actual tiles bigger (14x14) instead of (10x10) and I've sized the object to match so it becomes (5*14)x(5*14) = (70x70).
Okay, that's all fine but how does this help with the previous explanation? Well, let's make things smaller rather than larger. Next-up I've set the tiles to that they're (5x5) but this time, I've set the fxTileLayer2D's size to (60x60). What this means is that the tiles only take up (5x5)x(5x5) = (25x25) which is less than a quarter of the area. Notice how the tilelayer renders the tiles at the top-left? This is important to understand. When you pan the tile-layer, this block of (5x5) tiles will pan around.
Okay, finally, this should help clarify exactly why you have control over the tile-sizes. The final configuration has the same number of tiles (5x5) and they are still the same size (5x5). Also, we've kept the tile-layer object size the same at (60x60) but this time, we've told the map to wrap the tiles (in this example, in both axis) so what it does this time is automatically repeat the tile-rendering over the objects window. How cool? Using automatic panning, you have an infinite tile-set to now scroll over. You can dynamically change the size of the tiles if you want. Don't forget though that tiles behave identical to other objects when you zoom in on the camera e.g. they get bigger/smaller as you zoom.
Hopefully, I've covered the topic here but they can be confusing. The golden rule is that you set the position and size of the tile-layer and then you configure tile-sizes. Note that the tile-sizes will be what you set in the editor but you can change them. Also note that there is absolutely no performance overhead of changing the tile-size so do it whenever and however often you want. If you're trying to achieve a zooming effect though, use the camera.
I hope this helps explain the tile-maps a little better.
We'll be doing much more comprehensive documentation covering individual objects like this.
- Melv.
#5
So by using .setAutoPan and .setPanPosition, I could do something like create a large tile map, but only display a few tiles at a time. Much like a typical 2D rpg where the player moves around and when they get to the edge, the map starts moving in the direction they are trying to go. Very cool!
I just simply put in the .setSize above and the tilemap is rendering just where I expect it to. Its going to take just a bit to get used to using the coordinates this way, but it makes perfect sense now that I see what I was doing wrong.
I'm sure I'll have more questions as time goes on. Thanks for taking the time to explain this ( with screenshots no less! ). You are da man!
02/26/2005 (12:08 pm)
Thanks Melv, perfect explantation. One thing I figured out that I was doing wrong is not specifying a .setSize on the tilemap itself. Since you have now explained that the .setPosition and .setSize are basically creating a window or viewport for the whole tilemap, it makes perfect sense. And the sizes of the tiles are independant of that.So by using .setAutoPan and .setPanPosition, I could do something like create a large tile map, but only display a few tiles at a time. Much like a typical 2D rpg where the player moves around and when they get to the edge, the map starts moving in the direction they are trying to go. Very cool!
I just simply put in the .setSize above and the tilemap is rendering just where I expect it to. Its going to take just a bit to get used to using the coordinates this way, but it makes perfect sense now that I see what I was doing wrong.
I'm sure I'll have more questions as time goes on. Thanks for taking the time to explain this ( with screenshots no less! ). You are da man!
#6
Eventually, the tilemap and editor documentation will contain all this kind of stuff. For now, David, thanks for the good question.
02/26/2005 (1:46 pm)
Nice Melv. Docos on the fly, here we go. :) Eventually, the tilemap and editor documentation will contain all this kind of stuff. For now, David, thanks for the good question.
#7
02/26/2005 (1:51 pm)
That first image with the Co-ordinates listed is very usefull... I'd pretty much figured it out when working on the pong game. But seeing it in an image really makes it stick.
#8
So a "unit" is defined when the camera is set up. If my screen is set to 800 x 600, and I make a camera that is also 800x600, then all my sprite and tile sizes will basically be in pixels... yes? Is there a better way to think about units?
This is loads of fun so far! But so many questions...
Great job though guys!
02/27/2005 (1:05 am)
AH-HA!So a "unit" is defined when the camera is set up. If my screen is set to 800 x 600, and I make a camera that is also 800x600, then all my sprite and tile sizes will basically be in pixels... yes? Is there a better way to think about units?
This is loads of fun so far! But so many questions...
Great job though guys!
#9
... which zooms the camera in x2?
Then, each "unit" occupies approximately 2 pixels because we're zoomed in x2. That's always the danger. The other hidden dangers of course are that for the logical coordinates to be the screen-resolution, two things have to be true, you must be fullscreen and the fxSceneWindow2D GUI control (what T2D renders into) must occupy all of the window (something which isn't necessarily so). Always dangerous to discuss them sneaky pixels. :)
There's another factor that should be taken into account if you start to work with the rigid-body dynamics but I'm not going to confuse the issue here with that.
Matching the art to the resolution really depends on how you decide higher resolutions will work with your graphics. In the fish-demo (be with you soon), the default resolution is 800x600 (same as the SDK) and the large-scale background looks good and the fish look okay. If you increase the resolution, the logical T2D coords stay the same (actually as the example above) but now that we're rendering across a higher resolution surface (pixels), the background and the fish show more detail. The background is something like 1600x1200 and therefore you get emergent detail, the same for the fish. This of course is also true if you keep your resolution the same but use the camera zoom, any extra detail automatically emerges as a result of the texture-mapping process on the graphics card.
This is really the advantage you get with using modern hardware. If you're happy using the higher-res textures by default, you automatically get emergent detail (texels) if the res goes up or the camera zooms.
Don't forget as well that you can change the camera position, area and zoom when you want without affecting the scene. The camera is completely passive in this sense as it should be. In-fact, the camera system is pretty good (and improvements on their way) as non of the graphics are bound to the camera or the window, they're bound to the scene (these almost mystical world-units) and so independant of how you look at them. This means you can do something like the following without affecting the objects, their collisions, mounting etc at all...
Man, I do waffle about this stuff, hopefully it helps a little somehow.
- Melv.
02/27/2005 (2:43 am)
@Phil: You got it spot-on although, as you know, it's always best to keep the idea of pixels out of your game although 1:1 art side of things is still important. What you say is true but if I were an very evil developer, which I assure you I'm not, I would then say, what if I issued...%myWindow.setCurrentCameraZoom( 2.0 );
... which zooms the camera in x2?
Then, each "unit" occupies approximately 2 pixels because we're zoomed in x2. That's always the danger. The other hidden dangers of course are that for the logical coordinates to be the screen-resolution, two things have to be true, you must be fullscreen and the fxSceneWindow2D GUI control (what T2D renders into) must occupy all of the window (something which isn't necessarily so). Always dangerous to discuss them sneaky pixels. :)
There's another factor that should be taken into account if you start to work with the rigid-body dynamics but I'm not going to confuse the issue here with that.
Matching the art to the resolution really depends on how you decide higher resolutions will work with your graphics. In the fish-demo (be with you soon), the default resolution is 800x600 (same as the SDK) and the large-scale background looks good and the fish look okay. If you increase the resolution, the logical T2D coords stay the same (actually as the example above) but now that we're rendering across a higher resolution surface (pixels), the background and the fish show more detail. The background is something like 1600x1200 and therefore you get emergent detail, the same for the fish. This of course is also true if you keep your resolution the same but use the camera zoom, any extra detail automatically emerges as a result of the texture-mapping process on the graphics card.
This is really the advantage you get with using modern hardware. If you're happy using the higher-res textures by default, you automatically get emergent detail (texels) if the res goes up or the camera zooms.
Don't forget as well that you can change the camera position, area and zoom when you want without affecting the scene. The camera is completely passive in this sense as it should be. In-fact, the camera system is pretty good (and improvements on their way) as non of the graphics are bound to the camera or the window, they're bound to the scene (these almost mystical world-units) and so independant of how you look at them. This means you can do something like the following without affecting the objects, their collisions, mounting etc at all...
// Let's assume we've currently got the default view.... ... [b]// Now let's setup a new target position for the camera...[/b] sceneWindow2D.setTargetCameraPosition( "25 15" ); [b]// Setup a new target zoom for the camera...[/b] sceneWindow2D.setTargetCameraZoom( 3 ); [b]// Move to that position over a two seconds...[/b] sceneWindow2D.startCameraMove( 2 );
Man, I do waffle about this stuff, hopefully it helps a little somehow.
- Melv.
#10
I understand now the value of separating pixels from units, but I guess I'm wondering what the recommended practice is for making sure that things are at least relative scale of texel density. I think it would be bad, for example, to author 256x256 tiles and have them scaled so that they are roughly "actual size" at a target resolution (say, 1280 x 1024). Of course they will be enlarged at 1600 x 1200, and therefore loose some of their fidelity (because they have to be sampled up). Anyway, it would then be "bad" to make an asteroid texture that was 1024 x 1024, but was only taking up say 128 x 128 pixels on screen. It's bad because it's a waste of memory (although hopefully T3D is smartly only loading the closest mip level), and it's bad because the artist then has no control over the downsampling of the original art. It's likely to look like a blurry mush.
So, what I'm thinking is that a good way to go about this is to say, well maybe 64 texels we are shooting to be "10 meters" in world space which we say is one world "unit". That way, when an artist paints a texture, they know about where to start. If the spaceship is supposed to be 10 meters long, then make an image that's about 64 pixels (1 unit). Maybe more, depending on how close the camera is likely to get, but at least keep all the art the same relative scale.
This way, when the art goes in the game, we know what to set the size to. Seems like a project would want to nail this down early, since just about everything has to have its size set (camera, tilemaps, sprites, etc). If we're not using pixels, but we know how many pixels a unit is supposed to equal, then we just divide to get the unit size of the asset (i.e. a 128 x 128 sprite would get sized to 2 x 2 units).
Does this make sense? I think it does, but maybe I'm missing something... seems like we almost have to think about it this way at the risk of some art getting sampled way up, and other art getting sampled way down, which is generally undesirable.
Oh, almost forgot why I got on this kick in the first place... does .setSize work on fxParticleEffect2D? It doesn't seem to do anything. I was trying to bring in some of the sample effects to my experiment, and they were coming in super small. I tried to setSize them up, but that didn't work. So now, I'm reseting the sizes and camera view of everything else...
-Phil
02/27/2005 (5:23 pm)
Cool, thanks for the clarification Melv. I understand now the value of separating pixels from units, but I guess I'm wondering what the recommended practice is for making sure that things are at least relative scale of texel density. I think it would be bad, for example, to author 256x256 tiles and have them scaled so that they are roughly "actual size" at a target resolution (say, 1280 x 1024). Of course they will be enlarged at 1600 x 1200, and therefore loose some of their fidelity (because they have to be sampled up). Anyway, it would then be "bad" to make an asteroid texture that was 1024 x 1024, but was only taking up say 128 x 128 pixels on screen. It's bad because it's a waste of memory (although hopefully T3D is smartly only loading the closest mip level), and it's bad because the artist then has no control over the downsampling of the original art. It's likely to look like a blurry mush.
So, what I'm thinking is that a good way to go about this is to say, well maybe 64 texels we are shooting to be "10 meters" in world space which we say is one world "unit". That way, when an artist paints a texture, they know about where to start. If the spaceship is supposed to be 10 meters long, then make an image that's about 64 pixels (1 unit). Maybe more, depending on how close the camera is likely to get, but at least keep all the art the same relative scale.
This way, when the art goes in the game, we know what to set the size to. Seems like a project would want to nail this down early, since just about everything has to have its size set (camera, tilemaps, sprites, etc). If we're not using pixels, but we know how many pixels a unit is supposed to equal, then we just divide to get the unit size of the asset (i.e. a 128 x 128 sprite would get sized to 2 x 2 units).
Does this make sense? I think it does, but maybe I'm missing something... seems like we almost have to think about it this way at the risk of some art getting sampled way up, and other art getting sampled way down, which is generally undesirable.
Oh, almost forgot why I got on this kick in the first place... does .setSize work on fxParticleEffect2D? It doesn't seem to do anything. I was trying to bring in some of the sample effects to my experiment, and they were coming in super small. I tried to setSize them up, but that didn't work. So now, I'm reseting the sizes and camera view of everything else...
-Phil
#11
02/27/2005 (6:25 pm)
Thanks for the explanation, Melv. That made things click just as I was having trouble getting my background sprite to fit the viewport. :)
#12
T2D provides a callback in the window that tells you when there has been a change to the window extents. This happens if you resize the window or if you change the resolution. You also get this callback when T2D starts and so you can begin to make decisions on how you want to handle the resolutions before you start adding stuff to the scene.
As an example. Let's say that I wanted to keep my origin in the center of the screen but I wanted the width/height of the camera view to scale such that the world-units, pixels and texels were all approximately the same thing. To do this, I'll use the base T2D code in the SDK so after the "Custom Code" section, add the following:-
... now I'll add a function below that leaves the camera centered on (0,0) but adjusts the width/height to equal the window size. I do this with the following code:-
The "setCurrentCameraPosition()" call uses the "getWords()" function to extract parameters 2 and 3 from the "%newExtents" parameter passed into the callback. The echo is just to give you info for this example so it can be removed.
You should see a box on the screen where no matter what resolution you set, always occupies the same pixel area. A nice way of showing this is to go into the GUI editor (F10), in the GUI tree on the right, select "sceneWindow2D" and drag the anchors (small black boxes) surrounding the fxSceneWindow2D control in the top/left edit window. If you drag the bottom-right anchor, you'll see that the box stays the same size (and the same aspect). if you hit the tilde "~" key, you'll see the extents being dumped to the console in realtime.
You can, of course, handle this change however you want dependant upon the effect you require. You may, for instance, not be interested in maintaining correct aspect, or you may want the origin not to be in the center.
Particles
The "setSize()" for the fxParticleEffect2D doesn't scale the particles. It does however serve a very useful purpose. When you define a particle-emitter, you can set the spawning of particles within the area of the parent-effect (this comes from the fore-mentioned setSize) to one of several modes. You can tell the particles to spawn within all of the area, a single-point (centered in this area), a line in the X axis that crosses the area as well as a line in the Y axis.
If you go into the editor, load an effect such as "Flasher.eff" and then hit the button at the bottom of the screen labelled "Stats". You'll see a cyan box area. This is the area of the fxParticleEffect2D. All emitters use this area in one of the several modes described above (in the future, each emitter will have it's own though). You can change this in the editor by changing the "object size" field at the top-left of the effect edit screen. This field is saved with the effect and is essentially the size changed by "setSize()". Try changing this field in the editor. You can load the effect and do the same in the scripts simply with "%myEffect.setSize(%someValue);".
Cool?
Hope this helps,
- Melv.
02/28/2005 (2:15 am)
@Phil: You are totally correct. Before you start any sizable project, understanding the relationships between texels -> world-units -> pixels is extremely important. There isn't one golden rule though because you can handle this in many ways. You may want to change to a high-res set of textures or you may want to just see more on the screen rather than scaling stuff up.T2D provides a callback in the window that tells you when there has been a change to the window extents. This happens if you resize the window or if you change the resolution. You also get this callback when T2D starts and so you can begin to make decisions on how you want to handle the resolutions before you start adding stuff to the scene.
As an example. Let's say that I wanted to keep my origin in the center of the screen but I wanted the width/height of the camera view to scale such that the world-units, pixels and texels were all approximately the same thing. To do this, I'll use the base T2D code in the SDK so after the "Custom Code" section, add the following:-
%sprite = new fxStaticSprite2D() { scenegraph = t2dSceneGraph; };
%sprite.setSize( 50 );
%sprite.setImageMap( tileMapImageMap );... now I'll add a function below that leaves the camera centered on (0,0) but adjusts the width/height to equal the window size. I do this with the following code:-
function sceneWindow2D::onExtentChange( %this, %newExtent )
{
// Set camera logical coords to window pixels extents to camera
sceneWindow2D.setCurrentCameraPosition( "0 0" SPC getWords(%newExtent, 2, 3) );
// Dump new extent to the console.
echo("> New Extents are" SPC %newExtent);
}The "setCurrentCameraPosition()" call uses the "getWords()" function to extract parameters 2 and 3 from the "%newExtents" parameter passed into the callback. The echo is just to give you info for this example so it can be removed.
You should see a box on the screen where no matter what resolution you set, always occupies the same pixel area. A nice way of showing this is to go into the GUI editor (F10), in the GUI tree on the right, select "sceneWindow2D" and drag the anchors (small black boxes) surrounding the fxSceneWindow2D control in the top/left edit window. If you drag the bottom-right anchor, you'll see that the box stays the same size (and the same aspect). if you hit the tilde "~" key, you'll see the extents being dumped to the console in realtime.
You can, of course, handle this change however you want dependant upon the effect you require. You may, for instance, not be interested in maintaining correct aspect, or you may want the origin not to be in the center.
Particles
The "setSize()" for the fxParticleEffect2D doesn't scale the particles. It does however serve a very useful purpose. When you define a particle-emitter, you can set the spawning of particles within the area of the parent-effect (this comes from the fore-mentioned setSize) to one of several modes. You can tell the particles to spawn within all of the area, a single-point (centered in this area), a line in the X axis that crosses the area as well as a line in the Y axis.
If you go into the editor, load an effect such as "Flasher.eff" and then hit the button at the bottom of the screen labelled "Stats". You'll see a cyan box area. This is the area of the fxParticleEffect2D. All emitters use this area in one of the several modes described above (in the future, each emitter will have it's own though). You can change this in the editor by changing the "object size" field at the top-left of the effect edit screen. This field is saved with the effect and is essentially the size changed by "setSize()". Try changing this field in the editor. You can load the effect and do the same in the scripts simply with "%myEffect.setSize(%someValue);".
Cool?
Hope this helps,
- Melv.
#13
09/29/2005 (5:36 pm)
Anyone have a copy of the images that Melv provided in his examples? I'm getting 404s.
#14
09/29/2005 (5:48 pm)
Nvm I think I finally figured out setPosition, setTileSize. :) 
Associate Melv May
No problem.
Understanding the tilemaps can be confusing at first but when it clicks, you'll be amazed how simple and powerful it is. This question is definately going to come up again and again so please bear with me for 10 minutes whilsts I put together a simple image to demonstrate.
Be back soon.
- Melv.