Tiles Offset

#1 What do you mean when you refer to "tile offset"? Panning?

- Melv

#2 No, Let's say I have a tile layer that is 200 units wide by 200 units high. Let's also say each tile on this tile map is 20 units wide by 40 units high. Now, when I place tiles the will be placed every 20 wide, 40 high right ? Is there any way to change this or will there be any way to change it in the future ?

#3 So you would have a 20x40 tile, but draw them into a 20x20 grid, thereby overlapping the tiles. What's the point in that? You'll never see the 20 units of tile that get overlapped, so you might as well make your tiles 20x20 to start with.

You mention perception benefits, but the only way that's going to work is if you have tiles on different layers and scroll them at different rates.

#4 By "really neat perception benefits" do you mean "walking in grass?" That's usually the effect that I think of when I think about tile offsets. Victor Putz' YakIcons was ubercool.

You could layer series of small tilemaps and control the layers to manipulate the same effect. Either that or have a tile-based particle effect that looks like the effect you want. While particles can be used for whiz-bang nifty effects, they can also be used for some extremely common practical things.

#5 It makes it a lot easier to do a topdown RPG style game if you could make the pillar layer "offset" (or grid size) smaller that the tile itself. That way you could have a pillar let's say that doesn't have the area of it's sprite fully filled.

The other thing you could do would be to say have an isometric tile that was 20 wide and 10 high. If you made the grid size 10 wide 5 high you could stagger the tiles. I'll use some crude ASCII here but let's say 1's are a 20 x 10 tile and 0's are no tile. In a 10 x 5 grid you could have the following:

1 0 1 0 1 0 1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1 0 1 0 1 0 1

This would basicly give you a semi-decent way of making a simplistic Isometric 2D game. And let's face it, if you want to start doing elevated area's and rolling ground and what not, you are better off going to 3D.

Does any of the above make sense or am I crazy ?

#6 I thought that was why there were layers to begin with. Maybe I'm just way off base, though.

#7 I agree with David, this is something easily solved by using proper layering.

#8 Alright then, let's have a little example. This is pretty crude but I think it convey's what I mean. We'll use some basic 2D Isometric style game. Let's say you have the following tiles:


Now using the current method I think you get the best/closest results if you split it into four / five layers. Basicly layers one and two would be your ground tiles:


While Layer 3 and 4 would be your Wall / Object tiles:


Now this works fine if your sprite is in front of the Walls like so:


But as soon as you get him behind the walls you get this:


If you try and get him on one of the object layers you can end up with some weirdo stuff like this:


Now let's say you tilemap can have a tile that is 20 x 20 units, but with a tile grid size of 10 x 10 units. Now if your ground layer was setup like this (With 1 being a tile at the grid position and 0 being a blank position):

1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1

Your ground layer would look like this:


And your object layer would look like this:


And using ordering and on the layer you could get a result like this:


Now is there any other way that I have missed to get the result you see above ? I have had a look at the tile code and the change I think would be in the fxTileMap2D.cc:

Adding two more parameters to this function to represent tileGridSizeX and tileGridSizeY

ConsoleMethod(fxTileMap2D, createTileLayer, S32, 3, 3, "(tileCountX / tileCountY / tileSizeX / tileSizeY) - Creates a Tile Layer.")

and in this function add the corresponding parameters

SimObjectId fxTileMap2D::createTileLayer( U32 tileCountX, U32 tileCountY, F32 tileSizeX, F32 tileSizeY )

Then you would need to go through the rest and search for the functions that add / remove tiles, load tile etc and change the functions that step through the tile grid using the tileSize parameter to use the tileGrid parameter. This isn't a huge change, but the only bad thing is if I implement it then the tile creator program basicly becomes unusable unless it's also changed (haven't looked at that yet though).

So does that make sense or am I jumping the gun ?

#9 I think if you can figure it out and make the relevant engine changes, then go for it. Isometric stuff has been mentioned a few times, and although it's on the to-do list, I think it's quite a way down.

It sounds like you know your way around C++, and if you do figure it out, I'm sure you'll have plenty of grateful people if you submit what's needed as a resource.

#10 Oh man, we totall just ran into the same problem trying to do "fake" Isometric.

If anyone else has any other insights on how to do this, we'd be glad to hear them. :)

#11 Changing tiles like that may run into more issues though, the save data may break your format, I know they were running into issues when updating the code so soon they're coming out with a new format that will pretty much break the old tilemap format.

You could always make a child class of it and attempt modifications, that way you have both.

In all honesty I see your point though I don't see why you can't get around this with clever art and ordering within a layer... A tile doesn't have to be a whole door, it can include part of the next door next to it, since that is all visual you can subdivide your sprites like that.

I'll admit I haven't gotten to the display aspects of my team's simulated isometric game, though I may attempt to do so sooner now

#12 I don't get it. In the first example (with the two layers per "layer"), why couldn't you stick the character sprite underneath both the wall layers? Wouldn't that serve the same purpose as what you're trying to do? Either way you'd need to fudge up a consistent way to keep the character properly occluded, no? Or am I missing the point entirely?

#13 If you do that then when the character is in front of the walls he will actully look like he is partially behind them. If all objects were kept on one layer you could use ordering properly to make the character sit the right way. Matt's suggestion of chopping up the art does provide a (what I consider) dirty solution. Until the new changes come in for the new file formats and what not I don't think I'll touch much of the code to try and dummy something up either.

#14 The wall-character overlap problems are pretty much a matter of z-ordering, which I have yet to figure out but need to come up with a system for, since an iso RTS pretty much demands it. I don't see how overlapping tiles would help too much with z-ordering...

#15 I think what Glenn originally said is the same problem as I now encountered if I understand it correctly. My levels consists of mainly of 4x2 tilesize sprites. But now I have several sprites of 12x2 and 12x4 size which I still want to position in a 4x2 tilesize grid and not on a 12x2 nor on a 12x4 grid which is too course for positioning. The only way now is (I think):

(a) to split all sprites into the size of the grid accuracy you need. And then proberbly mount the sprites so that act as one entity?
(b) use an additional data/levelfile which holds the positioning for all that the leveleditor cannot.

Or is there a better way to do this? Or did I miss something (noob in T2D)?

This also brings me to a more general remark that while most tutorials are excellent, it would be nice to have a document included which roughly outlines the whole setup and design decisions/philosphy of T2D (it is obviously not targeted at all kinds of 2D games atm).

#16 Quite interesting as the first thing I did when I got T2D was play aound with ways to get ISO tiles going.
I looked at several options and thought i was very bright to use two overlapping layers to create a 'virtual' layer.
I changed the editor code to allow offsetting a layer position either by a key press, entering into a dialog and
later linking two layers into a 'virtual' layer with an offset for the second layer.

I quickly ran into the same problems described here and thought it would be too unwieldly in the end.
I then scanned through the c++ code and hacked around a bit to see if there was a quick way to
just add custom offsets etc, but it impacts too many other places in the code and would take a lot
of work to propogate.

I then fell upon the idea of using a custom ActiveTile derived class which is not restricted on where
it can draw (as per docs). The basic idea is to have this tile draw 2 tiles instead of one, offsetting the
second as required (as well as providing overlap).

As I have not looked at it again I will keep you updated as to how it pans out once i get back to it.

As for your depth issues Glen, what about swapping the player between layers based on Y coord per
tile the player is on every time the player moves? Just a brain fart but i think it could be worth testing out.
Perhaps a virtual depth map for all tiles that specifies which layer something should be drawn based on an
x,y coord and "depth"?


regards
neo

#17 Ok so I caved in and tackled the issue of iso offsetting on a fxTileLayer2D and it was surprisingly easy.
It's about 5 lines of code change (just for the rendering that is) and it works like a charm.

I'll post a plan once I finish the stuff I'm busy with and share ;p

Just to be clear, it allows using one tile layer that knows how to offset tiles correctly.

But i suppose no one cares anymore ;p

~neo

#18 Sounds good Neo. I think especially for background graphics etc, this might be very handy and contribute to a less regid designed look. Did you also allow other tile sizes? And where did you store the data for the offset if I may ask?

- Edo

#19 Well I'm not using intra tile offsets, I'm basically simply stepping across the source tile positions as usual, but just offset the render
position. (default iso tile stepping)

So:
For every row you step Y by tileHeight / 2
And for every OTHER row you offset X by tileWidth / 2

e.g:

for( all visible tiles in Y )
{
    drawX = ( Y % 2 )  ? tileWidth / 2 : 0;

    for( all visible tiles in X )
    {
        draw tile sourceXY at position drawXY

        drawX += tileWidth;
    }

    drawY += tileHeight / 2; 
}

I derived a class from fxTileMap2D and another from fxTileLayer2D and just overrode fxTileMap::createTileLayer and
fxTileLayer2D::renderXXX() to keep things nice and clean, but this could be integrated quite easily and be generic.

Obviously I'll have to tackle things like pickTile() and anything to do with the layer in world coords.

Still a bit to do but I think it will be worth it to have a clean isometric interface that plays well with everything
else and still uses as much as possible from the underlying classes.

Obviously things like physics, etc are right out the door as the iso stuff basically runs in a psuedo 3D world, but
that's to be expected.

~neo

#20 A screenshot would go a long way here. :)