Jo Engine Forum

Sega Saturn Development => General discussion about the Sega Saturn => Topic started by: 20EnderDude20 on August 13, 2018, 02:48:59 am

Title: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 13, 2018, 02:48:59 am
I've made a demonstration of circular transparent shading by not using perspective distortion, and instead, use affine transformation and it looks fine: (https://imgur.com/nWa7aWc.png) Now, would the shadow be corrupted by having overdraw if I skewed it, in other words, kept the coordinates parallel with each other?
Title: Re: Circular Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 13, 2018, 08:47:01 pm
Okay, so there is a solution to the perspective distortion with rectangular shadows. What you do is that you make a 16-frame animation of a square moving two points together. You would then use the palette swap trick to compress it to one texture, and you would use affine transformations for the rest. Observe: (https://i.imgur.com/w5RggEn.gif).
Title: Re: Circular Transparent Shading on The Saturn
Post by: corvusd on August 13, 2018, 10:57:01 pm
Very good ideas! Are you think about How make the change of shape when the camera rotate above the shadow?
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 13, 2018, 11:02:49 pm
Yes. The frame number of the texture depends on the view that you're looking at it from. Since it's 16 frames long, it should change about every 5 degrees within 90 degrees. When it's 0, it should be at the frame with the triangle, if it's 90, it's square. If you go above 90 degrees, you flip the texture, and the same applies there. I'm not a coder, but I can animate in Flash, so I might ask XL2 to implement a system like this, if he has time  ;). Here is a much more impressive-looking gif: (https://i.imgur.com/4po4cZS.gif)
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 15, 2018, 11:06:16 pm
Wait, if the ps1 used affine texture mapping for everything 3d, and if the shadow looks the same even with the warping, why didn't any developers program shadow polygons to turn off perspective correction (calculating q value, tessellation, etc.) on the Saturn?
Title: Re: Transparent Shading on The Saturn
Post by: ponut64 on August 16, 2018, 01:26:48 am
There are a few possibilities.

- They did not conceptualize the shadows as polygons, whether or not they actually were.

- Development for the system never got to the point where such a thing was conceived (remember, it was premier on the market for far less time than the PS1 and N64)

- Developers of the period hadn't a grasp of perspective correction well enough to understand that any method short of absolutely correct perspective correction has its applications compared to other methods. In other words, the Saturn doesn't have to use affine texture mapping, and the PS1 is worse for it, so the thought would be counter-intuitive.

- Developers were concerned with contextual overdraw, wherein interrupting the Saturn's perspective correction meant a part of the entire polygon pipeline, which could have drastic effects on the numbers of polygon's rendered if anything went wrong. (Most critically, because the texture warping on the Saturn is more or less because non-visible vertices are no longer calculated)

- Most likely, some developers of the time actually did do this, and we just don't know.
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 16, 2018, 09:55:04 am
To understand the problem of transparencies and the redrawing in SS. We have to dig deeper into our technical knowledge of the SS graphic pipeline.

Tessellate a Quad will not help in reducing overdraw or redrawing of pixels in the H-T VDP1.

In addition to using the VDP1 H-T (No Gouraud + H-T) has other problems added:
- If the quad is very deformed it will take up to 6 (According to documentation) drawing cycles.
- Ideally if It do not redraw any pixel, up to 2 cycles (This is a speculation on my part, being in essence the same as Gouraud.).
- Restriction of color types to work well within VDP1.
- It will never see the VDP2.
- Simple to program.
- Infinity blend layers.
- 1 Level transparency. 50% blend.

In other hand, if we use the transparency of VDP2 with sprites of the VDP1:
- It will not have redrawing problem.
- It does it in a cycle.
- Restriction of color types to work well within VDP2.
- It will not ever see the VDP1.
- More complicated to program.
- Up to 2 blend layers. 1 real transparency, other MSB Shadow function whit a lot of restrictions. Finally 1 effective transparency layers.
- Up to 32 levels of transparency.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 16, 2018, 04:01:28 pm
But a shadow’s just one color, so it shouldn’t matter that much
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 16, 2018, 04:17:45 pm
But a shadow’s just one color, so it shouldn’t matter that much

Of course it matters. 1 color or 32,000 colors not is the important. The issue is in how those colors are painted by the VDP1. Think about that deeply a time, you will see how it is not so simple.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 16, 2018, 04:29:03 pm
I know, I’ve seen perspective corrected sprites have a kind of moire pattern, but maybe that is a desirable result for some things, like for dust.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 16, 2018, 05:29:39 pm
Another thing to do would be to make the shadow out of rows of squares, like the fm towns marty’s “3d” sphere, and let the further sprites be smaller to make a rough resemablance of perspective distortion.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 16, 2018, 06:09:46 pm
What if we just ask an sh-2 to make a distorted version of the shadow to be displayed as a sprite with affine transformation?
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 16, 2018, 07:03:01 pm
What if we just ask an sh-2 to make a distorted version of the shadow to be displayed as a sprite with affine transformation?

Everything is possible. But are you aware of the programming implications they have? Time, effort and knowledge. Right now we are in an early moment of homebrew for SS. With public official SDKs or Jo-engine all these things that you pose are far away.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 16, 2018, 07:30:54 pm
But now we have more efficient compilers, letting all of these great ideas become more possible, and worth the while, to break the rumor that the SS can't do transparency. ;) Now that we know that transparent shading is possible, let's sit back and wait a couple of weeks for sonic z-treme to be released, to get the movement of hombrews for the saturn. Oh, what a time to be alive!
Title: Re: Transparent Shading on The Saturn
Post by: Jorhlok on August 17, 2018, 04:31:49 am
You mentioned the fm towns marty 3D sphere which gave me an idea but then I looked it up on youtube and it was nothing like my idea.

The idea is to use a normal VDP2 layer with small premade tiles and a CPU can decide how to composite the tiles to recreate what looks like any shadows.


The VDP1 draws arbitrary lines from the left line to the right using a greedy algorithm which causes pixels to be overdrawn. This avoids PS1-like gaps but causes the moire pattern with transparency. The other thing that causes the moire pattern was demonstrated well in one of Jon Burton's Sonic R videos. So unless each line is perfectly vertical or horizontal it'll overdraw causing transparency to be bollocks. This applies to skewed and rotated quads, not just perspective corrected quads.


One of the things you might have heard is that CRTs and composite video blurs the dithering enough to be a convincing shadow just drawing a dithered black oval over the ground. I didn't understand just how effective this was until I saw this composite capture of Z-treme on youtube: https://youtu.be/x7cW9wgIW00?t=50
Anyways you can tell how, back in the day, a team on a deadline scraping for ounces of power on a not quite adequate for 3D system would just draw an oval and be done with it.

I think one of the major issues with performance is that we're using an incredibly old jack-of-all-trades graphics library instead of tightly focused custom routines. Unlike a more straightforward graphics system, the saturn's really hard to write efficient graphic routines or even wrap your head around especially the memory scheduling. If two chips try to access the same memory chip in the same cycle, one of them will be halted until it gets access. This can basically throw away many cycles of work the saturn would otherwise be able to accomplish.

Anyways we got some interesting ideas floating around.
Title: Re: Transparent Shading on The Saturn
Post by: ponut64 on August 17, 2018, 05:32:52 am
You mentioned the fm towns marty 3D sphere which gave me an idea but then I looked it up on youtube and it was nothing like my idea.

The idea is to use a normal VDP2 layer with small premade tiles and a CPU can decide how to composite the tiles to recreate what looks like any shadows.


The VDP1 draws arbitrary lines from the left line to the right using a greedy algorithm which causes pixels to be overdrawn. This avoids PS1-like gaps but causes the moire pattern with transparency. The other thing that causes the moire pattern was demonstrated well in one of Jon Burton's Sonic R videos. So unless each line is perfectly vertical or horizontal it'll overdraw causing transparency to be bollocks. This applies to skewed and rotated quads, not just perspective corrected quads.


One of the things you might have heard is that CRTs and composite video blurs the dithering enough to be a convincing shadow just drawing a dithered black oval over the ground. I didn't understand just how effective this was until I saw this composite capture of Z-treme on youtube: https://youtu.be/x7cW9wgIW00?t=50
Anyways you can tell how, back in the day, a team on a deadline scraping for ounces of power on a not quite adequate for 3D system would just draw an oval and be done with it.


I think one of the major issues with performance is that we're using an incredibly old jack-of-all-trades graphics library instead of tightly focused custom routines. Unlike a more straightforward graphics system, the saturn's really hard to write efficient graphic routines or even wrap your head around especially the memory scheduling. If two chips try to access the same memory chip in the same cycle, one of them will be halted until it gets access. This can basically throw away many cycles of work the saturn would otherwise be able to accomplish.

Anyways we got some interesting ideas floating around.

I can't blame anyone for being oblivious to this if you hadn't actually played on real Saturn hardware, but:

- The Saturn's AV / composite / yellow cable video signal is among the best (as far as that type is concerned).
- And yes, 100%, the typical transparency effect of blanking out half the pixels works pretty much flawlessly over this signal type. As far as I am concerned, the Saturn is meant to be used this way, and it would be nice if emulators included an image filter for it.
- S-Video, the near-neighbor display type to AV/yellow plug, is also good on the Saturn - in fact it's pretty much pixel perfect, which means the transparency effect is no longer convincing.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 17, 2018, 05:56:21 am
What's better, dithering, or over-transparency? In my opinion, I would choose something that is real vdp1 transparency, and not the same screen door method that's been used since the genesis. The designers never had the intention of the output being precise, but with s-video, I would rather stick to real transparency, simply because it gives the Saturn a chance of having transparency. Oh, yeah, and I think the n64 can only do 50% transparency because mario in sm64 uses dithering when using a secret warp, so we shouldn't get too ahead of ourselves.
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 17, 2018, 09:46:03 am
What's better, dithering, or over-transparency? In my opinion, I would choose something that is real vdp1 transparency, and not the same screen door method that's been used since the genesis. The designers never had the intention of the output being precise, but with s-video, I would rather stick to real transparency, simply because it gives the Saturn a chance of having transparency. Oh, yeah, and I think the n64 can only do 50% transparency because mario in sm64 uses dithering when using a secret warp, so we shouldn't get too ahead of ourselves.

N64 have REAL Alpha Blending. Is a patent of Silicon Graphics. PSX and SS not have Alpha blending, it is wired half-transparency. In its documentation says it clearly all this stuff. We not invent theories or data... already they lied enough in the past: History of millions of polygons on screen at 60 FPS. We stick to the technical data, clearly documented. Please.

Half-transparency is REAL and totally useful in SS. The key is archive the best way to use it without caveats: No Redraw, in 3D primitives and OK blend in all pipeline(VDP1+VDP2).

Example to start whit real approach: Burning Rangers.

In my Table analysis we have at 65 titles whit VDP1 CC half-transparent use. We can research all advantages and disadvantages in each case(geometry, layer, quantity, area pixels, type of color and pool VRAM, size texture, color calculation use it...), and get right conclusion about the objective. In the same way are other column to analysis of VDP2 semi-transparency... Feel free to make research and share! :)
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 17, 2018, 11:00:35 am
I agree with Corvusd.
It's easy to come up with ideas, but it seems nobody else ever actualy try to write the code themselves.
I've got ideas myself for more transparency (even if my game is filled with vdp2 transparency), but until it's written it's not worth much.
Like if you use vdp2 for sprite over sprite transparency, how do you solve the priorities?
It's super complicated, but most people don't think about these.
Like sure, I can use the NBG0 as a framebuffer, but then all my other sprites need to have the correct priority.
Even Burning Rangers struggled with it, and it was made by one of Sega's best studio.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 17, 2018, 03:55:02 pm
But yet again, that 16-frame system might work. You just need the value of the angle of the camera, and you’re pretty much good to go.
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 18, 2018, 07:14:01 pm
It's not about if you can find the proper angle. You would need that only for square objects, so probably only for the world objects or maybe some platforms. Each pixel takes 6 times the time it takes to draw a normal pixel. It doesn't make sense to have slowdowns for such a small details. And you increase cpu calculations as well. You could just use a msb  distorted sprite if you framebuffer is palette only, you could just precalculate that shadow and use palette swaps to create a shadow (which is what I do) or use another vdp1 color calculation function (like gouraud or half luminance). There are reasons why very few games used half transparency, and it's because of both the bug and the slowdown.
The mesh effect looked ok on crt with composite, which is what people used back then, so it just made sense to use that instead of decreasing your framerate.
Even Burning Rangers used the mesh effect very often.
Title: Re: Transparent Shading on The Saturn
Post by: jabfg on August 18, 2018, 10:57:39 pm
The mesh effect looked ok on crt with composite, which is what people used back then, so it just made sense to use that instead of decreasing your framerate.
That depends on the region ;) , here in Europe we all used RGB since the scart cable came with the console.
Title: Re: Transparent Shading on The Saturn
Post by: ponut64 on August 19, 2018, 05:18:59 am
The mesh effect looked ok on crt with composite, which is what people used back then, so it just made sense to use that instead of decreasing your framerate.
That depends on the region ;) , here in Europe we all used RGB since the scart cable came with the console.

I did not know that.
In which case, you've got pixel-perfect display...
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 19, 2018, 05:30:21 am
Is SCART basically RGB in another form factor?
Title: Re: Transparent Shading on The Saturn
Post by: Jorhlok on August 19, 2018, 11:37:35 am
Is SCART basically RGB in another form factor?

I'm an american so I might have something wrong but my understanding is that SCART is a multipurpose audiovisual cable/port specification. So it carries analog video and audio and supports what is equivalent to composite, s video, component, and RGB. Not everything that uses SCART does everything and if it does you need a cable that supports it by having those pins. This is sort of like an old VGA cable that's in my drawer that only has the bare minimum of pins and wires so things like the monitor sending specs via one of the pins won't work with that cable.
Title: Re: Transparent Shading on The Saturn
Post by: jabfg on August 19, 2018, 11:39:15 am
SCART was a cable standard created in France that was adopted all over the Europe. It was created in the 70'S and supports bidirectional audio/video communication. It also supports RGB signal and the three types of sync( sync using the composite video, sync on Luma or pure SYNC).
All the TV in the 90's had this connector and the majority supported RGB signal ( expect the really cheap ones).
This standard was only dropped in favor of HDMI but the new TV's continue to bring the connector.
All Nintendo and Sega consoles supported the RGB through scart since the 16 bit era except (for unknown reasons) the Nintendo 64.
In the case of Sega Saturn the cable was bundled with the console and it supported RGB natively.
Japan also used a similar cable called JP21 that was physically the same but with switched signals. (See the attached diagram).
It also allows to play American /Japanese consoles in 60 hz. Because the majority of European TV s in the 90's supported 60hz in the form of PAL60 instead of NTSC (diferent type of video compression), if we use the composite cable or the almost not exitant s-video cable on these NTSC consoles the colors will be all messed up but with SCART in RGB mode, since there is no compression the image is displayed correctly.
The scart standard was only used on TV's, not on monitors except the old commodore 64/amiga ones (1084/1085 models).
I hope I helped.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 19, 2018, 06:42:27 pm
So, why doesn't the mesh effect create artifacts that the apple II and Atari 8 bit line used often for color (green and pink) in high-res mode?
Title: Re: Transparent Shading on The Saturn
Post by: Jorhlok on August 20, 2018, 02:21:41 am
So, why doesn't the mesh effect create artifacts that the apple II and Atari 8 bit line used often for color (green and pink) in high-res mode?

Short answer: it did.

IIRC the original apple ii hardware is monochrome under the hood and was able to make color with composite monitors with patterns of white and black pixels. This is horizontally on a scanline.
I'm not as familiar with atari computers but high resolution modes for many computers such as 80 column mode on a commodore 128 is hardly legible on a composite monitor or tv. Thankfully you could use it with monochrome or the equivalent of s video monitors.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 20, 2018, 07:13:01 pm
The Atari 8 bit line also offered the ability of the sprites to be used as an overlay to make real color in high res mode. Even transparency existed before the 16- bit generation ;).
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 22, 2018, 02:53:12 am
I guess one "easy" solution to transparency involves the following trick :
-Calculate your 4 vertices. Sgl has a function to do it and return the results (something like slConvert3dto2dfx).
-Get your min x and max x.
-Build an array [max x - min x] containing your min y and max y (so 2 unsigned shorts).
-Doing a bit of interpolation, calculate your min y and max y for each x value.
-If you are feeling on fire, interpolate your gouraud shading too.
-Use MANUAL draw commands (slSetSprite in SGL) and use 2 points lines, with your current x value and min y for point A and your current x and max y for point B. Set your color, select transparency and in your draw priority put your z value (max or center usualy).

Now it won't work correctly with scaled sprites because your minimum width is 8 (but I never tried with zero, it might just work too even if Sega says it doesn't. If it does your points x width should be 1 ).
Your "covered" data in the framebuffer must be in rgb code (16 clut or rgb) else the transparency won't even be processed and you will waste precious cycles.
Like usual, expect slower performances with transparency, so make sure you have no overdraw if you use it.
Cpu wise it shouldn't be too demanding unless you do it for like 20 objects or more.

Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 23, 2018, 11:29:58 pm
Anyway, if anyone is wondering, it's super easy to do (took me like 10 minutes), here is a Jo engine friendly version :


void drawLine(unsigned int no, Sint16 x1, Sint16 y1, Sint16 x2, Sint16 y2, FIXED drawPrty)
{
    SPRITE user_sprite;
    user_sprite.CTRL = 6;
    user_sprite.LINK =0x3000;
    user_sprite.PMOD = (1<<12) | (0<<11) | (1<<10) | (0<<9) | (1<<7)|(1<<6)| (CL32KRGB) | 3;
   
    user_sprite.COLR = (CD_Red);
    user_sprite.XA= x1;
    user_sprite.YA= y1;

    user_sprite.XB= x2;
    user_sprite.YB= y2;

    slSetSprite(&user_sprite, drawPrty);
}

It doesn't mean it's the fastest way (using the VDP2 is faster), but anyway...
The red shape is made of lines, I just went lazy but you could do any shapes you want and even add some shading (maybe just by playing with the color code or by using gouraud shading). The "background" is just sprites, it won't work on a VDP2 layer and will just replace the color in the framebuffer.
You could, I guess, just flicker it on and off or flicker the mesh effect, but then what's the point of the half-transparency?
The only real solution I see is to use line color tables with VDP2 layers, but that requires knowing what's on screen, which isn't easy at all.
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 24, 2018, 12:54:27 am
Incredibles posts these days XL2!

Well, it's a very creative solution on your part. I think that if you can facilitate the creation of content with this routine, it could be used well, in specific things. For large crystals for example.

With respect to making the transparency work in both VDP1 and VDP2. I still believe that you have to see how Burning Rangers does it. Well I think it's the best solution, using the SS pipeline.

The maximum that I have come to find out is that BR make two "spaces" of drawing are alternated in the VDP1. In first, only the opaque elements with their texture or color are drawn. And in a second the transparent elements and a part of the black opaque elements that cover the transparent elements.

The first space is drawn with a clipping system "total" and the second to half. For example for a final output resolution of 320x240 non-interlaced, with a Clipping System of VDP1 of 319x239. The second space will be 160x120 and then send it to VDP2 to NBG1 at 16bit color and using a Color calculation of this layer over the VDP1. The elements drawn by the VDP1 will look transparent over the VDP1 and VDP2 at the same time.

All for "one" frame. BR have 20FPS peaks stable.

Problems that still exist:

1) The elements of the VDP1 between them do not mix. Could we use VDP1 H-T? Solving the redrawing problems. Using only non-deformed elements in the vertical like: Scaled sprites, Normal Sprites or Distorted sprites like Billboards. Or new tricks like yours XL2.

2) Can we get to render the second space to the total resolution?

3) In Burning Renger the final layer of transparency is on top of everything, including the UI. Could we somehow avoid this problem? For example creating a mask on these parts. Or using a VDP2 layer for the UI.

Objective: Make a total Sun Lens Flare effect that works on VDP1 and 2 and that are 3D elements of VDP1.

A for all! :)
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 24, 2018, 01:33:07 am
Well, one solution that I'm currently experimenting with :
-Use the framebuffer from last frame.
-If for each pixel the bit 15 is 0, it's palette code. Just draw a line using cram palette with transparency ratio.
-If the msb is 1, use vdp1 half-transparency.
Since you set the z distance, it won't create much sorting issues and would keep artifacts low.

The main issue is reading from the framebuffer, it's just slow.
Like I mentionned, you can also use gouraud shading, so these fake polygons could still look nice.
I'm not sure it could be done with textures because the width must be a multiple of 8 (I hate this limitation)
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 29, 2018, 12:03:16 am
It looks like you've used this pseudo-polygon effect in your latest build of Sonic Z-treme, and It looks nice so far! I see that you've used 11 polygons for the shadow, looking though the VDP 1 debugger in Yabause  ;D.
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on August 29, 2018, 05:15:59 am
I didn't use that in the Sage demo.
Title: Re: Transparent Shading on The Saturn
Post by: 20EnderDude20 on August 29, 2018, 06:22:04 am
What did you use?
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on August 29, 2018, 09:37:50 pm
What did you use?

Scaled sprite whit vdp1 color calculation function replace/shadow, this are equal to half-transparent. Only add a step transform to monocrome mask if the pattern is color.
Title: Re: Transparent Shading on The Saturn
Post by: corvusd on September 02, 2018, 05:30:49 pm
Well, one solution that I'm currently experimenting with :
-Use the framebuffer from last frame.
-If for each pixel the bit 15 is 0, it's palette code. Just draw a line using cram palette with transparency ratio.
-If the msb is 1, use vdp1 half-transparency.
Since you set the z distance, it won't create much sorting issues and would keep artifacts low.

The main issue is reading from the framebuffer, it's just slow.
Like I mentionned, you can also use gouraud shading, so these fake polygons could still look nice.
I'm not sure it could be done with textures because the width must be a multiple of 8 (I hate this limitation)

Forgive XL2, I wanted to have answered this answer of yours before.

I have a similar idea to solve the problem. I thought that you could create a function that knew when a part of an element (Normal, Scaled or Distorted Sprite and lines or polylines) is on top of another element of VDP1 or not. That is, the function knows when a vertex of an element is above an element of VDP1 or VDP2. If so, use VDP1 CC (Color calculation) Half-Transparent and when it is on the VDP2 use palette transparency shared with VDP2 color RAM.

There would still be the problem that certain elements, when they are on the border, did not make a transparency correctly.

In your idea something similar would happen, but only at the line level.

Maybe my idea is "faster" because it would be done in the transformation calculation part. Comparing common coordinates, it would not touch to read the framebuffer as in your idea.

Also, it may be useful to use both ideas in combination.

Who knows, even plus the trick of Burning Rangers.

According to situations, each form or idea may be more suitable for a better solution. Quality / Performance

All of them using the native process and graphic pipeline of the SS.

Regards,
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on November 23, 2018, 07:42:25 pm
I spent some time writing a proper software rasterizer.
The full-software mode doesn't work correctly yet, but the line rasterizer works pretty well (you calculate the edges and then send them to be rendered as lines for each scan line).
It does create a few issues :
-The edges overlap, which leads to overdraw (solution will be to have some kind of active edges and clip them against each other).
-It creates many lines (like 800 for a 12 triangles cube), which should be reduced with the active edges clipping and by allowing the lines to be rendered vertically as well depending on the height/width ratio. Another solution would be to use polylines with a depth of 2 pixels (so each line covers 2 scanlines, so one polygon - with other techniques - takes maximum 112 polylines for a size of 224 pixels).
-It is more CPU intensive than just sending the data to hardware as is.

While the Burning Rangers technique seems very nice, it's also quite hard to pull off and it's probably quite slow.
But its "worst" case scenario will be much faster than my worst case scenario for sure.
Another idea I might try is to use scaled sprites instead of lines and play with the RAM addresses. But it will have some weird distortion for sure.

Anyway, this whole technique could be useful for games such as racing games or for one effect (like a window) in a game.

Title: Re: Transparent Shading on The Saturn
Post by: corvusd on November 26, 2018, 11:17:37 am
Hello XL2,

forgive me for not answering you before, here or in Discord.

As you had planned, your idea to do H-T without overdraw is another genius work on your part. :)

After thinking about it a little. I agree with you that it can be a problem, this amount of Draw Calls. In a way it reminds me of Doom and Defcon 5. I do not know if there are any more games that I draw by "lines" in SS. But both are quite bad in SS, similar or worst to 3DO, in contrast to PSX much better than both. It may be that it is easier to optimize calls on PSX because of the simplicity of the system against SS, or even because of the best optimized tools, although this year I doubt they were available even on PSX. Finally it is true that both are two ports very improvable for SS and that they had come from previous systems, which does not help.

All in all, I think it is a very good solution, for elements such as: Crystals, square shadows ... in short, simple forms, with a quad or two triangles. Still it would be possible to save the problem of mixing it with the VDP2. But as a sub-function within a larger function that simplifies this "subject" in SS, it would be ideal. Come on, what should have been done in his day.

Thank you for your great work!

Regards,
Title: Re: Transparent Shading on The Saturn
Post by: XL2 on December 06, 2018, 06:02:02 am
Ok, so I got a technique similar to Burning Rangers working.
I'm doing like BR, letting the VDP1 rasterize the sprites, SCU DMA the frame buffer to work RAM, then SCU DMA it to VDP2 VRAM, but instead of swapping the frame buffers or clearing it, I'm actualy using an offscreen area of the frame buffer.
So I don't have that 16 ms latency that BR had (well, it's my understanding from reading the VDP1 technical manual), so the game can still hit 60 fps in some areas (there is an impact on framerate, but lower than what BR did).
I had to work around SGL to get these working as, obviously, SGL never planned the hardware to be used in such a way.

If anyone is wondering how to do it :
1) Set your NBG0 or NBG1 layer to bitmap, 16 bits, scale x up by 2.2, y by 2.
2) Modify your system clip command to allow a range from 0 to 511 for the x value. No need to modify y.
3) Each frame, use a local coordinate of 432, 56, write a custom draw command and use a scaled sprite (8x1, no preclipping (faster this way), using a VDP2 palette value of 0 with no transparent pixels). Leave if in vram if you aren't using SGL. Also use a clipping window (352 to 511, and 0 to 111)

4) For each loop in your game's logic, start by DMAing the frame buffer array to the NBG0/1 VRAM (I use bank A0) with a for loop (like y=0; y<112; y++) and send the array in work ram line by line using SCU direct DMA.

5) Write - using custom draw commands - sprites or polygons that you will need to scale them (multiply) by x:0.454545 and y:0.5 in screen space coordinates to an offscreen area. Either use SGL's windows (far) for the transparent sprites, or just send them far in your drawing list to make sure they get drawn first and, more importantly, make sure they are affected by the correct local coordinates command.

6) Some time before vblank, DMA the frame buffer to work ram using again a loop to skip the lines and data. If you want to be safe, you can use the VDP1 registers to make sure you got past all transparent objects before DMAing the data. It will pause the drawing, so be warned! Transfer only what you need and ASAP.

7) Vblank, go back to point 4.

Of course, it won't solve the sorting issues since your transparent objects will be on top of everything, so you can use a low-quality model of your avatar using again mask values (0) and send them to the offscreen area, sorting everything with the current draw commands. You would also need to either send polygons masking the walls and all to the offscreen area or use a more fancy no-overdraw technique (such as portals, BSP, etc.).