| Home | Forums | What's new | Resources | |
| A few Q's about the Saturn and emulation |
| fivefeet8 - Sep 12, 2003 |
| 1 | 2 | Next> |
 |
Mr. Saturn | Sep 12, 2003 | ||
|
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... | ||||
 |
fivefeet8 | Sep 12, 2003 | ||
|
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? | ||||
|
fivefeet8 | Sep 12, 2003 | ||||||
A few Q's about the Saturn and emulation
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. | ||||||||
 |
ExCyber | Sep 12, 2003 | |||||||||||||||
A few Q's about the Saturn and emulation
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.
Generally speaking, yes.
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).
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.
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 | |||||||||||||||||
|
fivefeet8 | Sep 12, 2003 | |||
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. <_< 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. | |||||
|
ExCyber | Sep 12, 2003 | |||
A few Q's about the Saturn and emulation
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. | |||||
 |
AntiPasta | Sep 14, 2003 | |||
A few Q's about the Saturn and emulation
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? | |||||
 |
antime | Sep 14, 2003 | ||
|
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. | ||||
|
fivefeet8 | Sep 14, 2003 | |||
A few Q's about the Saturn and emulation
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. | |||||
|
Mask of Destiny | Sep 14, 2003 | |||
A few Q's about the Saturn and emulation
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. | |||||
|
M3d10n | Sep 14, 2003 | |||
A few Q's about the Saturn and emulation
| |||||