#22182 - Marill - Mon Jun 14, 2004 11:22 am
A iso tile is about 2:1 ratio, that is 16x8 (width x height).
But in the GBA bkgs, they work all on 1:1 (8x8) square ratios.
imagine the tile 16x8 will look something like this
<>
so I use a 8x8 tile to store < and another 8x8 tile to store >, assign them side by side in teh bkg tile map and it will turn out nicely <>
The problem is that if I use such a scheme and tile the entire background, there will be gaps inbetween 2 isotiles.
Below, is an example of 4 16x8 isotiles stacked, 2x2: (topleft, topright, bottomleft, bottomright)
<><>
<><>
the gaps will be at the corners and right in the middle of the 2x2 pattern.
Therefore I am unable to tile the isotiles using 2 8x8 tiles to represent 1 isofile of 16x8.
One solution I can think of is using 2 background layers. The second background layer fills in the gaps in the 1st layer and then this second background layer is offset by +4+4 right into the middle where the gap should be in teh 2x2 isotile pattern.
This seems like an awful waste of space, but that's what I am thinking for the solution.
Is there anyone who has a much better solution to handle isotiles tiling on the GBA background layers which are square?
Main gist of the problem: isotiles aspect ratio is 2:1, GBA background tile is 1:1. This created gaps in between when tiling a 2x2 isotile pattern, how does one solve this problem?
Thanks in advancem, anyone! :)
#22183 - keldon - Mon Jun 14, 2004 11:39 am
Use mode 7 scrolling, rotation and scaling; or just draw a map that is isometric :-/
#22190 - sgeos - Mon Jun 14, 2004 2:19 pm
Getting a copy of Tactics Ogre (Advanced) and look at the tiles/layers/map setup really is the easiest way to figure this out.
You need two layers, a bottom BG layer and an overlay. Trees, rocks, or anything else that the player can walk behind go in the overlay layer (includes grid cells that stick up in front of the units).
The tiles have to be created so that they can be tiled in the BG layer. You could create "pieces" of tiles and put those together either at runtime or using a PC side tool. (1/4 a water tile that you add to 1/4 of a grass tile and 1/4 of a dirt tile and 1/4 of another water tile, etc.)
A few base tiles will turn into many after they have been combined. Tactics Ogre has tons of space to in VRAM, so I wouldn't worry about running out of space- only load the tiles you need for any given stage int VRAM!
I recommend using isometric tiles that fit in a 32w by 16h bounding box. If you insist on using half of that ratio (16w by 8h) then you will need to design tiles with the middle filled in. I figure that that is ... a lot of extra tiles and makes things really complicated. There are parts of three grid cells on *each tile* in VRAM. Good luck!
-Brendan
#22203 - sajiimori - Mon Jun 14, 2004 5:51 pm
| Quote: |
If you insist on using half of that ratio (16w by 8h) then you will need to design tiles with the middle filled in. I figure that that is ... a lot of extra tiles and makes things really complicated.
|
I don't know what you mean by 'with the middle filled in', but I would expect the total number of tiles to be fewer when using units of 16x8. The reason is that there would only be two isometric tiles visible in each rectangular tile, instead of four.
So if N different surfaces are to have transitions to each other, there would be N^4 32x16 tiles, or N^2 16x8 tiles.
#22222 - sgeos - Tue Jun 15, 2004 12:54 am
| sajiimori wrote: |
| I don't know what you mean by 'with the middle filled in', |
Looks like I can't slack on my explanation afterall. =P
| sajiimori wrote: |
| but I would expect the total number of tiles to be fewer when using units of 16x8. |
If I understand whay you are saying, I agree. Given a 32 by 16 iso-grid unit, it can be split into four 16 by 8 units. Each one of "quarter" can be used for a different tile transition.
| Quote: |
The reason is that there would only be two isometric tiles visible in each rectangular tile, instead of four.
So if N different surfaces are to have transitions to each other, there would be N^4 32x16 tiles, or N^2 16x8 tiles. |
How did you arrive at these figures? If I read the original post correctly, he is using 16x8 isometric metatiles that look something like this:
| Code: |
+ - - - - - - + + - - - - - - +
| B _ / - | | - \ _ D |
| _ / | | \ _ |
|_/ | | \_|
| \ _ A | | A _ / |
| \ _ | | _ / |
| C \ _ | | _ / E |
+ - - - - - - + + - - - - - - + |
Dealing with this scheme is much simpler:
| Code: |
+ - - - - - - + + - - - - - - + + - - - - - - + + - - - - - - +
| | | B _ / | | \ _ D | | |
| B | | _ / | | \ _ | | D |
| | | _ / | | \ _ | | |
| _ / | | | | | | \ _ |
| _ / | | A | | A | | \ _ |
| _ / A | | | | | | A \ _ |
+ - - - - - - + + - - - - - - + + - - - - - - + + - - - - - - +
+ - - - - - - + + - - - - - - + + - - - - - - + + - - - - - - +
| - \ _ A | | | | | | A _ / - |
| \ _ | | A | | A | | _ / |
| \ | | _ | | _ | | / |
| | | \ _ | | _ / | | |
| C | | \ _ | | _ / | | E |
| | | C \ | | / E | | |
+ - - - - - - + + - - - - - - + + - - - - - - + + - - - - - - + |
T is the number of tiles. If one wants to be able to have transparent "nothing" spaces, then N (the number of transitions) is equal to T + 1. (Otherwise N == T). If you plan on using transparent tiles, you might want to replace N below, with (T + 1) to make things simpler.
The map will be put together with 8 by 8 tiles, so the exponent is determined by the number of separate isotile regions on a GBA tile. The first 16x8 GBA tile contains regions A, B and C. The first 32x16 GBA tile only contains regions A and B.
One will need N^3 16x8 isotiles or N^2 32x16 isotiles. One breaks even at a single transition, after which one needs more 16x8 isotiles. (Break even at zero tiles with transparency.)
The 16x8 scheme requires 2 * N^3 GBA tiles, while the 32x16 scheme requires 8 * N^2 GBA tiles. VRAM usage breaks even at 4 transitions, after which one needs less GBA tiles using the 32x16 scheme.(Break even at three tiles with transparency.)
-Brendan
#22224 - sajiimori - Tue Jun 15, 2004 1:50 am
My figures were based on treating the second diagram of your last post as a single 32x16 tile versus four 16x8 tiles. When you suggested using larger tiles, I misinterpreted that as a suggestion to use tiles that include more transitions, rather than fewer. Now it seems we're on the same page.
#22225 - Marill - Tue Jun 15, 2004 3:01 am
Hey, thanks for hte explanation!
Mind if I borrow sgeos great diagrams?
| Code: |
+ - - - - - - + + - - - - - - +
| B _ / - | | - \ _ D |
| _ / | | \ _ |
|_/ | | \_|
| \ _ A | | A _ / |
| \ _ | | _ / |
| C \ _ | | _ / E |
+ - - - - - - + + - - - - - - +
|
Basically in the regions of B, C, D, E the idea is that I do not make them transparent? Instead, fill them up with the other backgrounds?
I have been thinking of this method too, sgeos, but I didn't really expand on it coz I'm having some issues with it, mainly this method will not scale well for a complex scene. This will mean an explosion of combinations and it gets difficult to manage, both art-wise and program wise.
For example I have a road, grass and sand.
if A is road, and take one 8x8 tile for example,
I'll need to create the tiles
A - road, B - grass, C - grass
A - road, B - sand, C - sand
A - grass, B - road, C - road
A - grass, B - sand, C - sand
A - sand, B - grass, C - grass
A - sand, B - road, C - road
flip it over and create 6 more, for a total of 12 combinations.
In a typical game, you've got road, buildings 1-x, grass, forest, sand, river, sea, etc etc, this will be too many and too complicated to handle.
"Tactics Ogre has tons of space in the VRAM" - hmmm I don't understand this, do you mean that GBA hardware VRAM? coz if the scene gets complicated, such an explosion of tiles may eat up the tile space in the GBA pretty fast.
The issues with this method are
(1) Because there is an explosion in combinations of tiles in a complex scene (it doesn't scale well with scene complexity), it takes up lots of space.
(2) It gets difficult to manage the combinations and alignment, program wise.
(3) It also gets difficult to manage such a huge number of tiles during the art creation.
Is there a method that will scale well with scene complexity? I am still thinking of keeping just the A area and B, C, D, E transparent, hopefully, and creating some transistion boundary areas (still with transparency).
PC games can get away with this simply because there is no 8x8 tile hardware specification to conform to. They could just always offset +4+8 and blit the next tile there to fill in the gap in the middle.
For the GBA, because there's the 8x8 tile hardware spec to conform to, it creates this problem and it's giving me headaches :)
thanks in advance!
#22226 - sajiimori - Tue Jun 15, 2004 3:46 am
Use sgeos's second diagram where each rectangular tile only contains a single transition. Then, like we said, if N=number of surface types then there will be at most N^2 different kinds of transitions (which is what you would have even if you weren't using rectangular tiles), and a maximum of N^2*4 tiles total.
If each tile is 2 bg chars wide (16x8 pixels), then that's N^2*8 total bg chars, so 1024 bg chars is enough space for 11 surface types (11*11*8=968). That seems like a pretty good number, and there could be more if you don't need every possible transition (which is often the case).
#22227 - Marill - Tue Jun 15, 2004 3:57 am
thanks, this means that well the RAM space is enough,
but the problem of complexity management because of the combinations for tracking in the game and the art creation is still there... i'll probably have to find other ways to get around that.
#22229 - Miked0801 - Tue Jun 15, 2004 4:16 am
Divide it across 2 layers. Have one half on 1 layer and the other on the other leaving the other half transparent. With flipping, you could reduce your char requirements down to almost nothing :)
#22232 - sajiimori - Tue Jun 15, 2004 6:27 am
I would think the main benefit of using 2 layers is ease of implementation. Unless your tiles tend to have very sharp seams, you won't save many tiles because transitions have to be drawn anyway. Of course, the main cost is a layer.
Managing complexity is always tough. Try to move as much code as possible out of the game itself, and into seperate tools. Then you can mostly forget about efficiency and being proper, and focus on formatting your data in the most convenient way possible.
Creating art shouldn't be different regardless of how you divide up the tiles. Draw in the way that's easiest and best looking, and write tools to rearrange your art to meet techincal requirements. Then you won't lose your art if you change your requirements.
Use a precise naming scheme that describes each tile. It should specify which surface is on the top, which is on the bottom, and whether the transition slopes to the left or the right (e.g. water_sand_r). Make a 3D array, with 1 dimension for the top surface type, 1 for the bottom surface type, and 1 for the slope direction. It holds pointers to the pixel data, so that you can put a null pointer for transitions that don't exist instead of wasting space.
| Code: |
enum
{
SURF_SAND,
SURF_WATER,
...
NUM_SURFACES
};
typedef u16 Tile[BYTES_PER_TILE];
const Tile* tile_matrix[NUM_SURFACES][NUM_SURFACES][2] =
{
...
};
const Tile tile_graphics[] = { ... }; |
So the goal of your tools is to convert from whichever way you felt like drawing your graphics, to the data that fills these arrays.
#22233 - sgeos - Tue Jun 15, 2004 8:05 am
I put a picture page together. It has some images of the tiles and maps. There is also a template for tiles that use the same geometry, and a couple of images made with the template.
| sajiimori wrote: |
| If each tile is 2 bg chars wide (16x8 pixels), then that's N^2*8 total bg chars, so 1024 bg chars is enough space for 11 surface types (11*11*8=968). That seems like a pretty good number, and there could be more if you don't need every possible transition (which is often the case). |
Transparent nothing transitions, plus 2 or 3 wall transitions, plus 7 or 8 floor transitions really does sound like enough for a single map to me. That leaves 56 tiles for pure overlay decoration. 56 / 8 = 7 overlay decorations if they do not exceed the standard 32x16 bounding box. (I could see "tall" trees being 32x32.)
My main objection to using two BG layers is that that is really two BG layers plus any needed for overlay, plus any needed to display other information (HUD, in game status, etc). One can get by with two BG layers for the whole map (an under-layer and over-layer) if transitional tiles are used.
Tranitional tiles really want to be 32x16 pixels. If for whatever reason is heavily invested in 16 by 8 tiles, using two BG layers for the underlayer or a bitmapped graphics mode is probably the best bet.
As far as shading goes, I don't think that most transitional tiles want to flipped. That is in my personal lego world, though. Your vision may vary. Using two BG layers makes flipping really easy. If one intends to do flat maps (no stacked lego block stuff), then two BG layers makes just about everything really easy.
-Brendan
#22234 - Marill - Tue Jun 15, 2004 10:41 am
sgeos, thanks so much it really explains it very clearly!
from the VRAM, it looks like the sprites have 2 frames of animations each? (i haven't played the game for sometime so I can' remember)
#22238 - sgeos - Tue Jun 15, 2004 12:29 pm
| Marill wrote: |
| from the VRAM, it looks like the sprites have 2 frames of animations each? (i haven't played the game for sometime so I can' remember) |
It looks like each sprite has a walking animation up at the top. Enough VRAM is set aside for a large creature. There are 3 griffons that take up "double" space. These must be overwritten every frame. (I put 8 units on the map, and it looks like there are 8 NPCs as well- 7 enemies and one guest.) Even if units have the same class, they get a unique spot in VRAM. This way each unit can be facing a different direction or be on a different frame and there is enough space to fit 16 unique units.
Next we have generic icons. You are facing this way icon, help icon, animated treasure bag, numbers for damage, etc. It looks like special attack animations are loaded at the end of VRAM.
I started the stage. Deployed units. NPC retreated. Moved and attacked with ninja. Moved and attacked with archer and paused the emulator when the arrow was in the air.
Most of the archer's animation have overwritten the ninja's, but you can see the ninja "jumping" at the end. At the very end of VRAM, I think we have the shriken barrage. Not sure. I can't find the archer's arrow.
-Brendan
#22239 - Lord Graga - Tue Jun 15, 2004 1:04 pm
I remember seeing a indepth look at how Final Fantasy Tactics did it over at Pixelation. Sadly it's not there any more :/
#22309 - Marill - Thu Jun 17, 2004 11:59 am
reading through the threads, I found another great explanation although not the pixelation.
http://forum.gbadev.org/viewtopic.php?t=2304
#23137 - wintermute - Mon Jul 05, 2004 11:17 am