Some questions about Saturn HW

For hardware talk only (please avoid ROM dumper stuff)
danibus
Newbie
Posts: 4
Joined: Sat Feb 03, 2018 12:41 pm

Re: Some questions about Saturn HW

Post by danibus » Tue May 01, 2018 9:41 pm

Huge wrote:
Sat Apr 21, 2018 10:06 pm
The 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.
Hi there!

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
https://www.youtube.com/watch?v=WDJgeuoaSvQ

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.

User avatar
Sik
Very interested
Posts: 673
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Some questions about Saturn HW

Post by Sik » Tue May 01, 2018 10:14 pm

I mean, if the polygon is smaller than the texture then it'll inherently skip texels.

What happens though is precisely that when it should skip a texel (because of shrinking), what it does is read the texel from VRAM anyway but then does nothing with it. That results in a waste of time and hence VDP1 being slower than it could have been.

Actually... if the VDP1 is shrinking a texture, and there are transparent and opaque texels "overlapping" in a given place, does the opaque texel always get drawn? (i.e. does it write to the same pixel on the framebuffer multiple times within a line?)
Sik is pronounced as "seek", not as "sick".

User avatar
Huge
Very interested
Posts: 178
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Tue May 01, 2018 10:17 pm

danibus wrote:
Tue May 01, 2018 9:41 pm
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
https://www.youtube.com/watch?v=WDJgeuoaSvQ
The part in the gamerhut video is UV texturing. That one has the system processing a polygon first, and then stretching a texture onto the polygon. So for example you can keep the polygon in position but move the texture. The Saturn doesn't have that; texture and polygon is one and the same.

And because of that, it wastes time sampling the texture even when it doesn't get drawn.

For example on Saturn if you have a texture like
abcd
abcd
abcd
abcd

4x4 = 16 bytes size

and you draw it at half size, you get this on your screen:
ac
ac

2x2 = 4 bytes size

but the VDP1 still reads all "abcd" rows, so 16 bytes, it just doesn't draw half the pixels in the end.

Of course you can draw single coloured or single color + gouraud shaded polygons, those are much faster as there is no texture to sample.

User avatar
Huge
Very interested
Posts: 178
Joined: Sat Dec 13, 2008 11:50 pm

Re: Some questions about Saturn HW

Post by Huge » Tue May 01, 2018 10:30 pm

Sik wrote:
Tue May 01, 2018 10:14 pm
Actually... if the VDP1 is shrinking a texture, and there are transparent and opaque texels "overlapping" in a given place, does the opaque texel always get drawn? (i.e. does it write to the same pixel on the framebuffer multiple times within a line?)
I think it is different in each mode.
With Scaled sprites it will definitely skip writing unnecessary pixels. But it may write the sidemost pixels twice for some reason if the part of the sprite is off screen.
With Distorted sprites it looks like it writes the unnecessary pixels, both within a line and when lines overlap each other.
With non-textured filled polygons, it only writes unnecessary pixels when lines overlap, but not within the same line.

I'm basing these observations on how VDP1 semitransparent polygons look in games, mind you.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest