Saturn transparency question
Moderator: BigEvilCorporation
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
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
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Thanks for your comment :pShadow 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
Gens is discontinued since a long time now. I started a rewrite but never had the motivation to complete it...
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.
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.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
No ideas about how saturn emulator does the VDP1 rendering.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?
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...
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.
But, it only handles vdp1 stuff, vdp2 checkerboards stay as they are.
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:
Dunno, but if you check the About box, it lists the CEP base addresses.Kinda off-topic too, anyone got any idea/tutorial on how to get CEP to work with SSF?
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?).guys try to use "SSF 0.11 Alpha R1" in options -> Program4 -> Mesh translucent, this is close to transparence effects!
But, it only handles vdp1 stuff, vdp2 checkerboards stay as they are.
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.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.
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:
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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...
What a complex way of doing that...
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...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.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.
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.
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.
What do you mean by "strange vdp1 rendering", quads vs triangles?afaik that is even simpler to do correct rendering (scanline based) instead of the strange VDP1 rendering...
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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.
- 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.
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.
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.
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/
http://www.eatsushi.org/content/index.p ... sega_docs/