Game Development Community

Are tiles Sceneobjects?

by John Vanderbeck · in Torque Game Builder · 04/10/2005 (8:08 am) · 10 replies

Joh's Informal Overview was a tad unclear on this. In one line he says:

"Also, remember that tiles are derived from fxSceneObject2D."

Which is pretty clear, but then the next sentence says:

"Just as they derive physics capabilities, tile layers can be rotated, zoomed, even mounted to other objects."

So in one line he's talking tiles and the other layers. I'm a bit confused.

If tiles ARE SceneObjects that would freaking rock and make it very easy to do what I want to do. However if they are then i've been unable to find a way to actually get at that ScneObject.

Am I just being stupid and overlooking some accessor? Or are they not SceneObjects?

I was hoping to be able to manipulate the invidual tiles with things like alpha blending.

#1
04/10/2005 (8:14 am)
If they aren't, how hard would it be to create an ActiveTile that is? I BRIEFLY looked through the code on ActiveTile stuff since theres nothing in the docs about it. Seems to be a basic ConsoleObject that you inherit from and do what you want.

So I could coneivably change ActiveObject to derive from fxSceneObject2D instead since fxSceneObject2D has ConsoleObject in there somewhere i'm pretty certain (Didin't trace it all back).

I guess i'm asking, if tiles are NOT fxSceneObject2Ds, how feasible would it be replacing entire tile maps with active tiles that we derived from fxSceneObject2D
#2
12/29/2005 (3:17 am)
To answer this question, i filed this as a bug (that activeTiles dont inherit from SimObject), let alone fxSceneObject2D (changed name in 1.1)

melv said he was going to change this, but i havent checked if he did that yet in 1.1a or 1.1b
#3
12/29/2005 (5:17 am)
No, tiles are simple structs in C++ code, they're not derived from sceneObjects and they're not individual ConsoleObjects, like most objects. That's why you must access them with indexes through the tile layer.

I had the same problem, wanting to add and manipulate specific stuff on individual tiles. Thats why I created a sprite grid that manages a collection of static sprites.

Hope it helped.
#4
12/29/2005 (6:47 am)
Just to be clear as to what goes on in a tile-layer; I think it would be worth me quickly going through what exactly is happening in a tile-map/layer.

When you create a tile-layer via the tile-map, it creates an array of pointers at the tile-dimension of the layer, all of which initially are NULL.

When you explicitly ask for a tile to be created or implicitly via a tile-map/layer load from disk, T2D will generate a "tTileObject" and assign the appropriate position in the tile-layer array (as mentioned above) to this structure. It's this structure that you would call the tile itself, not a static-tile, animated-tile or active-tile and you obviously can't really talk the tile being a t2dSceneObject or anything else.

After this "tTileObject" has been created, T2D will populate it appropriately for the type of tile that was requested. As well as resetting common tile properties such scripts, custom-data, flipping and so forth, one of three structures are created and referenced in the "tTileObject". These will either be "cStaticTileNode", "cAnimationTileNode" or "cActiveTileNode". It's these structures that contain the specifics of the tile, in other words, the static, animated or active-tile details. All three of these structures inherit from the root-abstraction object called "cRootTileNode" which identifies the tile-type, has reference-counting and other "stuff".

"The first two tile-types "cStaticTileNode" and "cAnimationTileNode" are fixed and provide the two common types of tiles available on most tile-maps although I'd like to think that it provides a little more. Now, so as to allow people to create their own weird and wonderful tile-types that are not a fixed structure, don't have static capabilities and are not passive (in other words are Active), I created the active-tile. This tile-type, as you can see above, has its own structure but in-fact will create, via inheritance, any class based upon t2dActiveTile".

"t2dActiveTiles", in the alpha#1 and above, are based-upon "SimObject" which allows you to do some amazing things. You can not only create your own class but you can provide console-methods in it to allow you configure it to do anything you want. This means that when you ask the tile-layer for the active-tile, you get the ID which allows you to then configure it with scripts. That is very flexible.

So from the description above you can see that it doesn't make sense to want a tile-layer to be a "t2dSceneObject". Ninety-nine percent of it would not be used which is a senseless waste and it would be a massive overhead. On top of this, they just don't fit directly; square-peg in a round hole and all that. There is a provided mechanism to do this though; "t2dActiveTiles"!

It might be better to think of it this way; "t2dActiveTiles" are the way to customise "t2dTileLayer"s. With this object you can do anything you want. If you want to be able to create a tile and specify a standard T2D class object to be rendered there then you could create a "t2dActiveTile"-based class to do this. Hell, that'd be a cool object to have anyway so I guess you guys might wait for me to do it right? ;)

This way, all objects would load/save with the tile-map/layer but if you wanted the tile-editor to amend this then you'd also need to extend it as well. After T2D has completed the final-release we can start looking at doing professional tools such as a tile-editor. At this point, we'll also want to support the editting of active-tiles (including user ones). Now specifying a class to add is easy but because they are completely custom, the editting of these properties would have to somehow be standardised, not an easy task but doable.

In the meantime though, "t2dActiveTiles" are simple, lightweight classes that allow you to customise-to-hell your tile-maps. "t2dActiveTiles" can render "outside" of its tile-bounds meaning you can render larger than single-tile stuff. You could, for instance, render a whole scene as an active-tile if you wanted. It'd probably take an hour or so to code-up but even crazy stuff like this is possible. Something else you could do would be to create an active-tile that would allow objects to mount to it.

It would be nice to provide many examples of the kind of stuff you can do but I've just not had time and it's not been a priority so far. All in good time I guess but in the meantime I'd recommend looking at the examples that are provided and play around with embedding your own callable functions and perhaps even generating "t2dSceneObject"s from them so you can reference them (which is what was asked for above). These spawned objects are objects available using the normal functions they expose to the scripts.

I hope this provides a little insight and direction to where you should look. If anyone wants to play further with this then please just ask if you need more detail over and above the provided active-tile examples in the SDK.

Good Luck,

- Melv.
#5
12/29/2005 (2:46 pm)
Excelent write up melv. this goes a long way to help understanding what exactly the activeTiles are for.

i would suggest copying your write up into the docs somewhere?
#6
12/29/2005 (3:07 pm)
Oh don't say that word (documentation)!! I'm up to my ears in doco this Xmas!

If it's useful, perhaps someone might expand on it and put in on TDN. Some better "t2dActiveTile" examples are to come though. I gave myself some ideas just typing this. ;)

- Melv.
#7
12/30/2005 (5:04 am)
I agree with the way tiles are coded in T2D, but I really needed that extra degree of control that justified the creation of a stand alone tile grid using static sprites(using only scripting, no C++). Well, maybe I'm just too damn stuborn and wanted to code the thing my own way =D

Sebastiao
#8
12/30/2005 (5:25 am)
Well, I don't know what to say; what exactly is it that static-sprites give you that a static-tile doesn't?

- Melv.
#9
12/30/2005 (10:09 pm)
Sebastiao, a nice (if dirty) hack would be to use the (static) tiles, and then for any tile you need to do 'extra' stuff for, you .clearTile it and instantly create a staticsprite at the same coordinate

of course you'd have to adapt that scenario to your needs, but overall i think it's a valid hack
#10
02/19/2006 (7:20 pm)
Hi Melv,

I know you weren't asking me, but here's something:

The tile arrangement allows easy addressing for things that are grid-like and statically sized, but not being able to, for example, set blend color, on an arbitrary tile is limiting. Also, whenever you change the imagemap you lose flip (and given that probably other settings as well).

For example, I've got a hex map and want to be able to "hilight" arbitrary regions of hexes. The way I got hexes was to use a quad of tiles for a hex and take one graphic and flip it for correct orientation. The quad arrangement allows the offset for alternate hex rows.

I created a highlight layer in the map as a convenience. After all, I'm already using the same grid for everything else. To allow highlighting of multiple hexes you have to be able to hilight none, all, most or least of any given tile (a simple cell image holds the respective fills).

With an array of static sprites changing the frame doesn't lose the flip information, right? (I finally found enough information to know I can't use a tile layer for this and haven't coded it up yet.) Also, I can have different color blend for each tile. This could be used to give "warm to cold" transition, or a fade out for a plotted move.

It's possible that active tiles will do this, but there seems to be next to no documentation on them and I just don't have the time read through and decipher the source. Wish I did, but I don't.

It isn't that things can't be done other ways, but using the tile layers just seems such a natural fit.

Tim Doty