Transparent Shading on The Saturn

[XL2]

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.

[corvusd]

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!

[XL2]

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)

[20EnderDude20]

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  .

[XL2]

I didn't use that in the Sage demo.

[20EnderDude20]

What did you use?

[corvusd]

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.

[corvusd]

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,

[XL2]

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.

[corvusd]

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,

[XL2]

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.).