Damn right.Quote:
Originally Posted by Lan Di
Printable View
Damn right.Quote:
Originally Posted by Lan Di
I'm rather glad to not be the only one that thought Symphony of the Night on the Saturn was a poor port, it's an opinion very few other Saturn enthusiasts seem to hold.
The Saturn version of Symphony is a bad port. There is no excuse for the slowdown, the dithered transparency, or the long load times that fail to utilize the load segments at_all. Since the source material doesn't seem a generation above a late gen SNES game to me there is really no excuse for these issues. This is one of many reasons that I think Konami is an overrated developer.
It's a disappointing port overall but it's worth having if you already own the PS1 original and you like playing as Maria for something different.
I did end up keeping the Saturn version and selling the PS1 version, mainly because I got the Saturn game for $30 and liked playing as Richter (without a code?). The S-Video on my Saturn was also a LOT clearer than the S-Video on my PS1 at the time, later generation PS1s and my PS2 eliminate that advantage though.
Umm, I don't see how this could be possible. The Saturn's VDP1 is slower than the PSX GPU, and the SH2s are slower than the GTE of the PSX too, so raw 3D math and polygon drawing are inherently superior on the Saturn. (in terms of raw quad vs triangle rendering counts) The PSX is also very fast at rendering 2D scaled sprites (faster than the Saturn -and faster than drawing 3D textures), so that wouldn't be an advantage either. (and many PSX games cut back on CPU/GTE/GPU overhead by using 2D scaled textures)Quote:
Originally Posted by Kamahl
The main advantage the Saturn would have is in VDP2 resource (PSX GPU bandwidth would get eaten up using that) and possibly for gouruad shading, though I'm not sure the Saturn is actually any faster at g-shading than the PSX. (and anything gained in speed must be weighed against the limited capabilities of additive lighting effects -since the Saturn doesn't support multiplicative lighting, thus limiting lighting/shading effects substantially -compared to PSX/N64/Jaguar/3DO/highcolor PC -and some 256 color renderers too, namely those catering to linear light/shade gradients for shading LUTs)
The worst case is for flat shaded polygons and cached textures (which the PSX handles at 66 Mpix/s -rasterization overhead aside) while sustained texture mapping is a more modest gap over the Saturn at 33 Mpix/s (g-shaded polygons are similar to that iirc), though actual rasterization speed would vary. (the larger the polygons, the more drawingis fillrate limited, the smaller the polygons, the more they're rasterization limited -and then there's 3D math limits and CPU overhead for game logic, Z-sorting, etc -though the former will always be faster than the Saturn and the latter will usually be faster too due to SH2 overhead for 3D math -and, to some extent, limited real-world performance of dual CPUs)
That's not to say that the Saturn couldn't reasonably keep up with the PSX in 3D, but I don't see how it could beat the PSX in polygon and/or sprite drawing speed.
This is obviously going off topic (I forget the most recent thread this was addressed in ;) -maybe the 5th gen tech one), but:
Yes, lots of problems/unfortunate decisions . . . from putting out too much hardware and often relatively costly/complex hardware at that -not just modest upgrades/on-cart hardware. (look at the overall history from SG-1000 to Saturn -unless you ignore add-ons, the Saturn to DC was the longest gap ever and still only 4 years)Quote:
Originally Posted by TVC 15
But ignoring all the stuff of the SMS era and early MD era, Sega had problems with trying to do too many different things at once without a coherent/collaborative plan that catered to all regions needs and also catered to stability in the company overall. (Kalinske's heavy spending was necessary to a point to make the Genesis as successful as it was, but I can't help but think they invested too heavily too soon in some areas -taking too much risk for things that weren't immediately necessary on top of spending heavily for immediate investments like manufacturing and marketing)
The Saturn and 32x issue was an obvious mess, perpetuating Sega's trend to push too much hardware too soon, but adding several new twists in this case (SoA being charged with the 32x, North America having a substantially successful platform already installed on the market, and the 32x and Saturn being released simultaneously -vs the at least 2 year gap in all other major Sega hardware releases -Mk.I, Mk.III, MD, MCD)
Plus you had the 32x as an add-on and the Saturn as a complex and expensive design. (forcing them to either price high or take bigger losses than the competition -especially with Sony's vertical integration- and also complicating software development -heavily exacerbated by Sega's problematic documentation and tools -which had already been problematic on the MD, CD, and 32x, but got comparatively worse with more complex hardware -since greater detail and accuracy in translation is needed, the MCD had already been significantly more problematic than the MD for that reason and the 32x avoided many of those problems by being developed in the US and -perhaps more so- using very basic hardware -and having good support for SH2 documentation)
And then came the mess on the software end with in-house Saturn publishing not catering to some major genres and franchises.
And then the mess of the launch (screwing up PR/contracts with developers and retailers -and consumers, wasting hype that could have been built up towards a fall/holiday-oriented release, bad price, fewer/poorer games, etc, etc)
And that botched launched wasted both resources and harmed PR in the US . . . setting them of for an even steeper uphill battle that christmas. (less resources for marketing, more resources needed to make up for the botched start, etc -and then the issues with supporting/marketing their many other platforms -including the mainstream 16-bit market, which was already complicated by the MCD and 32x)
Overall marketing suffered across the board due to those problems, and on top of the Saturn problems, the late-gen 16-bit market was almost certainly crippled by the mess. (ie reduced profits and revenue compared to what the Genesis had potential for -it could still have been quite competitive against the SNES)
OK, I could agree with some of this, but the scenario needs more context . . . namely what year you'd want to start making changes.Quote:
If anything recently I've been thinking, I actually believe Sega's issue with the Saturn was not that it had too little time, from that presupposed moment they saw Sony's tech specs in late 93' to the apparent Saturn redesign, but that they had too much time. A shorter-time frame prior to Sony hitting the market would have meant perhaps they would have considered more options before any release of the Saturn.
Stronger late gen-genesis/megadrive revenues could have been focused on until the Saturn was either farmed out or made bug free. The big 3 of late 95/early96' is emblematic of the Sega Saturn, great titles too late when it really mattered, after the presses opinions had begun forming. Exasperated by Sega rushing, with a console that really needed time and care to develop for.
Ideally (in terms of maximum stability and profitability) they probably should have started doing things differently from around 1990 onward . . . the MCD shouldn't have been released or should have been designed as a much simpler/lower cost system aimed specifically at cutting into NEC's market sector in Japan with correspoinding Japanese software support to really push that (and perhaps spreading to a niche market in the US -maybe even more successful than the real MCD due to lower price and better JP support).
Then, design the Saturn different from the start, involve the western divisions in the design and development (if not contributing to actual engineering, at least in terms of desired features -from the developers' perspectives- and price point -from management/marketing perspective) . . . and making compromises to cater to each region proportionally to their needs (within practical time/resource limitations of the engineers). Outsourcing R&D could be a possibility too, though not a necessity.
Actual release date could vary, but 1994 fit very well for the Japanese end . . . had the MCD been a big success, a 1995 JP and 1996 US/EU release probably would have worked out well. (with correspondingly more advanced/polished hardware -and software)
The Genesis (and CD) could thus have been carefully supported and transitioned into a budget market position late-gen (probably shifting during 1996 and 1997) with new software tapering off by 1997 and re-releases and ever cost-cut hardware being marketed by Sega through the end of the 90s. (if the CD had become more than a niche product, it could have fared very well as a budget system in the late 90s -hardware costs dropping dramatically, including CD drive, and media being very cheap and flexible to manufacture)
-However, in the context of late 1993, Sega's options were far more limited. They already had the MCD and MD (etc) on the market as-is with all corresponding investments and management decisions made (for better or worse) as well as a lot of resources put into Saturn R&D with most of the hardware set in stone by that point. Any redesigns would need to be relatively modest (like change in CPU and/or RAM configuration -or some other off the shelf parts, but almost certainly not any major modifications to the custom chips -the emphasis would have been on bug-fixes, fine tuning, and such by that point).
So the only other option would be the massive waste of dumping the Saturn and staring over . . . and given the time that would take, the only practical option (to at least manage a 1995 release) would have been to license an existing design in development by a 3rd party. (or going with a CPU-grunt-centric design with relatively basic custom hardware -sort of like an amped up 32x- . . . or maybe building on select areas of the Saturn's architex\cture -like building around a faster and/or more advanced VDP1)
But, to make this scenario simpler, lets say they did stick with the existing Saturn design (more or less) and also stuck to the (quite successful) 1994 Japanese launch. There's still the potential for some tweaks like CPU and/or RAM changes (like cutting back on the SH1 RAM, removing the low-RAM, etc -the dual SH2s was probably a good move for performance though, at least short of a faster SH2 -which would have been limited by the .8 micron 5V chips Hitachi was using . . . though pushing them a bit faster -perhaps close to 40 MHz- might have been practical depending on yields -actual design limits on chips using similar .8 micron 2-metal processes tended to be 50 MHz, but that was the absolute design limit -before the chip risked self-destruction- and actual limits of stability would tend to be somewhat less than that -one of the few exceptions to the 50 MHz/5V limit was with the .8 micron bipolar-CMOS hybrid used in Intel's Pentium 66 and some i486DX2-66 models, and even then the chips tended to run very hot weren't especially reliable)
But, assuming the Saturn was kept 100% the same on the hardware end and JP release date, there's still several other factors:
documentation/tool support for the Saturn (both in terms of making them available to SoA/SoE and getting them properly translated and packaged into SDKs for western software houses -as well as investing in developing a decent graphics API as soon as possible)
-The 32x issue . . . ie don't initiate that design and focus on the MD and MCD alone instead (and Saturn moving forward) . . . or maybe release a low-cost SVP cart module (ie no more than $50 -or $100 with game pack-in-), or if they really wanted to get into the lower-end in the nextgen and/or push that early in the west, then something like the Jupiter would at least have been far better than the 32x. (no CD drive/subsystem, no low RAM, fully hardware/software forwards compatible with the Saturn, but much cheaper -perhaps matching the Jaguar's 1994 price point- and, in terms of forwards compatibility, be able to be expanded to full Saturn spec via a reasonably priced add-on module released around the same time as the full Saturn, and allow all Jupiter carts to run on Saturn)
Or, even with just the Saturn alone, they could have simply pushed for better software/tool support and focused a proper launch in fall of 1995 in the US. (no 32x, continued MCD and MD support shifting into late-gen marketing mode, better marketing, better in-house software support, and better distribution/retail support)
Even with the complex and expensive design, Sega still would have been much better off and the Saturn, MD, MCD, and GG all likely would have fared much better than they did in the mid/late 90s. (Sega would have had taken bigger losses on hardware than the competition -if pricing competitively, but their PR/brand would have been much stronger, in-house software and 3rd party publishing would have been much stronger and much more profitable, etc)
The biggest problems came from the mess of management problems and conflicts in the 1993-96 period, and with those issues reasonably addressed, the Saturn (while far from ideal for Sega or the overall market in the mid 90s) would have been good enough to allow Sega to be reasonably competitive on the mainstream 32-bit market in all regions. (as it was, in sprite of their struggles, the Saturn already ended up with a very decent overall software library compared to the competition up through 1996 at least -perhaps into 1997- . . . and with the right management/marketing/PR behind it from day 1, it would certainly have had better and more plentiful software all around -and much more later on too- while having the necessary consumer/retail appeal to drive it to real, volume mass-market success in all major regions)
And a note on the "Jupiter" issue . . . you could argue that such a system would have greatly increased the shift to the 32-bit market in the US (due to low price point and early release by a huge brand name), but the counter-argument would be for the long-term trade-offs. (potential for a consistently cheaper console than all of the competition, but a split market for the Saturn, and a shift to the Saturn entirely meaning loss of that lower-priced niche . . . albeit it could cater to different market segments that weren't being addressed at all at the time, leaving the Saturn as the high-end system until it really became affordable around 1997/98 -with the MD still being left to cover the bottom-end budget market at a considerably lower price point than the Jupiter for both hardware and software -and jupiter-saturn ports would be relatively straightfoward too)
The problem is that the Saturn really wasn't rushed overall . . . certain key areas were rushed (namely the US launch), but the overall design almost certainly took several years of planning an engineering to accomplish. (and it's not really rushed in design . . . though also very costly for a practical home console and with many of the resources going to features that didn't benefit overall performance enough to merit them -reducing nominal cost effectiveness considerably . . . VDP2's 2D emphasis or VDP1's multi-bus design are at least somewhat excusable and reasonable from Sega's perspective in the early 90s, but the rest of the system still ends up being a complex and expensive mess -the overbuilt CD-ROM and sound sybsystems were big wastes that added a lot of cost to little/no relative benfit -and while very feature-rich in some areas, the Sound system ironically lacked hardware acceleration/support for sample decompression)Quote:
The Sega Saturn is really a terrible metaphor (ahem) for a a glacial Swedish drama, to develop for it you've got to loosen up and take your time, Sega's management however was a Hollywood studio getting hold of said Swedish script and trying to rewrite and green-light it as a mee-too mid-90's copycat disaster movie.
The 32x's hardware was certainly rushed (about 6 months of development), but that's another story entirely. ;)
But again, the hardware design wasn't the deciding factor for Sega. (it didn't really help, but it wasn't unworkable either)
The problems with software tools also weren't really due to being rushed . . . more an overall management problem and something Sega had been doing for a while by that point. (it just got increasingly problematic as hardware became more complex and the need for clear, complete, and reasonably translated documentation was important -let alone out of the box programming libraries -which was a non-issue for the SH2s, though more problematic for graphics . . . support for 3rd party middleware and custom APIs were also exacerbated/limited by the limited documentation)
I wasn't able to find any RE docs the last time I looked (several years ago) but I was able to find MIPS performance for the PS1 and Saturn. The Dual SH2s are rated at 50 MIPS, but I would assume that is full bore with both SH2s working on unique calculations rather than simple Master-Slave. This was also back when it was thought that the DSP could assist in polygon calculations, but I didn't find guesses on how that would affect the system. I also marked down that the PS1 CPU was rated at 30 MIPS and with the Geometry Engine the system had a max of 66 MIPS.
I've always considered MIPS comparisons somewhat senseless and more of a marketing thing, but it is an established standard too. It oddly adds up to what Kool Kitty is asserting though, and the PS1 would come out about 25% better in raw capability.
What I don't get is why the Saturn's VDP2 capabilities are so easily dismissed, or why the dual frame buffers amounting to 34% more Video RAM in the Saturn than in the PS1 is not to the Saturn's benefit.
MIPS ratings don't tell the whole story either . . . dual CPUs are never going to reach that peak (and at best are probably going to be closer to 1.7x as fast as a single CPU -more often closer to 1.5x, depending on the specific programming requirements and optimization -especially limited with old/simple CPUs with only small L1 caches and no additional buffering to facilitate highly parallel processing -albeit, slaving 1CPU to dedicated DSP-like tasks -like crunching 3D math- would be one of the better cases for making the most of the CPU time)Quote:
Originally Posted by sheath
The other issue is that the MIPS ratings (of a single CPU) don't reflect the performance needed for 3D math (multiplication and division) which, while still fast on the SH2s, isn't as fast as the peak sustained MIPS rating given (and those operations can be significantly slower than the instructions being performed most often in standard such benchmarks). The GTE OTOH is a simpler, fixed-function processor, so the MIPS rating on that will much more directly relate to the performance specific to 3D math. (plus, there's the combined resource of the R3000 and GTE . . . and the R3000 is rated for some 30 MIPS -in the same context as the SH2's 25 MIPS- so take that as you will -those also share the main bus, so you won't have both maxed out either, like with the Saturn's SH2s)
It has much better than 25% more raw capability for some things, but for pure sustained texture mapping fillrate (ie drawing opaque sprites), that's probably roughly accurate. (for 3D, you have the geometry performance advantages, for cached textures you have more than double the fillrate and same for solid filled polygons)Quote:
I've always considered MIPS comparisons somewhat senseless and more of a marketing thing, but it is an established standard too. It oddly adds up to what Kool Kitty is asserting though, and the PS1 would come out about 25% better in raw capability.
It's because those resources are only sometimes useful and otherwise wasted. With fixed framebuffers, anything but high resolution modes will waste that extra space (VDP1 has 1 MB of RAM, but usually uses more like 792 kB -for 320x224 res games vs the PSX making use of the full 1MB), VDP2 RAM only comes into play for VDP2 intensive games (and 3D games with relatively simple 2D BGs would be a much more modest advantage). On top of that, the PSX has texture look-up support for using 4 and 8-bit textures while the Saturn VDP1 (in 15-bit RGB mode) is limited to uncompressed 16-bit textures. (in paletted 16-bit mode, it can use 4 and 8-bit textures similar to VDP2, but cannot use shading/lighting/translucency effects -aside from VDP2 translucency)Quote:
What I don't get is why the Saturn's VDP2 capabilities are so easily dismissed, or why the dual frame buffers amounting to 34% more Video RAM in the Saturn than in the PS1 is not to the Saturn's benefit.
That's also ignoring the Saturn's slower main RAM (slightly slower SDRAM and much slower low-RAM) limiting bandwidth for texture updates to VRAM. (not to mention limiting CPU bandwidth too)
I'm not sure this is a fair comparison either . . . we don't know all the specifics of what the game needs. There could indeed be some areras that are hard on the Saturn . . . albeit I'd expect more of an issue with slowdown OR dithered transparencies and not both. (if they relied soely on VDP1 rendering, they could have hard rougly similar blending effects as the PSX as well as similar graphics flexibility, but with more limited drawing bandwidth -leading to slowdown- . . . while dithering would avoid the limitations of using VDP1+VDP2 BGs, and addressed much of the bandwidht issues)Quote:
Originally Posted by sheath
However there is one addition problem even with the VDP2 route: use of main RAM for animation updates. (the PSX has a higher bandwidth for DMAing data from main to video -133 MB/s vs 114- but the really big issue is for data in low-RAM on the Saturn -which is much slower still and limited to 16-bits width . . . plus, DMA takes away CPU and VDP time while handling those updates)
That's also one of the cool things about unified bus architectures (like the A8, C64, 7800, ST, Amiga, N64, and Jaguar -among others), all RAM is shared and directly accessible to all processors. (albeit there's the issue of efficient bus sharing to deal with -and the major advantages of lower cost and such)
I still say SotN is just a badly optimized port. There may be some disadvantages to the Saturn hardware, but the game isn't doing anything that's extremely demanding. There's plenty of far more demanding games on the Saturn that don't have the same performance and graphical issues that SotN has.
Agreed. Simply put, SOTN was a lazy port, similar to the PS3 version of Bayonetta.Quote:
Originally Posted by TrekkiesUnite118
It could also be that the PSX game is just as lazy too, but the architecture (and tools) just ends up catering better to that. ;)Quote:
Originally Posted by TrekkiesUnite118
I say this is the most likely scenario. We are talking about Konami after all.Quote:
Originally Posted by kool kitty89
I liked Akumajo Dracula X on the Saturn. Now granted I hadn't played the PSx version at all. But it did seem like a rushed port and again I have to ask why do companies allow this to happen at times do they not give a fuck really? I mean Sega was really bad about this shit. Did they really think those shitty ports of Toshinden was going to convert people to the Saturn? And somebody mentioned Princess Crown which happens to be one of the most overrated Saturn games ever.
Yeah me lol. The Saturn (along with the PS1 and N64) actually put me off gaming for a few years. That being said, I still sort of want one just to play Sonic 3D Blast and Earthworm Jim 2, because as much as I dislike that system I really like those 2 games and the Saturn versions are by far the best.Quote:
Originally Posted by DarkDragon