SpritesMind.Net

Although this is mainly a Megadrive dev forum, this is the best place I know of to get some knowledgable answer for my question.

No, it's not about wether the Saturn can do transparency effects or not... I'm well aware that it can do it, in numerous way, all with their own quirks in them (vdp1 and its framebuffer rewrites, vdp2 sorting, meshing, etc).

What I'd like to know is that if there are any games that actually use software code to calculate and apply transparency effects. Or if it is possible at all. As far as I'm concerned, this is an urban legend - every game I checked that claimed to do this, was infact using either hardware transparency, or just meshing at high resolutions.

The closest I know of is Burning Rangers, but even that just draws sprites on a VDP2 field, the transparency effect itself come from the VDP2, not software calculations. And even the "drawing sprites with the vdp2" may be just smart use of vdp1, drawing sprites to buffer/ram, reading them in with the vdp2 and displaying as a background with transparency applied.

As far as I know, the "mesh" technique was the one nearly everything used. The CPUs on the Saturn simply aren't powerful enough to do alpha effects via software in a game. Did you ever see software alpha effects on 486 PCs? No? Same reason. A 28 MHz MIPS won't do software alpha unless the place it's doing it is trivial.

what is the deal with the HW transparencies that they're not used much ?
Sonic R is full of transparency use... 2D and 3D transparency stuff don't mix well ?

Chilly Willy wrote:As far as I know, the "mesh" technique was the one nearly everything used. The CPUs on the Saturn simply aren't powerful enough to do alpha effects via software in a game. Did you ever see software alpha effects on 486 PCs? No? Same reason. A 28 MHz MIPS won't do software alpha unless the place it's doing it is trivial.

That's what I was thinking too, which makes me wonder how the hell did that rumor started its life. It's about as stupid as the Segacd doing amiga style HAM modes.

Meshing was a hardware feature too btw (you could set vdp1 to draw checkerboard pattern meshed textures).

TmEE co.(TM) wrote:what is the deal with the HW transparencies that they're not used much ?
Sonic R is full of transparency use... 2D and 3D transparency stuff don't mix well ?

afaik, sprite-on-sprite and quad-on-quad (vdp1) transparency was achieved by rewriting the picture to the framebuffer, which wasted a lot of fillrate.
Sprite-on-background transparency (vdp1 to vdp2) was easier to achieve, but far less flexible, so it wasn't used that often. The underwater fish boss in Panzer Dragoon Zwei used this.

I guess you just needed clever programming to do it so it looks impressive.

Huge wrote:

Chilly Willy wrote:As far as I know, the "mesh" technique was the one nearly everything used. The CPUs on the Saturn simply aren't powerful enough to do alpha effects via software in a game. Did you ever see software alpha effects on 486 PCs? No? Same reason. A 28 MHz MIPS won't do software alpha unless the place it's doing it is trivial.

That's what I was thinking too, which makes me wonder how the hell did that rumor started its life. It's about as stupid as the Segacd doing amiga style HAM modes.

Meshing was a hardware feature too btw (you could set vdp1 to draw checkerboard pattern meshed textures).

TmEE co.(TM) wrote:what is the deal with the HW transparencies that they're not used much ?
Sonic R is full of transparency use... 2D and 3D transparency stuff don't mix well ?

afaik, sprite-on-sprite and quad-on-quad (vdp1) transparency was achieved by rewriting the picture to the framebuffer, which wasted a lot of fillrate.
Sprite-on-background transparency (vdp1 to vdp2) was easier to achieve, but far less flexible, so it wasn't used that often. The underwater fish boss in Panzer Dragoon Zwei used this.

I guess you just needed clever programming to do it so it looks impressive.

The main problem with sprite / quad transparency on Saturn is when you are using it on polygons. The hardware transparency effect is done in this way :
destination pixel = 50% destination pixel + 50% source pixel

This works perfectly when you're rendering simple sprite or perfect rectangulars polygons but when you've a polygon which is no more rectangular some pixels will be overdraw (this is the way the VDP1 is rendering quad) and the transparency effect become wrong for these pixels. The VDP1 renders quad in a strange way, because of that the transparency can't work properly and that also cause important fillrate waste when you're doing 3D. Without speaking about the hardware itself which is probably more complex than a conventionnal 3D triangle system.
I guess we have that because it was supposed to do 2D, not 3D...

And yeah, doing software transparency is probably too heavy for a 28 Mhz RISC. I guess you can do it locally but definitly not on a complete screen.

I see. So the problem wasn't the speed of the transparent rendering (though it contributed), but the fact that when disorting a quad to a polygon, the transparency effect got all fubared.

But when using quads in 3d, the effect worked more or less fine, like in the Sonic R teleport pod:

You'll notice in the picture that the transparent part is not textured, just colored. When drawing a warped (3D) transparent quad, it screws up the texture. You'll notice in your picture that no textured parts are transparent. So that would seem to be the limitation on the hardware transparency - you either don't warp the quad, or don't use a texture if you do.

By warping, you mean quads drawn as polygons (with two corners of the quad having the same coordinates), right? That screws textures as well as transparency, I understand. The picture I posted has a rectangular shape though, so it could be textured AND be transparent at the same time, if what we said so far stands true.
Polygons are of course disorted as they are warped quads, and that would mean that the quad is overlapping itself, which is what ruins the transparency effect, as well as being slower as well.

In your picture, polygones are hopefully the type of polygon where the transparence can work because a very few pixel overlap during the rendering. Texturing won't change the done afaik, if you're look closely to the picture you'll see some wrong transparents pixels on polygons border where pixels overlap.

Yeah, which is how a quad warped to polygon would look... I see.

Bit late I know, but still...

Huge wrote:What I'd like to know is that if there are any games that actually use software code to calculate and apply transparency effects. Or if it is possible at all.

Well technically it's entirely possible. If your game is already running at 30Hz or slower anyway (as a lot of them do) you could probably do a fair bit in software - shadows might be a good example. But I agree with you, I don't know of any game that actually does that, and think it's fairly unlikely, because it's a pain.

Huge wrote:And even the "drawing sprites with the vdp2" may be just smart use of vdp1, drawing sprites to buffer/ram, reading them in with the vdp2 and displaying as a background with transparency applied.

That's exactly what it does. Neat trick - but it aint software. The game also does do some actual sprite to sprite transparency IIRC, but not much.

I think the main reason why real transparency isn't used often is because it's so much slower than normal rendering. It takes more than twice as long to render something transparent vs just using the mesh feature. This is a real problem.

As Stef says there is also the other problem that during polygon drawing, some pixels can get drawn twice, which means the colour calculation is also done twice, leading to wrong coloured pixels. But I don't think this is such a big deal personally, pixels are blurred on a TV anyway, and when everything is moving, it isn't that noticable. At least not noticable enough that it would stop me using it.

But the rendering speed? Hell yeah, that's a showstopper.

There's no difference in textured and non textured, the above mentioned problem happens all the time, whenever anything is drawn at an angle.

Very interest theme

Transparence?

Okay!

This is no missing in Saturn emu and others emulators!

transparence do TV set, all consoles in past time optimized for TV set's only, screen mask in TV have difference, i do experiments, yes i see how emus show picture on my TV, and correctly without any plugins and filters! plus i run my PC game Diablo 2 LOD and TV show picture more cool than on my Monitors (i have two monitors LCD '19 and CRT '17)
Because lower resolutions more better works on TV! and TV mask completely compatible with graphic on consoles

For sure in Diablo2 you may see red and blue balls of life and mana show more cool on TV set, for testing you need old CRT TV set like a JVC, Samsung, Philips, or anything another CRT's

Interesting thread, I've had these pics posted on my old site for some time now. I'd guess it isn't a software transparency effect either?

Sonic R's special level has a moving translucent texture map over the floors, and the 2D background can be seen through the 3D level.


Burning Rangers






DIVX Video:
http://www.gamepilgrimage.com/sites/def ... AT005d.avi

Are your pics from real hardware or an emulator ?
The transparency seems to be done in hardware of course as it's applied directly on polygon but i can't see the nasty effect of pixels overdraws...

edit :
Just saw the video, finally i'm not sure anymore we have hardware transparency here, if you look closely you can see that transparent polygon are rendered in half resolution, i can't see any good reason for that except software rendering... also that explain why the transparence is perfect (not overdraw errors).

Looks like this is from emulator SSF 0.11

if it was from VHS or another devices for record it will be more sharp with transparency effects

very close to NTSC filter right?

but why on my TV instead chess board effect, show transparence objects?
in my region work PAL standard on 50Hz yeah a bit slower than NTSC, but colors better and without JPG picture effect