Doing 14x16 square tiles is possible

[psycopathicteen]

aspect ratio corrected tiles.png (1.41 KiB) Viewed 6076 times

You could pull off 14x16 tiles by overlapping 2 layers, and using 2 tile sets. As you can see in the picture above, there is a red layer and a green layer. Each tile comes in a pair, with a "right" side tile, and a "left" side tile.

[Bregalad]

And why in the world would you want to do this instead of 16x16 ?

[TOUKO]

And why in the world would you want to do this instead of 16x16 ?

Same here, i don't see the usefulness of that,except saying "you can" .

[FrankenGraphics]

Maybe to counter wide pixels?

[psycopathicteen]

Maybe to counter wide pixels?

Exactly.

[tepples]

That or if you're porting a block puzzle game designed for a platform without wide pixels, where 8x8 is too small and 16x16 is too big. Puyo Pop for Game Boy Advance uses 2 layers to display 12x12-pixel tiles, as does the homebrew Luminesweeper. Zoop for Super NES uses software rendering for 12x14-pixel tiles.

[TOUKO]

Maybe to counter wide pixels?

Exactly.

Ok, but is it not a bit overkill to sacrifice a layer for that ?

[JRoatch]

That's kind of a neat solution.
My first thought would of been to use mode 7 to scale the whole tilemap, but then there would be no other layers available.

[TOUKO]

With mode 7 you are also limited to 256 tiles .

[tepples]

With 2 tile sets at 14x16, you are still limited to 512 tiles, as you have to store each tile twice in video memory: once offset and once not offset. It's a bit better at (say) 12x12 or 12x14, where you can still use all 1024 tiles, though you're still limited to one 2bpp parallax layer in mode 1.

[93143]

Wouldn't you need more than two sets? If you plan to cover a scanline in 7-pixel slivers, packing two 14-pixel metaslivers together lands you halfway through the fourth underlying 8-pixel sliver, so you'd need to do it again (but with three real slivers per metasliver this time) to get back into alignment.

Have I missed something?

[tepples]

The tiles would be paired. You'd have one copy of a pair of tiles occupying pixels 0-13 of a pair and a shifted copy of the same pair of tiles occupying pixels 2-15. Then you'd write the tiles to the map in the following order:

2-15 version of tile at position 0
0-13 version of tile at position 1
(3 blank columns)
2-15 version of tile at position 4
0-13 version of tile at position 5
(3 blank columns)
2-15 version of tile at position 8
0-13 version of tile at position 9
(3 blank columns)

Then in the other map, whose scroll is offset by 28 pixels, you'd write

2-15 version of tile at position 2
0-13 version of tile at position 3
(3 blank columns)
2-15 version of tile at position 6
0-13 version of tile at position 7
(3 blank columns)
2-15 version of tile at position 10
0-13 version of tile at position 11
(3 blank columns)

The 2-15 and 0-13 tiles together make 28 consecutive pixels. The two transparent pixels at the right side of a 0-13 pair, three blank tile columns, and the two transparent pixels at the left side of the next 2-15 pair together also make 28 consecutive transparent pixels.

[93143]

I think I see that now. I shouldn't have posted; I've been using my brain at pretty much full throttle for the last two weeks and it's worn out. Must sleep...

[psycopathicteen]

I'll attempt to write some code for calculating coordinates.

Code: Select all

lda {x_velocity}
clc
adc {bg1x}
sta {bg1x}
clc
adc #$0004
sta {bg2x}

lda {x_velocity}
clc
adc {fine_scroll}
bpl +
adc #$000e
dec {tile_number}
+;
cmp #$000e
bcc +
sbc #$000e
inc {tile_number}
+;
sta {fine_scroll}