Questions about Sega Saturn

I do not believe that to be the case. The water (and floor) looks wastly different in those game.
Go play the first stage of the first Panzer Dragoon again. The "floor" of that stage is a flat water scroll plane that stretches on to the horizon, with pillars and other structures sticking out of it. The water has a ripple effect applied to it, and everything that isn't water or sky is rendered at a much lower resolution. It's clearly a VDP2 scroll plane.
 
I've been looking through the Saturn VDP2 documentation again and unless I'm really misunderstanding it or it's very wrong it looks like the high resolution modes (640 or 704 width) are extremely limited. You effectively just get one tiled layer priority combined with the VDP1 layer, and no rotation or color blending effects. It's a lot like the SNES's high resolution (512 wide) mode which was also very limited.

EDIT: I think you can use a rotation layer in high resolution mode, it just ends up as low resolution (pixel doubled)

This thread showing very high resolution emulator rendering of VDP1 is pretty instructive as to what's VDP1 and what's VDP2 in several games:

http://www.neogaf.com/forum/showthread.php?p=191669876

The VDP2 planes stand out as uniformly low resolution. The second Panzer Dragoon screenshot shows a good contrast: the plane at the top of the screen shows increasing pixel density towards the horizon, therefore it's VDP1. But the water does not, therefore it's VDP2.
 
Last edited:
Oh my those saturn models....They look like they are falling apart. They are full of holes too.
I wonder if its the emulator of if it is due to the console's inefficient 3D hardware.
PSX models look much more robust in HD
http://sfx.gligli.free.fr/psx_enhance/gt_bef.jpg
http://i.imgur.com/ztFnm.jpg
https://i.ytimg.com/vi/jKmq0Uzs20U/maxresdefault.jpg
https://i.ytimg.com/vi/zFCiD3uaVB8/maxresdefault.jpg
https://i.ytimg.com/vi/yQ9k4NBJZKI/maxresdefault.jpg
http://i.imgur.com/Ud6bYwE.jpg
maxresdefault.jpg
 
This thread showing very high resolution emulator rendering of VDP1 is pretty instructive as to what's VDP1 and what's VDP2 in several games:
http://www.neogaf.com/forum/showthread.php?p=191669876

I was looking through those images and came across this:
fMk8sJ2.jpg
Aren't those triangles? How were they done. From the texels on the closest ones you can tell this is not just a distorted quad with two coinciding verts, and from the sharp edges in all sides we also know its just not a quad with a triangular texture.
So... How?
 
Last edited:
Aren't those triangles? How were they done. From the texels on the closest ones you can tell this is not just a distorted quad with two coinciding verts, and from the sharp edges in all sides we also know its just not a quad with a triangular texture.
So... How?

It's an emulator using OpenGL to render the graphics. It's not correct.

If you look carefully through some videos of the real thing you can see that the texturing on the triangles is distorted. See here:

 
I still don't get it. Sure the emu uses openGL, but it just draws what the game code tells it to, even if the emu translates quads into tris. If the software there were telling it to draw a quad with to of its verts meeting at the same position in order to fake a triangle (with no freedom of UV mapping) no matter how the emu translatrs that to openGL, I'd still expect to see the texture patern on that triangle to "squeeze" into one of its points. Either that, or the texture itself would have a triangular alpha, which would manifest as one of the sides having a sawtooth pattern.
It seems to me like there was some trick in there to better fake tris. Maybe clipping the quad in half...
Look into that screenshot and picture what I'm saying.
 
This is a quick mock-up of what I'd expect a triangle to look on saturn if it were only capable to fake triangles by distorting quads ( assigning the same position to two verts ) or by using the texture's alpha itself to clip the quad in half. The artifacts would still look the same on an emulator, as it can't interpret artistic intention, it just translates code and instructions...

Distorted quad:
SaturnDistortedQuadMockup.png
(Ignore the perspective correction, the Saturn wouldn't do it, but I can't disable it in PS, and by the look of it, OpenGL is doing it too in these screens anyways)

Alpha texture:
SaturnAlphaMaskedQuadMockup.png.png
 
I still don't get it. Sure the emu uses openGL, but it just draws what the game code tells it to, even if the emu translates quads into tris. If the software there were telling it to draw a quad with to of its verts meeting at the same position in order to fake a triangle (with no freedom of UV mapping) no matter how the emu translatrs that to openGL, I'd still expect to see the texture patern on that triangle to "squeeze" into one of its points. Either that, or the texture itself would have a triangular alpha, which would manifest as one of the sides having a sawtooth pattern.
It seems to me like there was some trick in there to better fake tris. Maybe clipping the quad in half...
Look into that screenshot and picture what I'm saying.

The way that OpenGL hardware (or the emulator, if it's being done at the level) tessellates a quad into two triangles is totally different from how Saturn renders a quad. The texture mapping is always affine in world space. Squeezing the texture towards one end of a triangle is impossible unless it's a product of the applied perspective projection transformation to screen space, or the emulator uses shaders with a different interpolation method.

If you draw a quad with two shared vertexes the end result will be that the second triangle will be rejected entirely and the quad will just be filled with the first triangle.
 
Aha! Gotcha. So my 1st mockup was representative of what a HD software emulation of the actual way saturn drew its quads (by blitting them) would lool like then... Is that correct?
 
Aha! Gotcha. So my 1st mockup was representative of what a HD software emulation of the actual way saturn drew its quads (by blitting them) would lool like then... Is that correct?

Yes, minus the perspective projection as you said.

There'll also potentially be a ton of internal overdraw depending on what order the vertexes are supplied in. If the upper left vertex is the first specified it'll result in a bunch of lines all coinciding on that same right-most vertex.
 
Pardon my language, but really, what an absolute piece of shit way of fucking drawing their geometry. They must have been out of their minds when they considered that sensible.
 
Pardon my language, but really, what an absolute piece of shit way of fucking drawing their geometry. They must have been out of their minds when they considered that sensible.

This is what happens if your original hardware goal is to make something that's really good at blitting a bunch of scaled sprites so you can do games that look like Outrun or Afterburner did in the arcade. Then later you decide you want actual polygons and try to make it fit within the sprite paradigm.

The internal overdraw, the jagged looking interpolation, the broken blending (that was very slow anyway), the poor guardband and lack of any real ability to tessellate were all consequences of this sloppy design.

The most offensive part of the design is that incremental round-off error causes the lines that compose the sprites to not align correctly even w/o any sides getting pinched (like in plain rotation). So to prevent gaps from showing up they draw an extra pixel on the line diagonals, giving substantial internal to most polygons regardless of how you try to get around it. AFAIK it's technically possible to render triangles with a forward rendered line technique like this without having internal overdraw or gaps. This would make perspective projection cheaper if they actually implemented it. But it's really difficult to get right and still has a bunch of other problems. Chris Hecker talked about this in his magazine series on software rendering from the 90s.
 
Last edited:
Yeah, I figured so, but by the time the goal post changed, they should have started from scratch. If sprites were so impossible, it would have been just as easy to pick a more traditional rasterization architecture and have a geometry engine with a function to quickly set-up scree-coplannar quads. Oh wait, that's what the psone did...
 
Is there a way you can prove this? Sonic Jam had a very limited 3D environment. Compare it to Soul Reaver which was a seamless huge 3D fully detailed world and Sonic Jam doesnt look all that impressive all of the sudden.
But still bland looking


Looked mediocre next to Wipeout and Ridge Racer

In what ways was it better?

Well.. have you tried the game?
The top default view is not impressive at all, but if switch to back view, you can actually see all the level geometry up in the distance, fully textured. Moving objects are gourard shaded. Floor is flat, but fully textured too, no pop up at all. Solid 30fps framerate.
I cannot think up of such a game on both PS1 or N64.. Spyro, Mario, Zelda, Banjo, Donkey Kong, they all used blurry textures or flat polygons.

Its even more impressive, if you consider it was released back in June 1997..
 
VDP 2 can draw a128x128 flat floor at 60fps. That's 980k "polygons" / second.. Im not stating that the Saturn was more powerful than the PS1/ N64, but some games designed specifically to run in it, would have been impossible on the other systems, without pop-up or reduced texture resolution.

Tomb Raider JPN Saturn version has better draw distance and water effects compared to the PS1 version.
 
Well.. have you tried the game?
The top default view is not impressive at all, but if switch to back view, you can actually see all the level geometry up in the distance, fully textured. Moving objects are gourard shaded. Floor is flat, but fully textured too, no pop up at all. Solid 30fps framerate.
I cannot think up of such a game on both PS1 or N64.. Spyro, Mario, Zelda, Banjo, Donkey Kong, they all used blurry textures or flat polygons.

Its even more impressive, if you consider it was released back in June 1997..
Yes I did. It looked great. But it was one limited environment. Would Sega be able to pull that off if it was one huge environment with more geometry and more variety?
The environment is consisted mainly from walls and grass, Trees are flat and there are a few objects here and there. The textures are mainly grass and the tiles
It was impressive looking but I still dont see it as proof of technical superiority
 
VDP 2 can draw a128x128 flat floor at 60fps. That's 980k "polygons" / second.. Im not stating that the Saturn was more powerful than the PS1/ N64, but some games designed specifically to run in it, would have been impossible on the other systems, without pop-up or reduced texture resolution.

Tomb Raider JPN Saturn version has better draw distance and water effects compared to the PS1 version.
There is a specific effect that was absent from the PS1 version. That water effect was also present in the other Saturn versions, but the PS1 version had more enhanced lighting effects underwater. Do you have evidence that it looked better overall?
 
Yes I did. It looked great. But it was one limited environment. Would Sega be able to pull that off if it was one huge environment with more geometry and more variety?
The environment is consisted mainly from walls and grass, Trees are flat and there are a few objects here and there. The textures are mainly grass and the tiles
It was impressive looking but I still dont see it as proof of technical superiority

Trees are 3D.
Im not stating the Saturn was technical superior to the other systems.. But some particular games, designed to take advantage from the VDP2, would be impossible to run on other systems without downgrading.
 
Back
Top