A few Q's about the Saturn and emulation

A few Q's about the Saturn and emulation

1. Is the saturn's hardware 2d processor really needed for good 2d games? ie. Capcom arcade ports, snk, 2d sidescrollers..

2. Should the psx also be able to do the same 2d like the saturn for those ports if it had the ram?

3. How does the saturn bend quads? Create smaller quads? Or actually hardware accelerated curves? How does it affect performance?

4. Does Nights Into Dreams use non-coplaner quads? If so, how does the current saturn emulators draw them correctly/incorrectly?

5. Is the saturn more powerful at 2d than the psx?

Thanks.
 
A few Q's about the Saturn and emulation

1. Is the saturn's hardware 2d processor really needed for good 2d games? ie. Capcom arcade ports, snk, 2d sidescrollers..

The video part is made of 2 ICs : the VDP2 renders the backgrounds layers, and the VDP1 draws sprites and polygons (a sprite is basically a polygon with a mapped texture).

You can still play those games without backgrounds, but without sprites it would be difficult ...

I don't see the point of the question anyways :)
 
A few Q's about the Saturn and emulation

1. Is the saturn's hardware 2d processor really needed for good 2d games? ie. Capcom arcade ports, snk, 2d sidescrollers..

Sure...

2. Should the psx also be able to do the same 2d like the saturn for those ports if it had the ram?

Yes...

3. How does the saturn bend quads? Create smaller quads? Or actually hardware accelerated curves? How does it affect performance?

?

4. Does Nights Into Dreams use non-coplaner quads? If so, how does the current saturn emulators draw them correctly/incorrectly?

?

5. Is the saturn more powerful at 2d than the psx?

Yes...
 
A few Q's about the Saturn and emulation

A few more questions and iterations of previous questions:

Why is the saturn a more powerful 2d system than the psx? Just because of the extra ram?

How comparable is the Saturn's audio chips to other consoles?
 
A few Q's about the Saturn and emulation

Originally posted by Runik@Sep 12, 2003 @ 04:35 AM

1. Is the saturn's hardware 2d processor really needed for good 2d games? ie. Capcom arcade ports, snk, 2d sidescrollers..

The video part is made of 2 ICs : the VDP2 renders the backgrounds layers, and the VDP1 draws sprites and polygons (a sprite is basically a polygon with a mapped texture).

You can still play those games without backgrounds, but without sprites it would be difficult ...

I don't see the point of the question anyways :)

What I'm wondering, if the saturn could have done better by removing it's 2d vpu and having just one more powerful 3d vpu instead. Is having a dedicated 2d vpu better for 2d than just having 1 powerful 3d vpu to do 2d.
 
A few Q's about the Saturn and emulation

Is the saturn's hardware 2d processor really needed for good 2d games? ie. Capcom arcade ports, snk, 2d sidescrollers..

No, but it helps. Especially if there are any raster effects, which are animation effects that are designed around traditional scanline-oriented 2D hardware manipulation; a lot of old-school screen warping/waving and perspective effects are achieved with this, and there's no cheap way to achieve the same effect on framebuffer-oriented hardware. It can be done of course, but you'll take a performance hit compared to just being able to shift scroll registers around.

Should the psx also be able to do the same 2d like the saturn for those ports if it had the ram?

Generally speaking, yes.

How does the saturn bend quads? Create smaller quads? Or actually hardware accelerated curves? How does it affect performance?

I'm not sure what you mean here. Can you give a more concrete example? As far as I understand VDP1 operation, it really just draws a quad line-by-line, with the orientation of the "lines" being appropirately transformed for the supplied coordinates. The biggest VDP1 performance issues are in per-pixel operations like semitransparency (which does exist, but can only be used with RGB modes, and only if the rendering order is correct, and takes something like 6 times as long to draw, which is why you see a lot of games using the crappy "mesh" pseudotransparency) and shading, which are mostly unrelated to geometry (i.e. it's a fill rate limitation). Saturn does not have hardware-accelerated curves in the sense of modern 3D hardware (and neither do PSX or N64).

4. Does Nights Into Dreams use non-coplaner quads? If so, how does the current saturn emulators draw them correctly/incorrectly?

Saturn's VDP1, like most "3D" processors of its time, doesn't actually deal with a Z axis, so the question of non-coplanar geometry is a software one.

What I'm wondering, if the saturn could have done better by removing it's 2d vpu and having just one more powerful 3d vpu instead.

Well, that raises other questions:

- What makes a rendering unit "more powerful"? The obvious choice and industry consensus seems to be higher fill rate, which is dependent on the clock speed of the processor, the bandwidth of the video memory, and the number of pixels that can be rendered in parallel by the hardware. For a given production process, it doesn't make much sense to assume that arbitrary clock speed targets can be selected, and faster/wider memory and more pixel pipelines cost more money, which brings us to the next question:

- Was the split-VDP architecture so expensive that merely eliminating VDP2's background generation portions (the display generation parts would have had to stick around as part of our hypothetical super-chip, since rendering isn't very useful unless you can see the result) would have made up the cost difference? I doubt this would be the case. For one thing, it's generally cheaper to fabricate two smaller chips than one larger one on a given manufacturing process, because yield suffers as die size increases. Then you'd also be looking at a need for wider and/or faster memory to feed the improved processor, so I'm a little skeptical that such a tradeoff could have been feasibly made.

Unless, of course, the question you were asking was "Would Saturn have done better if Sega's engineers weren't constrained by reality?", to which the answer is an emphatic "Hell yes!" :cheers
 
A few Q's about the Saturn and emulation

Originally posted by ExCyber@Sep 12, 2003 @ 04:34 PM

I'm not sure what you mean here. Can you give a more concrete example? As far as I understand VDP1 operation, it really just draws a quad line-by-line, with the orientation of the "lines" being appropirately transformed for the supplied coordinates.

An example would be the hills in Nights. They are made of quads that seems to curve to make the hill look hilly. <_< But if I understand you correctly, it draws those quads line by line into a curve? :huh

Thanks for your answers btw. And everyone elses.
 
A few Q's about the Saturn and emulation

An example would be the hills in Nights. They are made of quads that seems to curve to make the hill look hilly.

It could be very careful use of concave quads. Strictly speaking, VDP1 doesn't render concave quads in what you might call a "correct" way -- it "draws outside the lines" in an approximation of the shape suggested by the vertices, filling in some space that is outside the true quad, so some emulators might have trouble with this. The key to stuff like this, however, is knowing how to play with graphics in general. I'm not in a position right now to analyze Nights's graphics, but I wouldn't be a bit surprised if Sonic Team pulled out all the stops and used perspective, shading, and anti-aliasing tricks to create or enhance the illusion of curved surfaces...

edit: as for the "line-by-line" thing, it's a little hard to explain, but if you take any convex polygon (i.e. there are no "dents", or any line drawn between two vertices will be entirely inside the polygon), you can break it down into a series of pixel lines to draw onto the screen - this is how a lot of renderers operate. However, when I say that VDP1 works "line-by-line", what I mean is that it works by scanning the specified quad line-by-line from "left" to "right" and "top" to "bottom". These are all in quotes because the "upper left" and "lower right" could be damn near anywhere on the screen, in which case the quad can be physically drawn from right-to-left, bottom-to-top, or in various other twisted ways. But the VDP1 always starts at the first coordinate and ends up at the last one. This is probably why concave polygons are drawn incorrectly - they result in "lines" that cut across the edges of the polygon. In essence, the VDP1 treats each quad as a stretched/warped rectangle.
 
A few Q's about the Saturn and emulation

2. Should the psx also be able to do the same 2d like the saturn for those ports if it had the ram?


Well, I don't think it could. It only has a single framebuffer and a GPU that can only draw simple primitives. The Saturn has an uber-complicated video architecture which can, for instance, do all sorts of funky tricks with multiple framebuffers, and the PSX would have to do all that with it's R3000 CPU. The problem is, that CPU doesn't have direct access to the video memory, it all has to go through the GPU. So maybe the question should be: "Should the psx also be able to do the same 2d like the saturn for those ports if it had the ram and a cpu twice as fast?
 
A few Q's about the Saturn and emulation

The Playstation's graphics processor can do all the primitives that VDP1 can. What it doesn't have is the sort of tiled backgrounds most 2D-oriented hardware are built around. That doesn't mean it can't do impressive 2D games, eg. Castlevania SotN. The criticism against the various Playstation Street Fighter ports is mainly that animation frames are missing, which can be explained by lack of video memory and no efforts to squeeze them in with tricky coding (eg. store the sprite animations in compressed form in memory and decompress and transfer each frame to video RAM when needed).

Your framebuffer argument is not only wrong, the opposite is true. The Playstation video architecture (the frame buffer is in fast video RAM along with all textures) allow for far trickier effects, like feedback swirls, warping effects and so on. To do the same on the Saturn you'd have to transfer the contents of the backbuffer into texture RAM, which is slow. VDP2 lets you do traditional raster-oriented tricks and can apply some effects to VDP1-produced graphics, but I wouldn't call it superior. And if you want to be picky, the Saturn doesn't have "multiple framebuffers". There's the one VDP1 renders to, and VDP2 combines its output with VDP1's into a sort-of framebuffer, but you don't have access to it.

And again, direct framebuffer access is mostly irrelevant for real-world apps. If you want to plot graphics, do it in main memory and DMA it over to video RAM during the vertical refresh. Both VDP1 and VDP2 suffer if you access their RAM while the screen is being drawn, so it's not a good idea to do so even if you can.
 
A few Q's about the Saturn and emulation

Originally posted by antime@Sep 14, 2003 @ 12:49 PM

The criticism against the various Playstation Street Fighter ports is mainly that animation frames are missing, which can be explained by lack of video memory

But how would the slowdowns in XmenVsSF/MSHvsSF be explained on the PSx while the Saturn port exhibited few if any slowdowns. Plus the fact that the Saturn was processing a lot more frames for those games than the psx was. Maybe it's because of the way the psx did 2d? I've played both the psx and saturn versions of both games and the psx versions exhibited some moderate to severe slowdowns when doing some of the large scale supers. The saturn ports on the other hand didn't.
 
A few Q's about the Saturn and emulation

Your framebuffer argument is not only wrong, the opposite is true. The Playstation video architecture (the frame buffer is in fast video RAM along with all textures) allow for far trickier effects, like feedback swirls, warping effects and so on.

His point was, the Saturn hardware allows you to do certain 2D effects in hardware. With a simple framebuffer system you have to do everything in software and your graphics take up more space because you aren't using thrifty tiles (well you could use tiles, but it means even more work for the processor). This is a more flexible approach, but it's more resource intensive.
 
A few Q's about the Saturn and emulation

Originally posted by fivefeet8+Sep 15, 2003 @ 12:04 AM--><div class='quotetop'>QUOTE(fivefeet8 @ Sep 15, 2003 @ 12:04 AM)</div><div class='quotemain'> <!--QuoteBegin-antime@Sep 14, 2003 @ 12:49 PM

The criticism against the various Playstation Street Fighter ports is mainly that animation frames are missing, which can be explained by lack of video memory

But how would the slowdowns in XmenVsSF/MSHvsSF be explained on the PSx while the Saturn port exhibited few if any slowdowns. Plus the fact that the Saturn was processing a lot more frames for those games than the psx was. Maybe it's because of the way the psx did 2d? I've played both the psx and saturn versions of both games and the psx versions exhibited some moderate to severe slowdowns when doing some of the large scale supers. The saturn ports on the other hand didn't. [/b][/quote]

Just a supposition, but maybe the slowdowns are due graphics data being transfered from the main RAM into the video RAM, or even being decompressed from main RAM into the video RAM. The roots of a graphically intensive 2D game is constant texture-swapping, something the PSX might not be too good at, since 3D applications expect all their textures to be close by in the video RAM.

And let's not forget the Saturn version uses the RAM expansion, that pretty mych triples the avaliable RAM.

BTW, on the "curved" quads thing. As said before, it's caused by a limitation in the VDP1 quad drawing algorithm.

I tried to reproduce the effect in photoshop, but the darn thing doesn't supports distortions with concave quads. LOL. Anyway, Corel Photopaint to the rescue:

concave.jpg


The Saturn sorta works like that, but with less accuracy, of course. I'm not sure if SSF emulates that, but with sure neither Satourne nor GiriGiri emulate that, since they convert the quads into two triangles.

Even being a "bug", it's a cheap and dirty way to get things looking more rounded without using additional geometry. Nights and Shining Force 3 did that, maybe a few others too. But since it was labeled as a "bug", and due to experience, many developers kept their quads in the same plane.

A rough explanation token straight from one of the Sega's docs:

Link
 
A few Q's about the Saturn and emulation

Ah, I found a much nicer example.

These shots were taken from the Saturn's SDK SG3 file editor. It's renderer is very similar to the Saturn's, even the wacky gouraud shading.

But the editor's renderer won't curve non-textured quads, and the light-calculated gouraud often goes wrong when the quads becomes concave.

terrain1.jpg


Look! Curveys! :p

terrain4.jpg


The shot below shows the edges behind the "curved" quads:

terrain5.jpg


It's worth a note that, while the Saturn's gouraud shading had it's flaws (aggravated by the lack of color dithering), it could produce smoother-looking terrains, since it was quad-based, instead of triangle based, and would look right in all directions, while you can easily find the diagonal edges in a triangle grid.
 
A few Q's about the Saturn and emulation

Thanks for the info and pics guys. What about the sound chips in the saturn? How comparable are they to the Psx's sound chips?

I can see why emulating the saturn could be a hard undertaking.
 
A few Q's about the Saturn and emulation

The Saturn sound system is driven by a Motorola 68EC000 running at something like 11.5MHz (don't recall the exact number). The sound hardware is the YMF292, a semicustom (it seems to be a version of one of Yamaha's preexisting chips with a dual CPU interface) Yamaha synthesizer/mixer chip with 32 channels. It can apparently do FM/PM synthesis, but it's not clear to me how that is set up. The DSP is fully programmable, but the instruction set doesn't seem to be publicly documented anywhere. I suspect that the hardware is a bit superior to PSX's sound system, which has no dedicated CPU and a "black box" DSP that can only do the supplied operations, and much harder to emulate accurately than the PSX sound system because there are two CPU interfaces as well as a programmable DSP.
 
A few Q's about the Saturn and emulation

The SCSP has 32 "sound slots". Each slot can either play PCM or function as an FM oscillator. You can freely mix the two, so an FM osc. can modulate a waveform or vice versa. The main drawback of the Saturn's sound capabilities is the 512KB of memory you have to squeeze the controller program, sound data, music data, DSP parameters and the sound stacks into. By contrast, the Playstation has the same amount of sound RAM, but it's used only for compressed samples.
 
A few Q's about the Saturn and emulation

AFAIK the SPU uses some of that RAM for effects calculations too, it's not exclusively for samples.
 
A few Q's about the Saturn and emulation

Some screencaps from an actual Saturn. Notice how the effect only occurs with concave polygons, but even convex polys are drawn slightly outside the edges of the polyline. The program (with sources) can be downloaded from my site.

TV2003091823474800.png

TV2003091823480000.png

TV2003091823482500.png

TV2003091823484200.png

TV2003091823485500.png

TV2003091823491800.png

Sorry about the poor quality of the caps, anyone got an S-video cable they could spare?

I also spent some time playing NiGHTS (oh the things we suffer in the name of science) and I'm almost certain that the Soft Museum level is done by subdividing the nearest polygons. In some cases you can see how the "pit" under you is made out of lots of tiny flat surfaces.
 
Back
Top