Questions about Sega Saturn
- Thread starter Liandry
- Start date
It's PRINTED...end of year quarterly report or ytd sales...other Japanese publications also printed and published sales figures of note in 1995, 1996, 1997, 1998 and 1999.
Iirc 1996 had the last 16bit sales reports.
If you say so...however this post makes your knowledge of that era really clueless...it's quite easy specially if you spend so much time a Sega Saturn thread to find the data...which was also printed back in 1994 as upcoming games and 1995.
Virtua Fighter 1 was promised for Sega of America's 32X which released late in 1995.
Sega's AM2 had 1994-1995 with Sega Saturn and 32X. As well as the ROM based ST-V Arcade hardware...as well as the $10,000.00 plus high end Sega Model 2 which officially had the 1993 testing of Daytona USA and the 1994 full version Daytona USA. As well as doing preparation for Sega Model 3 development which iirc saw two games released in 1996.
Your arguments are about ridiculing the hardware Sega made versus the Sony PlayStation and that's really all you do...you insinuated or instigated the word "conspiracy" as a way to dismiss anything positive or informative about the Sega Saturn...
I wasn't aware initially that you were in the U.K. or Europe PAL region which was initially affected by the lack of focused development. However the U.K. alone* (or let's focus on third-party devs there) was a region where game devs didn't fear assembler coding and didn't fear complex "hard to dev for" Saturn....and those devs' contributions stand out big.
North America had some devs who were similar but it was also where the whole C compiler complaining and comparisons were being made by unnamed developers...
I know you weren't an early adopter...so you didn't say what a lazy crapfest when playing the 2d Saturn Mortal Kombat II after playing the 2d PlayStation Mortal Kombat 3...despite different dev teams...it was a 2d game...with Sega Saturn being known to have significantly more ram and faster load times...unless there was what can be called a deliberate crap job.
The same Sega internal dev team that handled the 32X Virtua Racing Deluxe was tasked with porting the Saturn version of Sega Rally Championship 1995...a Sega Model 2 game released in 1995...with a development cycle stated to be around six months.
And a bonus if you lived in the U.K. as they (Maximum magazine iirc) actually interviewed them and were informed about the fast paced schedule and how they wanted to add features but couldn't...
Now would it be fair to say that if no SoA 32X fiasco existed and that same dev team...CS Team was instead tasked to handle Saturn version of Virtua Racing Deluxe (again unlike how it was handed over to a third party due to what was going on) then you would eliminate a lot of the initial teething problems even if Sega Rally was still ported for December 1995 release?
Sega AM2 did directly handle porting of Virtua Fighter 1, Gale Racer and Daytona USA while Virtua Fighter Remix was a Sega ST-V Arcade hardware game and we can definitely argue that there was very MUCH rushed paced development before they started work on Virtua Fighter 2...along with pressure from Western game magazines on the subject of the Sega Graphics Libraries...an interesting topic that only those western magazines made a big deal about early in 1995 released magazines...specifically Edge-Next-generation which posted an infamous Yu Suzuki "quote" from development version of Virtua Fighter 1 which DOES NOT appear in ANY of their previous and only U.K. released magazines.
But sure as hell was used as mud to...smear the Sega Saturn after it's sold out Japan launch. Bias? Conspiracy? Paid off?
On a related note, me and a friend are running a small game store and we got an old TV monitor for the sake of retro gaming. Today we connected it with a Saturn and tried some Sega Rally.
The memories.
My friend modded his Saturn to include a fan, a LED screen for monitoring temperature,
Truly bizarre...reading that... even the Japanese launch day Sega Saturn didn't require some fan...or any cooling system...
Internal engineering sample and development prototypes...sure...but by launch Sega/Hitachi hit their die shrink targets...with numbers not much different than what was announced in September 1993 Japan and later further revealed in the Spring/Summer Tokyo Game Show event.
PlayStation did have a type of heat spreading heat sink thingy that isn't the type of heatsink we would know of in PCs
And I could be wrong but even premium Sega Model 2 didn't require a cooling fan...unless it was for the power supply.
Last edited:
Does it specifically specify sold to retail or sold to consumers?
Nobody questioned the existence of the 32X
Your argument goes like this:
Sega has X amount of platforms making games on , therefore I assume that the result was bad on the saturn because that's "common logic". Again nobody questioned that Sega had various platforms. Regardless that is NOT factual evidence that the games eventually released on the Saturn were visually compromised because of that.
All your argument about games not being good enough due to the existence the Arcades or 32X is based only on an that assumption.
Different teams were working on various games and the few Arcade to Saturn ports were usually released AFTER the original arcade version was made. So lets ignore VF1 since it has never never used as an example of the consoles capabilities.
Despite some Saturn games were also on the arcades (and many others werent), the Saturn ports were being developed usually after the arcade release, and whatever result we got was subject mainly to the hardware capabilities of the console.
Essentially most of the Saturn's life we had Arcade Games ported LATER to Saturn, Arcade games NOT ported to Saturn, and games exclusively made for the Saturn. Sega had various teams working on different projects.
The arcade games were simply BRILLIANT so thats evidence that Sega was pulling off great games regardless of number of platforms. Its not like they were simultaneously making 10 versions of the same game to meet all platforms. Far from it. The fact that great arcade games were done and were ready to be ported to the Saturn also makes it easy to assume that the Saturn's games development was benefiting from the arcade platforms. Sega was traditionally operating in the arcade and home console industry before the Saturn anyways.
If and by how much a specific Saturn port was affected by 32X is up to speculation not a fact. You cant quantify that.
Nobody mentioned a "conspiracy" that tries to make the Saturn look better than it is.
Its the fact that developers and people with better knowledge contradict the overblown claims usually made by people like you and other Sega dedicated fans. Their know how also falls in line with the results we see in the games themselves.
Ahm..... gamers from around the world were playing games made from around the world and thus this statemented is irrelevant.
Games under a tough schedule is a common thing. Sega Rally Championship was not a new project made up from scratch for the Saturn.
Regardless knowing how great the Arcade looked and how good it looks on the Saturn, it looks like a great port in line with what we were expecting at the time.
Show me the articles and then we will discuss or tell me which issue and I will find it. The exact interview is a better argument than any probable misinterpretation from bad memory.
Features could mean anything
??
My friend installed the fan just as a precaution because he values the Saturn model he modded a lot. Its a perfect console for playing all regions and at their intended speeds.It doesnt necessarily means it is needed.
I didnt mean to imply that it already had a fan. If I recall it originally didnt
Last edited:
HokutoNoKen
Newcomer
Game Sack presents Playstation vs Sega Saturn (video contains some hardware spec etc.).
/ Ken
/ Ken
HokutoNoKen
Newcomer
PS1:
CPU: 1x 32-BIT RISC @ 33.8Mhz
Colors: 16,777,216
GPU: 500,000 Flat shaded 32-pixel poylgons per second.
2D Tile Fill Rate: 8-bit Color/Tile - 67MPixels/s, 15-bit Color/Tile - 33M Pixels/s.
Textured Gouraud Shading: 100,00 Polygons/Sec [8-bit Color]
Max Res: 640x480
Min Res: 256x224
VRAM: 1Mb
Polygons: Triangle
Sound: 24 Channels PCM, MIDI (Decompress sound in real-time).
Sega Saturn:
CPU: 2x 32-BIT RISC @ 28.6Mhz each
Colors: 16,777,216
GPU: 800,000 Flat shaded 32-pixel poylgons per second.
2D Tile Fill Rate: 8-bit Color/Tile - 570MPixels/s, 15-bit Color/Tile - 560M Pixels/s.
Textured Gouraud Shading: 140,00 Polygons/Sec [15-bit Color]
Max Res: 704x480
Min Res: 320x224
VRAM: 1.5Mb
Polygons: Quads
Sound: 32 Channels PCM, FM, MIDI, LFO.
/ Ken
CPU: 1x 32-BIT RISC @ 33.8Mhz
Colors: 16,777,216
GPU: 500,000 Flat shaded 32-pixel poylgons per second.
2D Tile Fill Rate: 8-bit Color/Tile - 67MPixels/s, 15-bit Color/Tile - 33M Pixels/s.
Textured Gouraud Shading: 100,00 Polygons/Sec [8-bit Color]
Max Res: 640x480
Min Res: 256x224
VRAM: 1Mb
Polygons: Triangle
Sound: 24 Channels PCM, MIDI (Decompress sound in real-time).
Sega Saturn:
CPU: 2x 32-BIT RISC @ 28.6Mhz each
Colors: 16,777,216
GPU: 800,000 Flat shaded 32-pixel poylgons per second.
2D Tile Fill Rate: 8-bit Color/Tile - 570MPixels/s, 15-bit Color/Tile - 560M Pixels/s.
Textured Gouraud Shading: 140,00 Polygons/Sec [15-bit Color]
Max Res: 704x480
Min Res: 320x224
VRAM: 1.5Mb
Polygons: Quads
Sound: 32 Channels PCM, FM, MIDI, LFO.
/ Ken
The Sega Saturn is a perfect example of hardware specs having little to do with what actually happens in game. Sure, you can look at the numbers and draw a conclusion, and that will be sometimes right. You can also look at some oddities like polygon primitives, or the resolutions it supported and draw some conclusions, and they can also often be right. But there are plenty of examples of the Saturn falling short of it's contemporaries, and more than a few of it outperforming them. And they don't always fit in the neat little boxes the people try to fit them in.
While looking at the SegaRetro specs again I found they embedded this VDP1 tutorial:
https://segaretro.org/index.php?title=File:TUTORIAL.pdf&page=2
It actually gives cycle times for both primitive setup and fillrate. Textured non-shaded quads have 70 cycles setup and textured gouraud-shaded quads have 302 cycle setup. It also takes 16 cycles to fetch a command, but while this isn't explicitly stated I'm going to assume that it's pipelined and occurs at the same time as setup.
Then the fill rate is (x * y * 3) + (y * 5) cycles for any textured quad. Minimum texture size is 8x1, so 29 cycles.
That means the max quad rate is about 288K/sec for unshaded and 86K/sec for shaded. SegaRetro gives values that are twice as high because they have this bizarre and completely unexplained notion of "parallel cycles" where two cycles are executed per clock... This is also the source for 140,000 cycles/polygon figure above. Maybe the SegaRetro writer thinks that both framebuffers are rendered to simultaneously?
For the fill rate numbers, it seems that it refers to the source texture size. But the size of the primitive on the screen is probably also pertinent, because texels have to be duplicated to fill the destination lines. So the real number is probably something like max(texture_pixels * 3, screen_pixels * 3) + (screen_rows * 5). That is, unless the option to skip every other texture pixel is enabled, in which case texture_pixels can be divided by 4 and screen_pixels would usually dominate. I'm using screen_rows under the assumption that VDP1 can skip whole texture lines that aren't displayed but I don't know that for sure. Note that screen_pixels will usually be higher than the number of pixels seen on the screen because of internal overdraw.
This limits the fill rate to 3 cycles per pixel. That sounds bad but it's not really that surprising given that VDP1 is a forward renderer and accesses its framebuffers at any angles and therefore could need up to to one row address change every pixel, and that they didn't bother optimizing for bursts when consecutive pixels are next to each other, which is also not really that surprising.
This yields a maximum textured quad fillrate of about 9.5 MPixel/s.
I'm going to assume that non-distorted quads (that are guaranteed to have entire row spans at consecutive locations) could at least get a better fillrate, so normal 2D games should have a much better sprite fillrate.
https://segaretro.org/index.php?title=File:TUTORIAL.pdf&page=2
It actually gives cycle times for both primitive setup and fillrate. Textured non-shaded quads have 70 cycles setup and textured gouraud-shaded quads have 302 cycle setup. It also takes 16 cycles to fetch a command, but while this isn't explicitly stated I'm going to assume that it's pipelined and occurs at the same time as setup.
Then the fill rate is (x * y * 3) + (y * 5) cycles for any textured quad. Minimum texture size is 8x1, so 29 cycles.
That means the max quad rate is about 288K/sec for unshaded and 86K/sec for shaded. SegaRetro gives values that are twice as high because they have this bizarre and completely unexplained notion of "parallel cycles" where two cycles are executed per clock... This is also the source for 140,000 cycles/polygon figure above. Maybe the SegaRetro writer thinks that both framebuffers are rendered to simultaneously?
For the fill rate numbers, it seems that it refers to the source texture size. But the size of the primitive on the screen is probably also pertinent, because texels have to be duplicated to fill the destination lines. So the real number is probably something like max(texture_pixels * 3, screen_pixels * 3) + (screen_rows * 5). That is, unless the option to skip every other texture pixel is enabled, in which case texture_pixels can be divided by 4 and screen_pixels would usually dominate. I'm using screen_rows under the assumption that VDP1 can skip whole texture lines that aren't displayed but I don't know that for sure. Note that screen_pixels will usually be higher than the number of pixels seen on the screen because of internal overdraw.
This limits the fill rate to 3 cycles per pixel. That sounds bad but it's not really that surprising given that VDP1 is a forward renderer and accesses its framebuffers at any angles and therefore could need up to to one row address change every pixel, and that they didn't bother optimizing for bursts when consecutive pixels are next to each other, which is also not really that surprising.
This yields a maximum textured quad fillrate of about 9.5 MPixel/s.
I'm going to assume that non-distorted quads (that are guaranteed to have entire row spans at consecutive locations) could at least get a better fillrate, so normal 2D games should have a much better sprite fillrate.
Last edited:
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.
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.
Sure, there's no reason they couldn't do anything the console is capable of, if they put in enough work.
So....what are the skills required for it?
This seems like a pretty broad question. It really depends on what you want to do and how well, and what the standard for comparison is.
If you want to do a 3D Saturn game that exercises all of the hardware efficiently you need to understand the full 3D transform pipeline because there's no hardware to do that for you. You need to really think outside of the usual graphical boxes to get creative with the VDP2. It's pretty obvious to use normal layers for the skybox and HUDs and a rotation layer for the ground, but a lot of thought needs to be put in how to most effectively composite VDP1 and VDP2 output. This means knowing how to sort and blank out polygons that appear behind the VDP2 ground layer, and render graphics that actually create depressions in the ground instead of items on top of it.
You have to know a lot about batching and load balancing to make good use of both SH2s and this is something you probably need to design out in your high level architectural plans before doing much coding. Trying to get anything good out of the SCU DSP needs the same skill and forethought but it's much, much worse because you have to deal with a much more limited communications path, a very difficult assembly language, and a very limited code and data space. It's really not very realistic to use the SCU DSP outside of a very carefully architected yet very limited and straightforward task, like a pre-process or post-process filter. You can try to use it to help with 3D transforms but it's going to be really hard to make that work out well.
Then there's the entire audio subsystem. Unless you've got a very skilled audio engineer on the team it's going to be really hard to make good use of all this. But I'd also wager that there isn't really that much quality to be gained by going full tilt with all of its chips. If you only use the 68k as a simple sequencer, the sound chip for sampled mixing and enveloping, and maybe the SCSP DSP for a reverb filter and an FM channel or two for really complex instruments, then you'd be way ahead of the curve.
And in the end of the day, none of this is really going to matter if you aren't working with very good composers and artists.
Jollyroger
Newcomer
Very well explained indeed, Exophase.
I don't mean to barge in, this is my first post here, but I'd like to add a couple of comments, based on what I remember from back in the day (when I was still developing games), and more recently (when I did some experiments with Sonic X-Treme).
First of all, as you already discussed, the time constraints dictated by making games as a business meant that in general, given a game design, a certain amount of time and a group of developers, the most effective console to develop for (HW architecture, software tools and libraries, documentation, sample code, technical support, developer resources) would most likely yield a higher quality game.
Even with exclusive titles one can only go as far as it makes financial sense, and this means optimization and performance tuning to the death is not always attainable.
I was lucky enough to be at both the PS1 and the Saturn launches in Europe and sank my teeth in both the development systems over time, and later the N64 (and then several others).
In my humble opinion the Saturn is the console in that generation that had the most complex architecture and therefore left the most potential untapped, when compared to the competition. This is not to say that developers could have made it run twice as fast, and different kinds of games would have benefited by a considerably different margin, but rather that Sega initially handed developers quite terrible development systems/tools and at some point (still pretty early, in the grand scheme of things) gave up on the machine and developers reduced their investment/time/exposure and thus never squeezed the machine to its fullest.
On the other side, Sony kept pushing the Playstation hard, with strong marketing campaigns, signing more exclusive titles, dedicated developer conferences, better and better tools and libraries.
Among the many possible examples of this is the Sony DTL-H2700 development hardware, which includes easily the most sophisticated performance analysis profiler of its time. Nothing else was even close. I have one of them and to this day I use it sometimes to see the differences in the use of the machine developers had on early games vs. late games.
With that kind of instrument, it has been possible to obtain an amazing level of performance tuning on the Playstation; nothing of sorts has ever been available on Saturn, and even the last version of the SDK libraries released to Sega developers were years behind in terms of sheer scope and level of platform exploitation, when compared to Sony's (which weren't all that phenomenal either at the end of the day).
The necessary level of deep understanding of the system and trial-and-error required to make Saturn shine was a luxury that few could afford, and so even the brightest developers used relatively few "tricks" to make the chipset perform, before they moved on to other platforms/games. A shame in my view, as even with its idiosyncratic design, games can be designed and implemented on it that are amazing to behold and a joy to play, but instead Sega turned its back to it for a variety of reasons.
At any rate, to answer a question from Nesh, parallel processing was not a very common skill in the 90s (one could argue that it is still not exactly ultra-widespread even now), and juggling the Saturn chips was tricky at best due to puzzling system design choices (e.g. the two SH2 on a single common bus, which made it even harder to exploit parallelism). The SCU DSP warrants a special mention, a classic VLIW beast that could in certain conditions execute 6 operations per (14MHz) clock... Writing appropriate and efficient code for it required a substantial investment of skills and time to handle DMA in and out of its small memory pool, effective timing, code structure, etc., and thus it has been arguably never been used at its full potential, even considering its quirks and limitations.
Funnily enough Sega, which at that point were very expert in using DSPs in their arcade systems, backed off from that approach for their next generation machine and moving towards ease of development, while Sony in the PS2 opted for having a somewhat similar concept with the VU coprocessors, and then again with the Cell SPUs...
I love all games consoles and all other computer graphics systems, I love discussing these older machines and they probably date me pretty accurately; I hope to contribute to the conversation on how they worked...
Jollyroger
I don't mean to barge in, this is my first post here, but I'd like to add a couple of comments, based on what I remember from back in the day (when I was still developing games), and more recently (when I did some experiments with Sonic X-Treme).
First of all, as you already discussed, the time constraints dictated by making games as a business meant that in general, given a game design, a certain amount of time and a group of developers, the most effective console to develop for (HW architecture, software tools and libraries, documentation, sample code, technical support, developer resources) would most likely yield a higher quality game.
Even with exclusive titles one can only go as far as it makes financial sense, and this means optimization and performance tuning to the death is not always attainable.
I was lucky enough to be at both the PS1 and the Saturn launches in Europe and sank my teeth in both the development systems over time, and later the N64 (and then several others).
In my humble opinion the Saturn is the console in that generation that had the most complex architecture and therefore left the most potential untapped, when compared to the competition. This is not to say that developers could have made it run twice as fast, and different kinds of games would have benefited by a considerably different margin, but rather that Sega initially handed developers quite terrible development systems/tools and at some point (still pretty early, in the grand scheme of things) gave up on the machine and developers reduced their investment/time/exposure and thus never squeezed the machine to its fullest.
On the other side, Sony kept pushing the Playstation hard, with strong marketing campaigns, signing more exclusive titles, dedicated developer conferences, better and better tools and libraries.
Among the many possible examples of this is the Sony DTL-H2700 development hardware, which includes easily the most sophisticated performance analysis profiler of its time. Nothing else was even close. I have one of them and to this day I use it sometimes to see the differences in the use of the machine developers had on early games vs. late games.
With that kind of instrument, it has been possible to obtain an amazing level of performance tuning on the Playstation; nothing of sorts has ever been available on Saturn, and even the last version of the SDK libraries released to Sega developers were years behind in terms of sheer scope and level of platform exploitation, when compared to Sony's (which weren't all that phenomenal either at the end of the day).
The necessary level of deep understanding of the system and trial-and-error required to make Saturn shine was a luxury that few could afford, and so even the brightest developers used relatively few "tricks" to make the chipset perform, before they moved on to other platforms/games. A shame in my view, as even with its idiosyncratic design, games can be designed and implemented on it that are amazing to behold and a joy to play, but instead Sega turned its back to it for a variety of reasons.
At any rate, to answer a question from Nesh, parallel processing was not a very common skill in the 90s (one could argue that it is still not exactly ultra-widespread even now), and juggling the Saturn chips was tricky at best due to puzzling system design choices (e.g. the two SH2 on a single common bus, which made it even harder to exploit parallelism). The SCU DSP warrants a special mention, a classic VLIW beast that could in certain conditions execute 6 operations per (14MHz) clock... Writing appropriate and efficient code for it required a substantial investment of skills and time to handle DMA in and out of its small memory pool, effective timing, code structure, etc., and thus it has been arguably never been used at its full potential, even considering its quirks and limitations.
Funnily enough Sega, which at that point were very expert in using DSPs in their arcade systems, backed off from that approach for their next generation machine and moving towards ease of development, while Sony in the PS2 opted for having a somewhat similar concept with the VU coprocessors, and then again with the Cell SPUs...
I love all games consoles and all other computer graphics systems, I love discussing these older machines and they probably date me pretty accurately; I hope to contribute to the conversation on how they worked...
Jollyroger
I'm glad we can all agree that the Sega Neptune was the best and we still need one today!
What a great first post man! I apreciate your imput and stories very much.
After reading your post I want to express that its tragic that we will never see an example of the full potential of the console, or what creative ways of using the hardware will look like.
This is why I asked about homebrew. Thats the only way we could see something if ever and I wish we could. Because near the end of the Saturn we did get some pretty interesting results that originally weren't thought possible and yet based on what you said even those examples most likely left a lot of potential out.
Panzer Dragoon Saga for example had production values and attention to detail that approaches that of Naughty Dog's. You can only wonder "what if" they had the money and time to reach even higher?
Despite Sega's huge financial trouble its super talented team was bringing out excellent and unique games.
Jollyroger
Newcomer
Indeed. Some machines, usually the more complex ones, tend to reveal only after quite some time, as developers find interesting ways to use their hardware. This is the primary reason I personally prefer flexible, complex machines to powerful but narrowly focused ones. Of course this is very naive in the real world of games development as a business, but from a perspective of purely technical challenge and creativity in software development, I believe that nothing beats the pleasure of working on those machines. Clearly games have to be written towards the strengths of those systems, but then they can be truly amazing. The more successful a platform is and generally the more the developers find ways (over time) to exploit distinctive effects, features, that sometimes are beyond what those systems designers had in mind...
