Jo Engine Forum
Sega Saturn Development => General discussion about the Sega Saturn => Topic started 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?
-
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).
-
Very good ideas! Are you think about How make the change of shape when the camera rotate above the shadow?
-
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)
-
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?
-
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.
-
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.
-
But a shadow’s just one color, so it shouldn’t matter that much
-
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.
-
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.
-
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.
-
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?
-
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.
-
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!
-
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.
-
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.
-
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.
-
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! :)
-
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.
-
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.
-
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.
-
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.
-
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...
-
Is SCART basically RGB in another form factor?
-
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.
-
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.
-
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?
-
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.
-
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 ;).
-
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.
-
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.
-
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! :)
-
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)
-
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.
-
I didn't use that in the Sage demo.
-
What did you use?
-
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.
-
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" pq 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 with 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,