The single reason why SNES fans can brag about higher SNES salesQuote:
Originally Posted by zyrobs
The single reason why SNES fans can brag about higher SNES salesQuote:
Originally Posted by zyrobs
Actually, that would be Nintendo's monopoly in Japan. :pQuote:
Originally Posted by azonicrider
Without that, sales would be pretty much even, if not favorinf Sega.
Just because it becomes technically feasible with time, doesn't mean it would be economically feasible. For Sega's custom components, yes, it would have made sense to consoliudate them further (and probably switch to 3.3V power too -anything much less than .8 micron requires that). But some components are generally impractical to move on-chip, like DRAM, and others are off the shelf parts that are not cheaply/easily licensed. (like the SH2s)Quote:
Originally Posted by sheath
Now, Hitachi certainly would have had decreasing manufacturing costs to the SH2s and they did end up introducing models using newer processes (and lower voltage and higher clock ratings) within the Saturn's feasible mass market life, but as for a custom dual-processor die, I doubt that would be favorable compared to just using off the shelf Hitachi parts. (it would technically be cheaper per part to manufacture, but in practice, you'd have the overhead of hitachi custom making that for Sega and you'd lose the flexibility of supply and volume production of the standard mass market SH2 parts in use, so not really attractive within the Saturn -or PSX's- lifetimes)
In any case, the Saturn had just as much potential for cost reduction as the PSX, really, and more than the N64 (given how integrated it already was). Of course, the PSX's design was a bit leaner from the start so (even with vertical integration aside) it was always going to be cheaper to manufacture on an apples to apples basis. (similar level of technology used for improving/consolidating/cost-reducing each design, and similar margins/component costs/etc -in reality, of course, Sony had some additional advantages that deflated cost)
As the consoles aged, the actual difference in that cost would become less and less dramatic though, ad you'd start having the internal technology get cheaper and cheaper to the point where it only made up a small fraction of the total manufacturing cost. (compared to more fixed costs like PCB manufacturing, CD-ROM drive mechanism, wiring, plastic/metal case material, packaging, etc, etc)
And in any case, unless Sony actually pushed the PSX price much below $99, Sega should have had no problem continuing late-gen sales of a realistically cost-reduced Saturn as well.
Another point some people seem to miss on this is thinking the Saturn cost more to manufacture than the Dreamcast, which is simply wrong. In their respective times, the DC was indeed much leaner/low cost (ie 1998 vs 1994 Saturn), but comparing 1998/1999 technology (even with the Saturn's relatively modest redesigns)
The monopoly still existed after 1991?Quote:
Originally Posted by kool kitty89
The monopoly created the fanbase that very much existed perpetually after 1991.Quote:
Originally Posted by azonicrider
That doesn't explain the PC Engine success in Japan.
What percentage of the Japanese market did the PC-Engine take year on year, or at its best?
They still sold more than twice as much as the Mega DriveQuote:
Originally Posted by sheath
I am curious as to what went wrong with the Mega Drive in Japan, only 3.5 million during a 6 year lifespan.
Damn it still feels strange when I say Mega Drive. But I can't keep saying Genesis.
Yeah, if anybody here can shed a light on Japanese culture at the time or even today it will be a miracle. They are a confusing xenophobic/racist lot. It is possible Sega fell into the same trap as Microsoft has, being that Sega always publicized being founded by Americans I mean. It could be something else as well. Either way, Nintendo had a complete mafia-like lock down on cartridge manufacturing in Japan well through the Super Famicom days. I suspect this anti-competitive advantage is why they stuck with carts or the N64 more than any other possible reason. That again is devoid of any actual facts on the Japanese front outside of Western conjecture.
This may sound stupid, I always thought it was because the Mega Drive has a very western console design. It looks like a juke box.
The strangest things can throw off the Japs.
Yeah, and the Atari 7800 sold more than 2x as much as the Master System in the US up to 1989. :p (and almost 2x as much total)Quote:
Originally Posted by azonicrider
NEC was always a distant second to Nintendo in Japan, for a time they were catching up, but that didn't last (they kind of stagnated in the early 90s), and they did stay ahead of Sega prior to the Saturn, but that's not saying all that much given how Sega floundered in Japan. (MD was a great improvement over the SMS, but still pretty weak market share -more so if you compare software sales, from what I've seen . . . which is why the Mega CD's game sales actually pulled ahead of the MD's at some points, in spite of the much smaller Japanese install base)
The Saturn and Playstation finally broke Nintendo in Japan, and did so remarkably quickly too. (I'd argue maybe Sega and -especially- NEC could have done that the previous generation had soem different decisions been made . . . NEC in many ways had the potential to do what Sony did later on, they just didn't exploit their resources or other corporate advantages, especially outside Japan)
That still wouldn't explain NEC's relatively modest success . . . or Segas sudden massive boom with the Saturn.Quote:
Originally Posted by sheath
I think it's more to do with Japan's business culture and laws not doing anything to fight monoplistic business practices . . . though I'm less sure on why there wasn't rampant 3rd party unlicensed publishing like the US had seen with Atari/Coleco/Mattel/etc consoles. (and even quite a bit on the NES in spite of the lock-out hardware and extensive Nintendo leveraging/blacklisting)
And with NEC's huge market position in Japan's consumer (and industrual) electronics industry (and a monopoly on mainstream business computing), I'm less sure on what was up there aside from them simply not being aggressive enough in the game sector. (unlike Sony . . . and Sony very well may have learned from that) Even if NEC didn't understand the game industry that well, they had Hudson's experience to aid that, and tons of potential investment capital to build up a game division (for marketing/management, not to mention expanded R&D), which also could have included more aggressively attracting 3rd party publishers and even merging with some as 2nd parties. (or just tightly parneting for mutual benefit as they'd done with Hudson and somewhat like what Sony did with Namco)
That, and NEC's failings outside Japan probably had some impact too, in terms of Japanese 3rd party interest.
Moved from:
http://www.sega-16.com/forum/showthr...l=1#post614963
VDP1's shading works on 5-bit boundaries though (for 5-5-5 RGB), so you'd have to organize the palette with that in mind if you wanted to get any shading out of it. (that said, you could potentially get "better" lighting this way than in RGB since you could better approximate multiplicative light levels rather than additive, somewhat like 256 color PC games do except with a larger palette and logically shading to a custom colorspace rather than using look-up tables working with those 256 colors . . . you COULD do it logically in 256 colors too though -like organizing one nybble to be intensity/brightness- but I'm not sure if any PC games did that; it's also similar to the way CRY color works on the Jaguar)Quote:
Originally Posted by zyrobs
For just 256 colors though, on the Saturn, I'm having a hard time seeing how you could make that work with 5-bit boundaries, unless there's some way to work on only one 5-bit channel (igrnoring the other 10-bits normally modified in RGB), but if that was possible, it would mean the Saturn could do colored lighting/shading effects too (control over shading R-G-B elements independently or in pairs). I'd gotten the impression that the Saturn wasn't capable of colored lighting like this (which I thought was quite odd given the addedtive shading logic being pretty much exactly what you'd need for that), but given your above statement on colored lighting, it seems I was misinformed. If that's indeed possible, it would be quite nice, and potentially allow 256 color paletted graphics to have 32 logical light levels, and even close to (or exactly) linear multiplicative lighting too, unlike RGB lighting, and you could potentially even play around with some word effects using the other 3-bits of the pixel as a separate channel. (probably not a lot of use for that though)
That's what I was suggesting, though it would, again, would only work on 16 color textures using the CLUT texture format, not direct color RGB textures or "direct" (or offset) palette textures, unless you sacrificed a bunch of the palette for spading (via offset or reloading CRAM in vblank -either case much more limited color-wise than the CLUT texture method)Quote:
Changing palette entries of the textured polygons, or the colours of non-textured polygons, between each frame during the vblank period could also work.
And we're talking 256 color palette limitations too, for high res stuff, so more limited than 16-bit color depth paletted modes.
As long as the 16 entry VDP1 CLUT works, you're good for flat shading via CLUT swapping . . . provided you use a unique CLUT for each polygon and exclusively use 16 color textures.Quote:
The VDP1 can set up the framebuffer in 512x256x16, 512x512x8, and 1024x256x8 modes. For high res graphics, 1024x256x8 is the most optimal. This locks you into 8bit textures, which can only use palette (stored in vdp2 cram) or colour lookup tables (stored in vdp1 vram).
I'm not really sure what you mean by needing "an entire gradient's worth of palettes." In 256 colors, with 5-bits of that used as logical shading/intensity (or approximations thereof), you'd just need to set up the palette to be effectively 32 shades of 8 colors, but in practice, you could make some compromises to get more useful colors out of that and still have "pretty close" shades of those colors too. (though soem games could probably be tailored fairly well to use textures/colors based around a true 8 "hue" by 32 "intensity" colorspace -bear in mind you'd still have use of 256 colors/shades for actual textures/model colors, but within the limits of the custom colorspace)Quote:
I don't know if there is any limitation to using gouraud shading in 8-bit modes, beyond the RGB/palette clash. If there are none, then you could possibly use shading in normal density interlaced modes with RGB textures (for ex. in 320x480), and even in double-density interlaced modes (for ex. 640x480) with clever use of palettes. However I think you would be limited by the amount of palettes to use in this case, since you'd have to set up an entire gradients worth of palettes for every shaded colour.
Hmm, though another matter would be exactly how VDP1's shading logic alligns with each 8-bit pixel value . . . if it's still working on a word (16 bits) at a time, that could be a problem: the first pixel byte might work OK with 5-bit shading like that, but trying to do that for the 2nd pixel in the byte would end up with improper allignment due to VDP1 "seeing" it as 5-5-5-1 (or 1-5-5-5, I forget which). And if you orgnized the palette to work on the 2nd byte of each word, then it wouldn't work for the 1st due to allignment issues.
In 16-bit paletted color mode, you could avoid that given how a single pixel is still 16-bits wide, but 8-bits is problematic. (that is unless VDP1 is actually byte addressible and not word alligned, allowing you to shift the poisition of the logical pixel value on 8-bit boundaries and make it still work -albeit, pixel fillrate would thus be limited to roughly the same as 16-bit color shading)
The Jaguar's blitter uses 4 and 8-bit pixel boundaries, so that sort of thing shoudl be quite possible (custom colorspave using a 256 color palette as 4-4 Y/C), but the Saturn doesn't work that way.
Quote:
Originally Posted by saturndual32
Yes, but aside from any of the computational overhead needed for light sourcing, there'd the technical limits for actual shading.Quote:
Originally Posted by zyrobs
I'm not sure how Lobotomy did it, but if you're rendering in direct color mode on VDP1, shading is done by additive blending on the RGB channels (basically desaturating towards black or white rather than linearly fading towards black or brightening up to "max" intensity and stopping as with multiplicative lighting).
Many games have noticeable problems with this, including odd shading with colors turning to white/gray or just desaturated color/textures in general, or the whole game looking overly dark. Tomb Raider immediately comes to mind as a very obvious example of this. (way too dark, and if you turn up the gama to compensate, then everything is all washed out)
It might be possible to minimize that by customizing textures and model colors with those shading limitations in mind, or even design a game actually stylized fir the desaturation effect to its advantage.
That, and actually using a lighting algorithm that takes the Saturn's rapid destuation to black into account and doesn't just treat it as normal linear multiplicative lighting. (had tomb raider done this, a more gradual/subtle fading effect could have helped avoid the visibility problem and excessive darness at the expense of coarser shading)
It might even make sense to "dither" shading to some extent: rather than just shading to black continually, stagger (or cycle) it between shading RGB elements separately (or in pairs) to smooth out lighting by simulating in-between colors rather than continuously shading to black (or white). The color changes would be so subtle, that it should still look like just lightening or darkening and not colored lighting.
This would probably involve some added overhead for the lighting calculations though. (or at least more complex coding and some experimentation to actually determine what sort of intermittent color shading would look best)
Then again, shading in a custom "paletted" colorspace in 16-bit paletted color mode would probably be much easier to actually accomplish and would allow much better approximation of multiplicative lighting. (and potentially better/smoother lighting than the PSX does)
You can't really do colored lighting or sprite translucency in paletted mode with shading used like that. (you could sort of do weird grayscale translucency effects by blending luma in the custom colorspace/palette, but not proper blending . . . or, if you weren't using shading at all, you could organize the palette as 2 5-bit color elements usable as a 32x32 array of colors with approximated blending by averaging the color elements as with RGB -which is also how the Jaguar's CRY color blends using a 16x16 hue array oranization for the color byte, allowing averaging of the 2 4-bit color values -and then averaging the luminance byte separately)
OK, yeah, so it's probably just using paletted color then.Quote:
Seems to be the same thing, gouraud shading on paletted textures.
In fact it seems to be that the whole trick of doing gouraud shading on palettes was known from the very beginning, since the floating cubes in the BIOS used them too.
Hmm interesting notes on the VDP rotation effect layers, I wonder why the resolution is fixed like that (can't be a line buffer limitation given the fact that other VDP2 BGs can use smaller pixels).Quote:
Originally Posted by zyrobs
In any case, that would still not explain the loss in detail from arcade to Saturn. Low screen resolution has nothing to do with texture resolution or detail, so it seems much more likely to be a limitation of VDP2's RAM capacity (512 kB) and nothing more. (lower res means more jaggies, of course, but nothing to do with loss in detail) I mean, if you could run the arcade game at 320x240, it's still going to be significantly more detailed than the Saturn version. :p
On another note, that video is a great example of how the lack of lighting makes the Saturn's models look smoother compared to the flat-shaded arcade game. I remember noticing this in screenshots of the PC game too, with examples of variable detail settings applied. (I don't remember if there was a smooth shaded option too, but I remember it just being flat shaded like the arcade)
I'm not sure what Team Andromeda was on about with "smoother joints" though . . . as far as modeling goes, the Saturn is blockier, you just don't notice it given the lack of lighting to make things look all faceted.
Duke 3d seems to use 4bit CLUT sprites for the landscape + gouraud shading on them for lightning. Other sprites are 8bit.Quote:
I'm not sure how Lobotomy did it, but if you're rendering in direct color mode on VDP1, shading is done by additive blending on the RGB channels
Not many games use RGB colour polygons, they are slower to draw and use more memory.
Gouraud shading on the Saturn works by combining 2 RGB values, one taken from the target pixel, one from the shading lookup table (traditional Gouraud shading only affects the luminance). One entry in the shading table includes four (one for each vertex) 5bit RGB values, so 32 shades for each component. These values are interpolated to the target sprites size. Colour values above 16 are reduced by 16 and added, values below 16 are subtracted as is from the target pixels colour values. So in theory you can add or subtract 16 values to each colour component - for RGB sprites.Quote:
unless there's some way to work on only one 5-bit channel
If you only want to increase only one colour component, you set up the shading entries to include a colour that only has that colour component, and 10h (no change) for the other two.
Things get more tricky if you use gouraud shading on sprites with palettes, since the VDP1 will still perform the same mathematical operation on them as with RGB sprites. In this case you use red gouraud shading (the other two components are set to 16 for no operations), because those are written to the same least significant bits as the palette entries are. You are effectively using gouraud shading to go to lower/higher palette entries dynamically.
The downside is that you ultimately have less palettes to use, as you need x extra entries for every level of lightning, for every texture that is dynamically lit.
For CLUTs, they are just pre-stored colour values in VDP1 VRAM. One table has 16 entries, each 16bit long, and each entry can have any data that a normal sprites would otherwise have - so straight RGB or palette entries. The VDP1 just takes the colour entries from the table and writes them to framebuffer. Gouraud shading is probably applied on these entries after they are taken, so same thing happens as described above.
The advantage seems to be that you can swap out CLUTs on the fly, without having to redefine each palette, thus making it simpler to do coloured lightning among others.
According to the docs, anyway.
And I'm sure you do this to wind me up . Its nothing at all to do with the lighting because if one plays Fighters MegaMix which uses more polygons and features full lighting effects the joints aren't are smooth, same goes for Fighting Vipers on the Saturn (which also supports lighting) . Like Tekken 2 (which also supports lighting) Last Bronx (arcade and Saturn, VF 2 (Arcade) the characters arms just aren't as smooth and have rectangle like lines/blocks making up their Arms - something which you don't see in Saturn's VF 2 or Dead Or AliveQuote:
On another note, that video is a great example of how the lack of lighting makes the Saturn's models look smoother compared to the flat-shaded arcade game. I remember noticing this in screenshots of the PC game too, with examples of variable detail settings applied. (I don't remember if there was a smooth shaded option too, but I remember it just being flat shaded like the arcade)
I'm not sure what Team Andromeda was on about with "smoother joints" though . . . as far as modeling goes, the Saturn is blockier, you just don't notice it given the lack of lighting to make things look all faceted.
That's just a rubbish and more myths that seem to come from this board . SEGA Japan supported the Mega Drive in Japan for some 7 years plus , People forget the system came out in 1988:mad: . In fact bar the 32X SEGA and the DC SEGA supported its conoles for a lot of years and far longer than what Nintendo supported the likes of N6DD or Cube, Virtual Boy or MS with the XBox.Quote:
The parent company wanted their entire lineup axed globally and focus on the Saturn, since in Japan they had awful sales
No, not really, it has been confirmed by interviews with key Sega people, and we also know that they were asking NVidia and 3DFX as early as 1995.Quote:
Originally Posted by Team Andromeda