Hi there!Huge wrote: ↑Sat Apr 21, 2018 10:06 pmThe Saturn works "backwards". It samples every pixel of the texture and determines whether it needs to be written to framebuffer or not. So if you have a 64x64 texture but only write 32x32 of it, then you waste a fourth of your fillrate checking texture pixels that don't end up being drawn. There are some mitigating factors like texture end codes that can be used to reduce the amount of pixels sampled, but it's still bloody stupid either way.
One thing to note though is that while it samples every pixel of the texture, it doesn't write multiple values per line to the framebuffer. So you don't actually get pixels written multiple times (in one line, anyway); the speed is wasted when reading the texture. When you DO get overwrites, is when lines intersect, ie. when the polygon is not a perfect square (4-point transformations, the manual calls these "Distorted Sprites").
I don't know if you get overdrawn pixels when you draw a poly where the right side is larger.... logic would dictate that you get dropouts here, but the VDP1 does some aliasing to get around this, but I don't know how.
Talking about polygon+texture, non-regular polygon, not a perfect square
When reading doc and forums, I understand VDP1 will adapt texture to polygon. It polygon is 32x32 and texture 64x64, I understand will shrink texture to 32x32 and then change shape to adapt to polygon shape.
But you wrote that will "show only 32x32 and then waste time checking pixels that don't end up being draw" (?), then part of texture is not showed (??)
I think is not possible just select which part of texture to show, this is what GameHut said in this video
That takes me to endcodes, I read doc again (no! I just saw figures as Chilly Willy told me XD ).
I understand we can avoid showing parts of texture using textures, making this pixels 100% transparent and "jumping" in sampling, faster in some way , but again, VDP1 follows until the end of texture, so no part of texture to select, just all texture.