11-23-2022, 08:01 PM
Hi!
Good job with your drawing primitives :-)
Yes you're right, warping on cornes requires 4 sprites as the actor appears on all corners at once.
I haven't planned use for the remaining bits in tile descriptor. Traditional flags are already implemented -flipping bits, palette and graphic index-, plus the exclusive tileset index and 90º rotation flag that weren't present in any 2D chipset.
Color math (or "blending") is already much more capable in Tilengine than it was in Super Nintendo. The SNES has 4 modes, but only one mode can be globally selected that affects all layers and objects that have blending enabled. Tilengine has 7 modes, where one of them is an user-provided function for custom math effects. Each layer and sprite has its own mode selected.
Adding per-tile blending mode is not planned, but it could be possible. For performance reasons it should be excluded from affine and pixel-mapped modes. Recent per-tile palette feature is also disabled in these modes, as enabling it on these modes causes a 6% performance hit. Another problem with these modes is that they use an intermediate line buffer that is blended after the main pass using the layer's blend function. Doing per-pixel blend function on the fly would cause severe performance loss. Normal modes where the scanlines of source bitmap are parallel to target scanlines are relatively cheap to render because rendering attributes (source graphic, palette, inversion flags, blending...) are determined per source scanline, not per pixel. So pixels on each source batch are cheap to spit out. However, affine and pixel mapped modes require setting attributes for every single pixel. So the simpler the inner loop, the better.
Good job with your drawing primitives :-)
Yes you're right, warping on cornes requires 4 sprites as the actor appears on all corners at once.
I haven't planned use for the remaining bits in tile descriptor. Traditional flags are already implemented -flipping bits, palette and graphic index-, plus the exclusive tileset index and 90º rotation flag that weren't present in any 2D chipset.
Color math (or "blending") is already much more capable in Tilengine than it was in Super Nintendo. The SNES has 4 modes, but only one mode can be globally selected that affects all layers and objects that have blending enabled. Tilengine has 7 modes, where one of them is an user-provided function for custom math effects. Each layer and sprite has its own mode selected.
Adding per-tile blending mode is not planned, but it could be possible. For performance reasons it should be excluded from affine and pixel-mapped modes. Recent per-tile palette feature is also disabled in these modes, as enabling it on these modes causes a 6% performance hit. Another problem with these modes is that they use an intermediate line buffer that is blended after the main pass using the layer's blend function. Doing per-pixel blend function on the fly would cause severe performance loss. Normal modes where the scanlines of source bitmap are parallel to target scanlines are relatively cheap to render because rendering attributes (source graphic, palette, inversion flags, blending...) are determined per source scanline, not per pixel. So pixels on each source batch are cheap to spit out. However, affine and pixel mapped modes require setting attributes for every single pixel. So the simpler the inner loop, the better.