Attachment:
aspect ratio corrected tiles.png [ 1.41 KiB | Viewed 4067 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.
And why in the world would you want to do this instead of 16x16 ?
Bregalad wrote:
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" .
Maybe to counter wide pixels?
FrankenGraphics wrote:
Maybe to counter wide pixels?
Exactly.
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.
psycopathicteen wrote:
FrankenGraphics wrote:
Maybe to counter wide pixels?
Exactly.
Ok, but is it not a bit overkill to sacrifice a layer for that ?
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.
With mode 7 you are also limited to 256 tiles .
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.
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?
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.
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...
I'll attempt to write some code for calculating coordinates.
Code:
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}