Questions about Sega Saturn

[bunge]

Castlevania Symphony of the Night was better on the PlayStation.

 

[Nesh]

Castlevania Symphony of the Night was better on the PlayStation.

To be honest that game performed significantly better on the PS1. But the Saturn version got extra content. It made the side characters playable with their own stories if I recall.

 

[tuna]

The PS1 was enjoying higher numbers of units sold to actual customers in general and it also had a shitload of Japanese games that never got localized despite its crazy worldwide success. Some of them were dead gorgeous and better than games that got worlwide popularity too.

Saturn also had loads of great games that never got released in the west.

 

[function]

Delaying the Saturn would have been better than rushing it out and cramping the Genesis.

In hindsight, I think this is definitely the case. Genesis was still popular in the America's and Europe when Sega pulled the plug on development in late 95 to focus on Saturn (hardware was dopped in 96).

And the 32X was a very clever device but completely the wrong hardware. Sega had another option in 1994 that enabled 3D games beyond the SNES and was a far simpler (and cheaper) add-on than the 32X. Their SVP was trialled in MD/Genesis Virtua Racing and was planned for a solo snap-through upgrade-cart release.

Virtua Racing was a bleeding edge, hi-speed, hi-poly game and the MD port was a rushed. Despite this the game was still really cool on MD - and yes, I still have a genuine cart copy!

The SVP could apparently do all kinds of stuff, including texture mapping (obviously with a big performance hit) and could have powered funky ass 2D effects. With an expanded memory pool and games developed using more than the 16 colours of a single layer BG layer (like Virtua Racing) the cart could have done some really cool 2D games and a mad Doom port, not to mention home versions of Star Wars Arcade and Virtua Fighter (was well into development then canned).

It was "mindblowning" back in early 94. And remember we were playing this on 14 inch (effective 13 inch) CRT tvs and not 27 in LCD PC monitors and 50 inch LCD TVs, before you all scoff like ignorants!!

(Interestingly, the MD could do horizontal and vertical line scrolling on BG layer tiles so the Blue Sky backgrounds in VR could in theory have been crudely "rotated" to match the polygon foregrounds).

(M-CD hardware was the wrong choice too IMO. Very capable, but too much spent on underused hardware elements. Ditch the mighty 12 mHz 6800, ditch the M-CD only 512KB RAM, increase the shared pool to 512KB from 256KB and save a ton on the hardware while accepting you lose a few "special stages" and have longer load times)

 

[Putas]

Graphics accelerators in cartridges were also mindblowingly wasteful.

 

[bunge]

Graphics accelerators in cartridges were also mindblowingly wasteful.

Sega had planned an expansion cartridge with the SVP chip that would accept cartridges. This would have meant you buy the extra electronics once and insert cartridges into it.

 

[Nesh]

Saturn also had loads of great games that never got released in the west.

I know. I didnt question this. This was directed to Akumaju's previous argument:

"The main problem is that Sega Saturn had a successfull launch and first year and second year in sales in Japan, outselling Sony PS1, it was even outselling N64 in that region.

That is why there are so many games that were made that did not get localized and people don't discuss or aren't aware of when they make their generalized assumptions."

The Saturn wasn't the only console that was getting a ton of Japanese games that never localized. Many games dont see their way to the west for many reasons, sometimes because they are developed by companies that make games only locally, or because they are too "japanese" for a worldwide release or because they just don't believe they will sell in other regions.

 

[Nesh]

And I simply dislike the notion that Sega of America is to blame for Saturn's demise. Some die hard fans think that, just because the Saturn was doing relatively better in Japan (with a big question mark if it was doing good in absolute terms), it is proof that Saturn had worldwide success potential that Sega of America destroyed and they make a huge amount of assumptions

 

[function]

Sega had planned an expansion cartridge with the SVP chip that would accept cartridges. This would have meant you buy the extra electronics once and insert cartridges into it.

Yeah, that was the point of my post. Not sure Putas got that.

VR was just a demo of what the SVP was supposed to do. Games built for it from the ground up could have had budgeted far more optimally and integrated with MD graphics, which were in games like the Sonics and stuff like Contra being pushed into really impressive territory.

 

[bunge]

Yeah, that was the point of my post. Not sure Putas got that.

VR was just a demo of what the SVP was supposed to do. Games built for it from the ground up could have had budgeted far more optimally and integrated with MD graphics, which were in games like the Sonics and stuff like Contra being pushed into really impressive territory.

Here’s a little back story:

 

[see colon]

(M-CD hardware was the wrong choice too IMO. Very capable, but too much spent on underused hardware elements. Ditch the mighty 12 mHz 6800, ditch the M-CD only 512KB RAM, increase the shared pool to 512KB from 256KB and save a ton on the hardware while accepting you lose a few "special stages" and have longer load times)

I think the SegaCD's main downfall was Sega's inability to market the thing properly. They put all of their marketing eggs in the FMV basket and didn't properly show how "regular" games could be better beyond CD soundtracks. There are certainly a few games that were just Genesis games on a disc with better music, but if you compare the animation in Spider-Man or Mortal Kombat to their Genesis counterparts they are certainly a half generation better. Also, if you look at the games Core made using scaled sprites (Soulstar, Battlecorps, BC Racers) to anything on the Genesis it's a wonder Sega never ported over any of their superscaler games to the system. Even if they weren't arcade perfect they would have been a fair bit better than a stock Genesis could do.

 

[Nesh]

Interestingr read

https://books.google.com.cy/books?i...u suzuki like the saturn 2 processors&f=false

 

[Nesh]

https://books.google.com.cy/books?i...u suzuki like the saturn 2 processors&f=false

 

[Sonic]

Here's some further reading.

http://www.goodcowfilms.com/farm/games/www.eidolons-inn.net/segabase/SegaBase-Saturn(Part1).html

http://www.goodcowfilms.com/farm/games/www.eidolons-inn.net/segabase/SegaBase-Saturn(Part2).html

 

[David Gámiz Jiménez]

Welcome. I'll try to answer these questions.. but it's pretty technical so it might be difficult to explain clearly.

1) This is how gouraud shading works on PS1. All of the points on the triangle have a 24-bit color value (not 15-bit). Each component (red, green, and blue) has an 8-bit value that represents a number between 0 and 2. Those values are averaged across the triangle, then multiplied by the texture color to shade it. The final color is then converted to 5-bits per component either with or without dithering. Most of the time shading doesn't increase intensity, so you can think of these values as being between 0 and 1 or having about 7-bits of precision.

On Saturn a 15-bits is used for each color, or 5-bits per component. They're averaged to represent a number between -0.5 and 0.5, which is then added to the texture color to shade it, and then it's output to the screen without dithering. So, this is inferior to PS1's method because:

a) Addition doesn't perform as correct of lighting model, so the transitions look less evenly stepped.
b) To get lighting that can go from full intensity to zero intensity the texture values have to be biased. But then this cuts off how naturally dark they can be. So you either give up dynamic range of shading or you give up dynamic range of the textures.
c) PS1's colors effectively have fractional input bits, so even when they're thrown out in the end (no dithering) they still give smoother shading transitions as the polygons move around. Similar to why sub-coordinate texel precision is desirable, something both consoles lack.
d) Dithering arguably looks better sometimes (less visible banding), especially when used in higher resolutions than 320x240.
e) I didn't mention this above, but PS1 has a more consistent averaging algorithm for the color values. On Saturn, the sprites are drawn one line at a time, and when it switches from one line to another the averaged color values are rounded down to whole numbers. PS1 on the other hand maintains 12 extra fractional bits for every value it's averaging throughout the triangle (both color components and texture coordinates)

2) The biggest why VDP1 half-transparency is rarely used in 3D (it's used all the time for 2D) is that it causes glitches because some pixels inside the sprite get drawn multiple times, so it has spots blending against itself basically creating sections that have higher intensity than they should. And these spots change a lot as the sprite's deformation changes, making it look very visually jarring unless. These glitches don't happen in 2D so long as the sprites are only scaled and not rotated or otherwise deformed.

The other issue is that VDP1 half-transparency is pretty slow. The mesh patterning feature is free and a lot of TVs at the time were pretty blurry so it looked almost the same.

I'm very sorry Exophase !!! I completely forgot this thread! And I did not get any notification, I'll try to find it and configure it now.

A long time has passed, two long years ... In this time I have researched a lot. And thank goodness, with this answer now I understand you much better! XD

1) In essence, we agree:
- We would say that the final result would be the same, or very similar, at the level of quantity degraded.
- I understand perfectly that mixing by multiplication against addition is better. What we know as it looks darker in SS and clearer in PSX. Without forgetting that the Gouraud of SS "covers" the base texture, not the mixture.
- Also that doing the degrade on quads and not on triangles also helps the final quality.
- And of course dithering helps a lot. I recently saw PSX games with and without dithering, in Gouraud it shows a lot.

2) Totally agree. I would like to add that here the transparency of PSX also has a calculation cost. Clearly inferior to that of VDP1 of SS. But I also think that there is a lot of room for improvement to use. I am convinced that this possibility has not been fully explored in SS. Only in Burning Rangers or in the games of Treasure did they address the limitations of SS transparency with intelligence and skill.

 

[David Gámiz Jiménez]

I've been thinking more about the way VDP1 and VDP2 access their dedicated RAMs.

Here is the datasheet one of the 16-bit SDRAMs variants the Saturn could have used: http://www.datasheets360.com/pdf/1496897083870865313 Saturn uses the -17. That's the 256KB version (two VDP1 framebuffers and two VDP2 VRAMs), there's also a 512KB version that's used for the VDP1 VRAM.

VDP2 is easier to decipher because there are actual registers that configure how it accesses its VRAM:

- In low resolution mode, a pixel is output once per 4 VDP2 clock cycles (at 28.6MHz or 26.8MHz). In high resolution, once per 2 VDP2 clock cycles. This is easy to verify based on resolution vs frame rate.
- There are two separate 256KB VRAM chips with fully independent buses, and each has two banks internally. So, there are four 128KB banks total.
- For each 8 pixels, up to 32 memory accesses are configured for low resolution mode, or 8 accesses for each bank. In high resolution mode it's 16 memory accesses, or 4 accesses for each bank.
- This means that each 8 pixels, which take 32 cycles, get 32 memory accesses. So the total bandwidth is one 16-bit access per clock cycle, or about 57.2 MB/s. This works if each of the two SDRAM chips can provide an access every other clock cycle.

Note that for a significant part of the time VDP2 mostly won't access RAM because the screen is in hblank or vblank, and most of the memory accesses will just be useful for giving access to the CPU, like for uploading new graphics data.

Now, how can the SDRAM chips be accessed to provide this bandwidth? The Saturn docs don't specify but it's pretty easy to surmise from the datasheet. Page 40 gives a really useful table that provides the timing in clocks. The -17 part is used, and almost certainly operated with the VDP2's 28.6MHz clock, so you can use the -17/29MHz timing numbers. You can see that an ACT to ACT cycle on the same bank is 4 cycles, this is how long it takes to perform a full random read. If you interleave the two banks and pipeline commands for one with reading data for the other you can perform two random reads in 4 cycles, or one in 2 cycles.

If bursts or same-column locality were exploited the rate could be higher. But because the accesses are arbitrarily programmed this isn't possible to guarantee, and the timing must be guaranteed because VDP2 is racing the TV beam. It doesn't have any room to buffer unexpected stalls.

So what about VDP1?

It should be possible to sustain 2 cycles per pixel at arbitrary locations there too, so long as both pixels are to different banks. This can be accomplished by interleaving the two banks in a checkerboard pattern. This would result in any consecutive pixels going to different banks so long as they're next to each other vertically or horizontally in any direction. The pixel overfill method used by VDP1 would ensure this; two consecutive pixels would not be drawn diagonally from each other.

Unlike VDP2, VDP1 can afford to do tricks to go faster by using bursts and column repeats where possible, because the time can take variable amounts. But I don't think it does.

This still raises the question of why the pixel rate is 3 cycles per pixel instead of 2, assuming that the previously linked slide is accurate. It could be that this number is not fixed but an average, and includes a typical overfill ratio of 1.5x.

And other incredible Exophase answers!

In this time I have learned a lot about the SS. I am writing an entry about the capacity of its limits for my personal blog ... and for that I am analyzing a good amount of games. Especially those where I detect good use or use of unusual features in games of SS.

I pass my data table. It is not yet translated 100% into English, but some parts are in my native language, Spanish.

It is also curious as in these last two years the emulation has also improved a lot. Mednafen is a good example of this.

NEW questions! Because I still have doubts! XD

1) Seeing your cycle analysis to draw textured quads. And the data of fill rate or texel rate of segaretro. I have doubts about knowing the number of cycles that SS consumes to draw in areas such as:
a) Flat polygons
b) Polylines
c) Lines
d) Scaled Sprite
e) Normal Sprite

And all this primitivies whit this Color calculation: Gouraud + H-T + Shadow + Luminance

2) If as I recently read from this shared book in this thread: "" If I render a 256 x 256 texture map to 1x1 quad in render the entire 256 x256 map in sigle pixel. "
In all the cases of primitives of the VDP1 this is so? Or only in the distorted and / rotated primitives? Because according to how this would affect a lot in the drawing time. Even in primitives you use VDP1 color calculation as semi-transparency or shadow. In other words, it would fill the quad in all cases in the same way. Or just do it this way with "Textures / Sprites" elements.

3) Is it possible to establish a formula to know the cycles or how much does the VDP1 CC Half-Transparent penalize according to primitive size, type, area occupied ... etc ..? We already know that you can penalize up to 6 times. But this data is not clear when it comes to optimizing its use.

4) In this time, I have "discovered" how things were done that I did not know for SS like:
a) LOD + Mip mapping ... Dept cueing, dynamic lighting by Gouraud sourced and colored ... and many effects that seemed exclusive to PSX.
b) One of them that I still have doubts, is the "tessellation". In PSX manuals there is talk of being able to subdivide the meshes. In SS games that do something similar like the Wipeout 2097 are seen. Saving the impossibility of UVW space in the textures in SS. We could conclude that SS could do something similar to PSX, which I read in the SDK uses the GTE for it.
c) The last doubt that has assaulted me is the use of Render to texture. In PSX you could see a lot, in things like big TV screens in sports games ... or various effects in full screen. But in SS no! But during this investigation I have found several cases that question me if it was possible and what cost in cycles could have for SS. In Castelvania SON, in the effect of the old photo in the intro of the game. Another case, in the pause of Tomb Raider and Loaded. The background is paused but not 3D of the game is a flat image. In Rayman, at the end of the levels in the transition 3D effect, we can see that the full-screen image is used. What is your opinion? Render to texture in SS ?? As??

5) And last question. In manuals and SDK it is clear that SS can make sound effects like echo and reverb. But does anyone know a game where it is known that it is used? I am unable to identify them. In PSX it is extremely easy to find games that use it. But in SS it is very difficult or impossible ... but theoretically it is perfectly possible. Even in theory the sound of SS is very much superior to that of PSX.

Greetings and thanks community!

 

[see colon]

Back in the day before I knew any better, I would point to the chrome effects on the title screen of Sonic R when people brought up render to texture effects on Saturn. And that's not how it was done, but.. it's sort of how it was done. According to the Gamehut video on that effect, they software render the metallic items using the slave SH2 and it's drawn as a sprite using VDP1.

 

[David Gámiz Jiménez]

Back in the day before I knew any better, I would point to the chrome effects on the title screen of Sonic R when people brought up render to texture effects on Saturn. And that's not how it was done, but.. it's sort of how it was done. According to the Gamehut video on that effect, they software render the metallic items using the slave SH2 and it's drawn as a sprite using VDP1.

OK... Well maybe "Render to texture" is to generic. I mean Render from Framebuffer to VDP1 element/s or a Total(VDP1+VDP2) Framebuffer to VDP1 element, to create a effect like Giant TV in stadium or some type the fake reflection or Fake motion blur... etc...

You maybe question, but not VDP1 Framebuffer to VDP2 Fbuffer Effects?? Like Burning Ranger Trasnparent Layer. Well, this a feature of the system. All transfer from VDP1 to VDP2. Although the use of Burning Ranger is very original and rare.

In this case you are also right. But in this types of effects, also very rare in SS, and maybe another way to explore in new homebrew soft. Are a effect like Shadow maps, projection text coordenates by software, 3D render engine... etc... Last of this case are used in the time. For example: Hexen, the scenery are render by CPU to a VDP2 screen. Or another "possible" more massive case is Firestorm Thunderhank 2. In my checks, because not run in Yabause. It looks like it's render all in CPU to VDP2 Screen.

 

[see colon]

I can't think of a single game that takes a full screen buffer and coverts it to an on screen item on Saturn. Also, i can't think of one that uses specular maps or any type of multitexture effects. From that Gamehut video I don't think they are possible.

 

[David Gámiz Jiménez]

I can't think of a single game that takes a full screen buffer and coverts it to an on screen item on Saturn. Also, i can't think of one that uses specular maps or any type of multitexture effects. From that Gamehut video I don't think they are possible.

Whit respect of the Render to texture feature. Well, I think that yes. Because are other real games(Loaded, Castelvania, Tomb raider, Rayman, Firestorm Thunderhank 2, Hexen) make very similar feature(Static and full resolution). The result is another history (Resolution, depth color, refresh, penalty... etc...)
For the Jon Burton video. Well, to question a person's word. That was a founder of TT. And actual producer of the Lego games and movies. With the professional history that it has. And that he programed by first hand the Sonic R for SS. Well, I think it's very naive. I believe that it is totally true. In fact, using the yabause emulator, which has a very complete debugger. You can see how it is just what he says. And in the case of the R of the main screen. You can move it in real time and interact with it. Also, other people have done similar things in SS, without that level of perfection: Texture Coordinate Demo by RockinB. You can download it and try it on your SS.