Saturn transparency question

Stef · Post by **Stef** » Mon Nov 16, 2009 5:37 pm

Emulator can fake transparencies, they can change the mesh effect in transparency and use differents methods to rendering transparents polygons (without any pixels overdraws errors) so this's not relevant here.

sheath · Post by **sheath** » Mon Nov 16, 2009 5:49 pm

All of these shots are from the S-video out on my 1995 Saturn.

Shadow · Post by **Shadow** » Mon Nov 16, 2009 5:54 pm

Stef this is you?

Gens 2.12 perfect emulator, i never forgot good past time because it was my first emu which i use, thanks you very much, my best friend

Unfortunately, in 2002 i don't have internet, and just read history files, i always have unlimited time for testing, but this amazing emu no more new releases

Shadow · Post by **Shadow** » Mon Nov 16, 2009 6:15 pm

guys try to use "SSF 0.11 Alpha R1" in options -> Program4 -> Mesh translucent, this is close to transparence effects!

Stef · Post by **Stef** » Mon Nov 16, 2009 7:22 pm

Shadow wrote:Stef this is you?

Gens 2.12 perfect emulator, i never forgot good past time because it was my first emu which i use, thanks you very much, my best friend

Unfortunately, in 2002 i don't have internet, and just read history files, i always have unlimited time for testing, but this amazing emu no more new releases

Thanks for your comment :p

Gens is discontinued since a long time now. I started a rewrite but never had the motivation to complete it...

Stef · Post by **Stef** » Mon Nov 16, 2009 7:25 pm

sheath wrote:All of these shots are from the S-video out on my 1995 Saturn.

So i think this is a software transparency effect, i can't see how doing it using hardware (means VDP1 polygon drawing and using it in VDP2 BG)

sheath · Post by **sheath** » Mon Nov 16, 2009 7:43 pm

The effect for light beams in Burning Rangers is identical to the effect used in PS1 games like Soul Reaver. Unlike Soul Reaver though, Burning Rangers doesn't suffer from full screen dithering:

The Sonic R effect is just amazing, not even the PC version replicates it. Not only are the floors on that level texture mapped, but the moving texture combined with the translucency of the floors to the far background simply wasn't done on other hardware that generation.

King Of Chaos · Post by **King Of Chaos** » Mon Nov 16, 2009 8:08 pm

I forgot about Sonic R.

Do any other emulators do the transparency that SSF apparently does?

Kinda off-topic too, anyone got any idea/tutorial on how to get CEP to work with SSF?

Stef · Post by **Stef** » Mon Nov 16, 2009 10:19 pm

King Of Chaos wrote:I forgot about Sonic R. Do any other emulators do the transparency that SSF apparently does?

Kinda off-topic too, anyone got any idea/tutorial on how to get CEP to work with SSF?

No ideas about how saturn emulator does the VDP1 rendering.
I worked a bit on SSE (a discontinued saturn emulator) so i can say the software renderer is correct, unfortunatly the internal core was too messy and that discouraged me...

Huge · Post by **Huge** » Tue Nov 17, 2009 9:17 am

The emerald level in Sonic R is fairly simple - the polygons of the level are drawn at half opacity, with a vdp2 background "overlayed" into them.

Kinda off-topic too, anyone got any idea/tutorial on how to get CEP to work with SSF?

Dunno, but if you check the About box, it lists the CEP base addresses.

guys try to use "SSF 0.11 Alpha R1" in options -> Program4 -> Mesh translucent, this is close to transparence effects!

This will change the vdp1 meshed polys to transparent ones. I'm not sure how it is handled internally - a postprocess or just by redirecting all polys that use the mesh bit to use half opacity instead (thereby rendering everything on the VDP1?).
But, it only handles vdp1 stuff, vdp2 checkerboards stay as they are.

Emulator can fake transparencies, they can change the mesh effect in transparency and use differents methods to rendering transparents polygons (without any pixels overdraws errors) so this's not relevant here.

Only the VDP1 mesh function can be replaced, and that's optional. If you check the Sonic R screenshot I posted above, that one comes from SSF, and it HAS pixel overdraw errors.

As for Burning Rangers, here are some comparisons:

Normal picture:

Sprites disabled, backgrounds only:

Normal Background 0 disabled, NBG1 only:

Normal Background 1 disabled, everything else displayed:

Every transparent effect (except for meshes), from the jumpjets to fire effects, are done this way in the game. Judging from the sheer amount of these effects, I'm more leaning towards clever vdp1 manipulation than a software effect. Surely there is a way to draw polygons directly as a vdp2 background - maybe one framebuffer is used for normal rendering, another one to write the transparent background to? Multi-pass rendering on the Saturn, of sorts? That would also explain why the transparent effects are done at half-resolution.

(and if you read back a bit above, Steve confirms that it does just that)

Also, if you check the divx video posted above, frame to frame, you can see that the transparent object and the rest of the screen does not move in complete sync. The transparent part also does not perfectly "align" with the foreground:

Stef · Post by **Stef** » Tue Nov 17, 2009 7:11 pm

So this is software transparency rendering, the cpu is used to render the transparent polygon (simple gouraud rendering in half resolution, the hard part is to take in account the 3D objects to clip the polygone on correct part) in a VDP2 BG layer then the VDP2 apply transparency on this BG layer.
What a complex way of doing that...

Emulator can fake transparencies, they can change the mesh effect in transparency and use differents methods to rendering transparents polygons (without any pixels overdraws errors) so this's not relevant here.
Only the VDP1 mesh function can be replaced, and that's optional. If you check the Sonic R screenshot I posted above, that one comes from SSF, and it HAS pixel overdraw errors.

I was speaking about "emulator" in general, it's pretty easy to replace the mesh effect with real transparency as SSF does... but we can also do correct transparency effect (without pixel overdraw), afaik that is even simpler to do correct rendering (scanline based) instead of the strange VDP1 rendering...

Huge · Post by **Huge** » Tue Nov 17, 2009 7:55 pm

Right, I kept thinking that the effects are rendered transparently from the getgo, which could potentially be too much with 50+ explosions and fire effects onscreen. But, you can render them opaque, since the transparency itself is applied by the vdp2. That's actually not a bad idea...

But I still think the game just does multi-pass hardware rendering. It just seems more straightforward. It would also explain why the 3d landscape looks like total junk otherwise, with extreme clipping, popup, and low-res textures everywhere - the VDP1 is too busy rendering twice, so they had to pull every plug when rendering the landscape, to keep up framerates.

afaik that is even simpler to do correct rendering (scanline based) instead of the strange VDP1 rendering...

What do you mean by "strange vdp1 rendering", quads vs triangles?

Stef · Post by **Stef** » Tue Nov 17, 2009 10:54 pm

Yep, the VDP1 is a 2D sprite drawer, it's afaik the most powerful system for that, it can draw *many* sprites, it doesn't have any limitation except the fill rate or VRAM space, it can apply many effect to them etc... when PSX design came out, SEGA modified it a bit to help for "3D" rendering (thinking about line / flat / gouraud rendering) but it's still a 2D sprite renderer. So yes, it draws quad instead of triangle, but that's not the most important point, it also doesn't use the conventional horizontal scanline fill method to render quad : take the quad where ABCD define each points of it (clockwise order).
- VDP1 will render the quad by rendering each scanlines between [AB] and [CD].
- Conventionals and moderns systems first sort points on Y coordinate (take A,B,D,C as Y order here) then render horizontals scanlines between [AB] and [AD], then [BC] and [AD] and finally [BC] and [DC].

This difference permit some stranges effects on the saturn, as rendering twisted polygon but as backdraw this method wastes time in pixel overdraw, some pixels are calculated and wrote severals time in frame buffer... and it becomes a bigger problem when you're trying to do transparency.

sheath · Post by **sheath** » Wed Nov 18, 2009 1:24 am

Stef and Huge, I would be very grateful if you could point me to reading materials regarding this discussion. I have been speculating based on the games for over a decade, and this single discussion is the first time I've heard anybody say reasonable things about Saturn hardware.

In particular, I would absolutely love to see any sort of hard facts about what Sega did to the Saturn's specs after the PS1 press release in summer of 1993. Secondarily to that, any and all comparisons regarding the way Saturn renders quads to other quad based 3D rendering methods would be great.A comparison to PS1 and N64 rendering methods would also be very helpful.

Huge · Post by **Huge** » Wed Nov 18, 2009 8:49 am

Quite a bunch of the official docs are up here. As far as I know, the only thing undocumented in them is a couple of things about the SCU DSP.

http://www.eatsushi.org/content/index.p ... sega_docs/