> I think his biggest mistake was that he underestimated how quickly the industry would switch to mainly focusing on 3D.
I think his mistake was a bit more subtle than that. Because he didn't have any experience in 3D or anyone to ask for help, he didn't know which features were important and which features could be ignored. And he ended up missing roughly two important features that would have bought the Saturn upto the standard of "workable 3D".
The quads weren't even that big of a problem. Even if the industry did standardise on triangles for 3D hardware, a lot of the artist pipelines sick with quads as much as possible.
The first missing feature is texture mapping. Basically the ability to pass in uv coordinates for each vertex (or even just a single uv offset and some slopes for the whole quad). The lack of texture mapping made it very hard to export or convert 3D models from other consoles. Instead, artists had to create new models where each quad always maps to an 8x8 texel quad of pixels.
The second missing feature is alpha blending, or semitransparent quads. The Saturn did support half-transparency, but it only worked for non-distorted sprites, and you really want more options than just 50% or 100%.
With those two features, I think the Saturn would have been a workable 3D console. Still not as good as the playstation, but probably good enough for Sega to stand its ground until the Dreamcast launched.
> The first missing feature is texture mapping. Basically the ability to pass in uv coordinates for each vertex.
These two situations are fundamentally related. Most 3D rasterizers including the Playstation use inverse texture mapping, iterating over framebuffer pixels to find texels to sample. The Saturn uses forward texture mapping, iterating over the texels and drawing them to their corresponding framebuffer pixels.
The choice to use forward mapping has some key design consequences. It isn't practical to implement UV mapping using forward mapping, and quads are also become a more natural primitive to use.
> The second missing feature is alpha blending, or semitransparent quads. The Saturn did support half-transparency, but it only worked for non-distorted sprites, and you really want more options than just 50% or 100%.
I don't consider this to be a significant problem. The checkerboard mesh feature provides a workable pseudo-half-transparent effect, especially with the blurry analog video signals used at the time.
Side note but forward mapping is also the reason why half-transparency does not work for distorted sprites. Forward mapping means that the same pixel may be overdrawn. If a half-transparent pixel is blended twice, the result is a corrupt pixel.
VDP2 can also provide half-transparent effects in various circumstances - this video provides a comprehensive look at various methods which were used to deliver this effect.
Forward texture mapping sounds like something I would have imagined as a novice before I learned how inverse texture mapping worked.
> Polygons contain diagonal lines that may result in pixel dropout (aliasing). When this occurs, holes are anti-aliased. For this reason, some pixels may be written twice, and therefore the results of half-transparaency processing as well as other color calculations cannot be guaranteed.
We have at least one examples of this being implemented in real hardware at around the same time: Nvidia's NV1 (their first attempt at a GPU) was a quad based GPU that used forwards texture mapping. And it had both UV mapping and translucent polygons. The sega saturn titles that were ported to the NV1 look absolutely great. And I the Sega Model 3 also implemented both UV mapping and transparency on quads (I'm just not 100% sure it was using forwards texture mapping).
I'm not suggesting the Saturn should have implemented the full perspective correct quadratic texture mapping that the NV1 had. That would be overkill graphically (especially since the ps1 didn't have perspective correct texture mapping either), and probably would have taken up too many transistors.
But even a simple scheme that ignored perspective correctness were the artist provided UV coord for three of the vertices (and the forth was implicitly derived by assuming the quad and it's UVs were flat) would have provided most of the texture mapping capabilities that artists needed. And when using malformed quads to emulate triangles, the 3 UV coords would match.
And most of the hardware is already there. VDP1 already has hardware to calculate the slopes all four quad edges from vertex coords and an edge walker to walk though all pixels in screen space. It also has similar hardware for calculating the texture space height/width deltas and walking though texture space. It's just that texture space is assumed to always have slopes of zero.
So that's the only changes we make. VDP1 now calculates proper texture space slopes for each quad, and the texture coord walker is updated to take non-zero slopes. I'm hopeful such an improvement could have been made without massively increasing the transistor count of VDP1, and suddenly the saturn's texture mapping capabilities are roughly equal with the PS1.
> I don't consider this to be a significant problem. The checkerboard mesh feature provides a workable pseudo-half-transparent effect
I think you are underestimating just how useful proper transparency is for early 3D hardware.
(by proper transparency, I mean supporting the add/subtract blend modes)
And I haven't put it on my list of "important missing features" because sometimes games want to render transparent objects. As you said, the mesh (checkerboard) mode actually works for a lot of those cases. And if you are doing particles, then you can often get away with using non-distorted quads, which does work with the half-transparent mode. (though, from an artistic perspective, particles would really look a lot better if they could instead use add/subtract modes)
No. Proper transparency is on my list because it's an essential building block for emulating advanced features that aren't natively supported on the hardware.
One great example is the environment mapping effect that is found in a large number of ps1 racing games. Those shiny reflections on your car that sell the effect of your car being made out of metal and glass. The ps1 doesn't have native support for environment mapping or any kind of multitexturing, so how do these games do it?
Well, they actually render your car twice. Once with the texture representing the body paint color, and then a second pass with a texture representing the current environment UV mapped over your car. The second pass is rendered with a transparency mode that neatly adds the reflections over the body paint. The player doesn't even notice that transparency was used.
Environment mapping is perhaps the most visually impressive of these advanced rendering tricks using translucency, but you can find dozens of variations spread out though the entire PS1 and N64 libraries.
Probably the most pervasive of these tricks are decals. Decals are great for providing visual variation to large parts of level geometry. Rather than your walls being a single repeating texture, the artist can just slap random decals every so often. A light switch here, a patch of torn wallpaper there, blood spatters here and graffiti over there. It the kind of thing the player doesn't really notice except when they are missing.
And decals are implemented with transparency. Just draw the surface with it's normal repeating texture and then use transparency to blend the decals over top in a second pass. Sometimes they Add, sometimes they Subtract. Sometimes they just want to skip transparent texels. And because the Saturn doesn't support transparency on 3D quads, it can't do proper decals. So artists need to manually model any decal-like elements into the level geometry itself, which wastes artist time, wastes texture memory and wastes polygons.
For some reason, VDP1 doesn't even support transparent texels on 3D quads, the manual says they only work for non-distorted quads.
> Side note but forward mapping is also the reason why half-transparency does not work for distorted sprites. Forward mapping means that the same pixel may be overdrawn. If a half-transparent pixel is blended twice, the result is a corrupt pixel.
No... This isn't a limitation of forwards texture mapping. Just a limitation of VDP1's underwhelming implementation of forwards texture mapping.
I don't think it would be that hard to adjust the edge walking algorithm to deal with "holes" in a way that avoids double writes.
My gut says this is basically the same problem that triangle-based GPUs run into when two triangles share an edge. The naive approach results in similar issues with both holes and double-written pixels (which breaks transparency). So triangle rasterizers commonly use the top-left rule to ensure every pixel is written exactly once by one of the two triangles based on which side of the edge the triangle is on.
----------
Though that fix only allows 3D quads to correctly use the half-transparency mode.
I'm really confused as to why VDP1 has such limited blending capabilities. The SNES had proper configurable blending in the 90s, and VDP2 also has proper blending between it's layers.
And it's not like proper blending is only useful for 3D games. Proper blending is very useful for 2D games too, and certain effects in cross platform 2D games can end up looking washed out on the Saturn version because they they couldn't use VDP2 for that effect and were limited to just VDP1's 50% transparency on VDP1 instead of add/subtract.
VDP1's 50% transparency already pays the cost of doing a full read-write-modify on the framebuffer, so why not implement the add/substract modes? A single adder wouldn't be that many transistors? That would be enough to more or less match the playstation, which only had four blending modes (50/50, add, subtract and 25% of background + 100% of foreground).
Though, you can go a lot further than just equality with the PS1. The N64 had a fully configurable blender that could take alpha values from either vertex colors or texture colors (or a global alpha value).
> VDP2 can also provide half-transparent effects in various circumstances - this video provides a comprehensive look at various methods which were used to deliver this effect.
> https://www.youtube.com/watch?v=f_OchOV_WDg
Yeah, that's a great video. And it's the main reason why I started digging into the capabilities of the Saturn.
> No. Proper transparency is on my list because it's an essential building block for emulating advanced features that aren't natively supported on the hardware. One great example is the environment mapping effect that is found in a large number of ps1 racing games.
That's a good point which I had not considered. However, just adding support for half-transparency wouldn't have been enough to bring the Saturn up to speed in this regard. Half-transparency is also really damn slow on the Saturn. Quoting the VDP1 User's Manual:
> Color calculation of half-transparency is performed on the pixel data of the original graphic and the pixel data read from the write coordinates. Drawing in this case slows down, so use caution—it takes six times longer than when color calculation is not performed.
This compounds with the Saturn VDP1 already having a considerable reduction in fillrate compared to the Playstation GPU. Playstation wasn't just capable of transparency, it was also damn fast at it, so emulating effects with transparency was feasible.
PS2 took this approach to its illogical extreme.
My proposed changes only really bring the Saturn's 3D graphics into roughly the same technical capabilities as the Playstation.
They don't do anything to help with the performance issues or the higher manufacturing costs. Or the string of bad moves from SEGA management that alienated everyone.
But an alternative history with these minor changes might have been enough to stop developers complaining about the Saturns non-standard 3D graphics and keep a healthy market of cross-platform games. It might have also prevented commenters on the internet from making overally broad claims about the Saturn's lack of 3D capabilities.
---------------
Fixing the performance limitations and BoM cost issues would have required a larger redesign.
I'm thinking something along the lines of eliminating most specialised 2D capabilities (especially all of VDP2). Unify what's left to a single chip and simplify the five blocks of video memory down to a single block on a 32bit wide bus. This would significantly increase the bandwidth to the framebuffer, compared to VDP1's framebuffer which uses a 16bit bus, while decreasing part count and overall cost.
The increased performance of this new 3D focused VDP should hopefully be powerful enough to emulate the lost VDP2 background functionality as large 3D quads.
Playstation indeed had unified video memory on a 32 bit bus, but the bus is only saturated when drawing 2D elements or untextured polygons[1].
Sprite-heavy 2D games like DoDonPachi already run better on Playstation than Saturn due to the faster framebuffer, while games like Spyro the Dragon, Crash Bandicoot and Final Fantasy 7 demonstrate the effective strategic use of untextured polygons.
[1] https://psx.arthus.net/sdk/Psy-Q/DOCS/CONF/SCEA/adv_gpu.pdf , slide 17.
It's basically inevitable. Any proposal for fixing the Saturn that slaps on a "optimise for BoM" requirement will be pushed towards unified video memory. And the only contemporary example of such a GPU was the playstation. Not to mention, the design of the playstation GPU appears to be pretty close to optimal for it's era and price point.
And if you were to also switch your hypothetical Saturn design to triangles and inverse texturing, the resulting design looks even more like the Playstation GPU.
> but the bus is only saturated when drawing 2D elements or untextured polygons
The Playstation's bus will also be saturated when loading the texture cache, or when scanning out the previous frame (only on the later SGRAM versions of the GPU). Even with textured triangles framebuffer writes are limited to 16bit bandwidth, less time is wasted on those other tasks which periodically interrupt rasterisation.
Though, now that I think about it, inverse texturing probably gives the playstation a massive performance advantage over and forwards texturing. Inverse texturing allows triangles to be rasterized in strict left-to-right then top-to-bottom order, which is also the order that the framebuffer is laid out in memory. This order will minimise the amount of time spent waiting for the next DRAM row to be prefeched.
The order of framebuffer writes with forwards texturing is somewhat chaotic and probably wastes a bunch more time closing and opening DRAM rows.
Saturn doesn't have a texture cache, since texel reads should be nice and sequential. But then it pays a penalty when writing to the framebuffer.
But I'm only saying that because I know write combining is a thing, and I'm not sure a hardware engineer in 1993 would have gone down that path.
AFAIK the problems lie in things like clipping/collision detection. Now that you have four points instead of three, there is no guarantee that the polygon is a flat surface.
About collision: I don't know how it is computed, but if it's by ray casting, that is now also used for lighting effects and sometimes reflections. Which would be another reason to stick to triangles.
The Nintendo DS actually supports both tris and quads as rasterization primitives, which has some interesting consequences for shading[2].
[1] https://psx-spx.consoledev.net/graphicsprocessingunitgpu/#gp...
Most games avoid using the same meshes for both rendered graphics and collision detection. Collision detection is usally done against a simplified mesh with much fewer polygons.
Since most games already already have two meshes, there isn't a problem making one mesh out of quads and the other out of triangles.
After VDP1 has rendered all quads to the framebuffer (aka VDP2's "sprite data" layer), some pixels in the framebuffer layer can use an alternative color mode. Normal 3D quads (with Gouraud shading) use a 15 bit format with five bits of Red, Green and Blue representing the final color (and the the top most bit is set to one).
Those background elements instead use a palletted color format. The top bit is zero (so VDP can tell which format to be used used on a per-pixel basis) and then there are 3 bits of priority (unused in this case), 3 bits of "Color calculation ratio" which Gamehut used to implement the fade, and a 9 bit color palette index.
So it's not just that you can't use Gouraud shading, but these fading objects are limited to a global total of 512 unique colors which must be preloaded into VDP2's color ram (well, I guess you could swap the colors out each frame)
-----
Importantly, since this trick only works against VDP2 background layers, it can't be used to blend two 3D quads against each other.
At minimum, it really needed to support the addition/subtraction blend equations.
Second, because it doesn't work correctly for distorted quads, it really doesn't exist in the context of "Saturn's 3D capablties"
I think we are basically arguing the same thing, but from my point of view I’d say the end result is visually undesirable but technically correct.
The "some pixels get randomly blended multiple times" behaviour is simply not useful. And if it's not useful, then it might as well not exist. And it certainly can't substitute for the more capable blending behaviour that I'm claiming the Saturn should have.
In another comment [1], I go into more detail about both why visually correct (and capable) translucency modes were very important for early 3D consoles and speculate on the minimal modifications to the hardware design of VDP1 to fix translucency for distorted quads, while working within the framework of the existing design.
It’s not random. Not even remotely.
> And if it's not useful, then it might as well not exist.
It is useful in some scenarios. The problem here is you’re describing it as a 3D system but it really isn’t. The whole 3D aspect is more a hack than anything
Sure, it's technically deterministic. But it's also very chaotic, as it depends on the exact position of the vertices. It's not something a game could predict and take advantage of.
> It is useful in some scenarios
I'm really struggling to think of any scenario where the chaotic pattern of over-blending might produce a desirable result. Do you have any examples?
> The problem here is you’re describing it as a 3D system but it really isn’t. The whole 3D aspect is more a hack than anything
That's an argument I strongly disagree with.
The Sega Saturn was designed to be a 3D capable system from the start. It was always intended that those distorted sprites would be used as textured quads.
Sure, the intention was for the Saturn to be a powerful 2D focused system and it's 3D capabilities were considered to be secondary (maybe even a novelty). But it's not like the Saturn was designed as a 2D-only system that some clever engineer later hacked into doing 3D by abusing the distorted sprite capability the hardware just so happened to have, just to compete with the 3D focused Playstation.
We can tell this because the "distorted sprites" have the wrong API for 2D games. 2D games kind of think about sprite transformation as putting the sprite at an origin, then applying rotation, scaling and skew to it. And if the Saturn was designed as a 2D-only console, then it's API would line up with this 2D game understanding of sprites. The resulting API would probably look like the GBA affine sprites, where you pass in a transformation matrix that expresses the scale, rotation and skew. (Actually, it's very questionable if a 2D-only console design would include the ability to skew sprites. Skewing isn't anywhere near as useful in games as scaling and rotating, and the additional hardware is a bit expensive. None of SEGA's "Super Scalar" arcade boards did skewing, and the GBA's affine sprites only support rotation and scaling)
But that's not how "distorted sprites" are implemented on VDP1. You actually control the distortion by specifying the coordinates of the four sprite corners. This is a very unnatural format for a 2D game, they have to do a bunch of extra math on the CPU to calculate how their desired transformation will affect the four corners. Even worse, this API means the VDP has to contain expensive division hardware to convert those "sprite corners" back into a form that's mathematically closer to the origin + transformation which 2D games like.
But do you know who likes the idea of stretching "distorted sprites" between "sprite corners"? That's right, 3D graphics. Just do a bit of find/replace: "distorted sprites" becomes "textured quads", "sprite corners" become "vertices", and you have an API that's actually quite ideal for doing quad-based 3D graphics. 3D games want to be able to transform their lists of vertices into new screen-space coords each frame, and let the textured quads fill in the gaps between verts. If the Saturn had a more 2D orientated API, the CPU (or DSP) would need to do a bunch of expensive math (divisions are not cheap) on those screen-space vertex coords, just to get the origin + transformation of each quad.
To summarise: The fact that "distorted sprites" take vertex coords is very strong proof that they were always intended to be used as textured quads for 3D graphics, and that the Sega Saturn was always intended to be 3D capable.
And since the Saturn was always intended to be a 3D capable system, I think it's only fair to point out it's deficiencies in that area, and explore how an alternative history Saturn might have looked if the engineers had put more focus on it's 3D capabilities.
Exactly. It’s not random. So let’s not exaggerate things please
> I'm really struggling to think of any scenario where the chaotic pattern of over-blending might produce a desirable result. Do you have any examples?
You’re deliberately misrepresenting my comment here.
You claimed that alpha blending is useless on the Saturn and I said it does have its edge cases but you need to stop thinking about the console as a 3D system. Sure, it was intended to compete with 3D systems but architecturally it’s really just a super powered 2D console.
This is why for pseudo-3D purposes, alpha blending doesn’t work well. But for 2D purposes it’s great.
Also I’d argue that the problem with 3D isn’t the alpha blending specifically but rather how order in which the Saturn renders and the use of quads.
> …APIs…
you keep talking about Saturns APIs but it wasn’t released with an SDK on launch (the PlayStation was, which is another reason behind its success with 3rd party studios). Saturns SDK came later, originally developers were expected to write assembly.
> And since the Saturn was always intended to be a 3D capable system
I doubt we’ll ever full know the truth as there are conflicting reports from people who were in Sega itself during genesis of the Saturn (pun intended).
We also know that Sega turned down Silicon Graphics (who later worked with Nintendo) and the reasons Sega turned them down is a topic of great speculation too.
There is so much folklore around the Saturn that it is hard to say anything for certain beyond the hardware architecture. And architecturally, speaking its 3D capabilities are kludge because Sega tried to hedge their bets with 2D as well.
I was on team N and I was always confused by the weird accessories of the Genesis, and the 32X’s timing always was one of the most confusing bits, but I’d never actually looked into it.
Unfortunately the combination of the 32X mistake plus the rushed Saturn launch just annoyed all partners, retail and development. It’s likely a big reason the Dreamcast did so poorly.
It was a nice system but Sega was already on their back foot, not many people trusted them, and piracy was way too easy. Their partner in MS wasn’t helpful. And then the PS2 was coming…
Piracy wasn't a big factor, since very very few people had broadband and CD-R drives in 2000. The attach rate was reportedly better than average. And the MS thing was just the availability of middleware that a few games used.
Didn’t they have to pay MS a small license fee for each unit? I’m assuming that was a drag too. Not one that killed it, but just another little kick.
I'm not sure what the agreement with Microsoft was, but it was probably on a per-game basis if the developers wanted to use Windows CE.
I knew it was per game whether the software actually used the windows CE stuff. I’m really not sure it was ever used much at all. I know the first version of Sega rally used it but it performed so poorly they had an updated version that didn’t that they put out later to fix the issues. And I’m not sure the bad version even came to the states.
One Reddit thread I see claims that Microsoft actually paid Sega for the Windows CE logo on the front of the system. But as you said, not many games used it.
Railroad tycoon for the win as a WinCE game I also didn’t mind the web browser and some of the online stuff - I only had dial up on the Dreamcast - broadband adapters were extremely rare! Plus I didn’t have broadband anyway.
Crazy taxi was a real favorite as well. I worked all summer in high school and my first purchase was a Dreamcast. I was the first person I knew in town that got the utopia boot disc, and then on from there. Discjuggler burns for self boots, manual patching - unlocked Japanese games. What a fun time!
But I've never taken it online. I'll be getting a DreamPi at some stage, but sadly shipping to where I am takes it out of "impulse buy" territory.
Piracy of CD based games in the late 90s most assuredly did not require broadband or personal ownership of a CD-R drive. A lot of piracy happened via SneakerNet. As long as you knew someone with games (legit or pirated copies) and a CD-R drive you could get your own copies for the cost of a CD-R disc. Every college had at least one person with a CD binder full of CD-Rs of pirated PC and console games. I suspect a majority of high schools at the time did as well. Dorm ResNets were also loaded down with FTPs and SMB shares filled with games, porn, and warez.
So SneakerNet and dorm rooms may have been a factor, but not enough of one to kill the system.
Oh definitely no, IME piracy was a much better issue on the original PlayStation, very quickly every other friend had a cousin who would chip your console and had access to a CD-R.
Plus didn’t the Dreamcast use some weirdo variant of CD?
Yes, GD-ROM which through some tricks could fit something like 1GB on a disc. However what most pirated discs did was just stub out the FMV. Most games that used the full space on the disc did so because of FMV. Quite a few games would easily fit on a Mode-2 700MB CD-R with the FMV stubbed out.
This was thanks to the MIL-CD functionality of the Dreamcast which was only removed in very late models.
In those days the piracy threat was less "players with broadband and CD-R drives are downloading games for free" and more "flea marketeers with CD-R burners are copying games and selling them to players for a fraction of MSRP".
I don't recall any particular difficulty in downloading games over 56k dialup around Y2K with a modem, though it was certainly a good bit faster with ISDN (and a couple of years later, 2Mbps-ish DOCSIS).
It was not fast with dialup -- it took a day or so, or longer if slowed it down to avoid what we now call buffer bloat -- but some of us had time, and a ye olde Linux box that was going to be dialed-in ~24/7 anyway.
But usually, the route to piracy that I recall being most-utilized back then involved renting a game from the video store for a few dollars and making a copy (or a few, for friends).
Perhaps the availability of burning games wasn't the right lens for me to look at it, but if the attach rate of 8 games per system is true (as I linked to in another reply) then that's similar to the NES and SNES and not at all a factor in the system's demise.
Because the DC's games were on Yamaha 1GB CDs ("GD-ROM") I doubt popping the disc in a PC and running Nero would have been possible. Most dumps were probably made using chipped consoles and a coder's cable or BBA.
The Dreamcast did use GD-ROM, which did hold up to around 1GB, and the usual way to rip those was to connect the [rooted/hacked/jailbroke/whatever-the-term-was] DC to the PC, so the Dreamcast could do all of the reading and transfer that data to the PC for processing and burning.
But even though GD-ROM could hold 1GB, a lot of DC games were (often quite a lot) less than ~650MB or ~700MB of actual-data, so they often fit well onto mostly-kinda-standard CD-R blanks of the day without loss of game data.
There were also release groups -- because of course there were -- that specialized partly in shrinking a larger (>650 or >700MB) DC title down to a size that would fit onto a CD-R, or sometimes onto two of them. (That involved Deep Magic, for the time, and implicitly involved a download stage.)
And my friends and family? I had one sibling who danced around with computers, and she had a (flaky AF, but existing) CD burner a year or two before I did, and most of my computer-geek friends were burning discs before Y2K as well.
But again, that's just my story -- which I've simplified to remove some stages from.
I don't doubt your own story even a little bit. Gaming for high-speed internet access, even in properly-large cities, was kind of the wild west around that time, and I agree that CD burning was unusual around that time.
I was a bit early for getting things done fast in my own area of small-town Ohio, and I think I was generally good at exploiting available options.
(Not all ideas were good ideas: I once helped negotiate and implement a deal to run some Ethernet cable overhead across a parking lot to a small ISP next door, so we could have access to a T1 at the shop I was working at, for $40/month. The money was right according to all parties, and we didn't abuse it too bad or too often...until it all got blown up by lightning, with huge losses on both ends of that connection.
The ISP never fully recovered and died absolutely a month or two later.
Which, incidentally, is how I learned to never, ever run Cat5 between two buildings. Woops.)
I suspect my parents didn't feel the need to upgrade from dial-up to DSL or DOCSIS while we were planning a 5000 mile move. We went from 1p-a-minute dial up ("put a timer on the stove, you have 15 minutes!") in 1998 to unlimited (but still with one phone line; drag the cord from the PC to the kitchen and hope Grandma doesn't try to call) a year-ish after, and then got 1.2Mbps DSL once we were in Canada in mid 2002.
My friend down the street upgraded and got a new PC around 1999 or 2000. I don't remember the specs, but it was much nicer than my dad's 300MHz K6-2 with no USB ports. For a while we even needed to use CursorKeys because the V90 modem used the same COM port as the mouse! So I used their PC for Napster, then Kazaa and WinMX, for 128kbps MP3s and "which pixel is Neo?" 700MB copies of The Matrix (sidenote: I warned him against searching for xXx featuring Vin Diesel, but he had to learn the hard way...)
We were aware of "chipped" consoles, and my family even asked the local indie game store if they could do it ("That'z Entertainment" in Lakeside, if any locals are reading this) but my only experiences with game piracy at that point was my dad's friend who had a modded PSX ("holy crap it says SCEA instead of SCEE!") and then the same friend as the paragraph above getting a PSX that his Army dad brought back from Eastern Europe along with Ice Age on DVD.
DC piracy was 100% a thing in its lifetime, but I still don't think it was widespread enough to have harmed the console's chances. The company was just out of cash.
> There were also release groups -- because of course there were -- that specialized partly in shrinking a larger (>650 or >700MB) DC title down to a size that would fit onto a CD-R, or sometimes onto two of them. (That involved Deep Magic, for the time, and implicitly involved a download stage.)
Even years later I was annoyed that the CDI version of Skies of Arcadia (Echelon, maybe?) didn't support the VGA box.
I suspect that we're about the same age.
Man, com ports and IRQs: I had 14 functional RS-232 ports on one machine, once, between the BocaBoard (with 10P10C jacks), the STB serial card that 3dfx promised to never erase documentation for (it is erased -- *thanks, nVidia*), and the couple of serial ports that were built into a motherboard or multi-IO card at that time.
Once configured to be actually-working, which I did mostly as a dare to myself, I could find no combination of connected serialized stuff that would upset it.
And that was fun having a ridiculous amount of serial ports: I had dumb terminals scattered around, and I had machines connected with SLIP and PLIP. (Ethernet seemed expensive, and "spare laptops" or "closet laptops" were not at all a thing yet.)
Anyhow, piracy: My friends and I were mostly into PSX back then. I may or may not have installed a dozen mod chips for my friends so I could get a discount on my own mod chip. (I was not trying to make money.)
Aaand there may have been quite a lot of piracy. I remember coming home and checking the mailbox to find a copy of Gran Turismo 2, with a hand-written note from a friend who I didn't expect to be able to succeed in duping a disc with Nero, but he'd done it, and hand-delivered it, and it worked. I subsequently played the fuck out of that game.
But you've clearly got a different perspective. And that's interesting to me.
> Even years later I was annoyed that the CDI version of Skies of Arcadia (Echelon, maybe?) didn't support the VGA box.
I've never actually-played a CDI system (I do recall poking at them in retail displays), and I don't know what "the VGA box" is in this context. Can you elaborate?
Oh, sorry for the confusion. CDI and GDI are disc images for Dreamcast games, like ISO files. Not the Philips CDi game console.
The VGA box is the video output for Dreamcast, which supported 640x480 progressive scan video, most games supported it but a few didn't.
I did do a little bit for/with Dreamcast at one point a long time ago, but I never actually owned one for myself. It has always seemed like a nice platform when I've played games on one -- however that happened.
At one point I probably knew the difference between formats, but I've definitely forgotten. It has been a very long time.
(In other Sega news: The thing I really miss is the Virtua Fighter port to the Sega Saturn.)
Oh yes that I definitely knew about, the rushed Saturn launch out of nowhere, as well as its early retirement to make room for the Dreamcast, soured a lot of people.
A shame too, the Dreamcast deserved so much better. It was a great system, and pretty prescient too, at least on the GPU side: Sega America wanted to go with 3dfx, Sega Japan ultimately went with PowerVR, 3dfx turned out to be a dead end, while PowerVR endured until fairly recently (if mostly in the mobile / embedded / power efficient space).
That was really boneheaded on Sega's part. They introduced the DC in Japan first, killing the Saturn which was quite successful there.
Had they waited, or at least launched in NA/EU in 1998, they could have kept money coming in from Saturn in JP while getting back into the market elsewhere.
In my teens, my older brother worked at a computer shop and back then was a hardware geek, and a Matrox M3D, and frankly compared to something like a Rush or Riva 128 the M3D was pretty good outside of some blending moire. That I'm talking about visual vs perf says something... and Dreamcast got the version AFTER that...
The biggest thing was their Tile based deferred rendering, which made it easy to create an efficient GPU with a relatively low transistor count.
Also, 3dfx pattern of 'chip per function', aside from it's future scaling issues, would have been a higher BOM.
-----
All of that said, ever wonder what the video game scene, or NVidia would be like today, if the latter didn't derp out on their shot at the Dreamcast in an SEC filing, which caused them to be relegated to the video chip for the Pico?
It was efficient but the performance was definitely the lowest of all consoles that generation.
> Their partner in MS wasn’t helpful.
The MS thing was actually an important PR olive branch after the Saturn.
Saturn had a somewhat deserved bad rep for API/doc issues, and doing 3D was extra painful between the VDP behavior and quads...
Microsoft was flouting around DirectX at the time, Even with it's warts at the time it was accepted by devs as 'better than what we used to deal with!'.
All of it was an attempt to signal to game developers; 'Look we know porting stuff to Saturn sucked, our API is better, but if you're worried, you are doing more PC ports now anyway, so this is a path'.
If anything, I'd say the biggest tactical 'mistake' there was that in providing that special Windows CE, Microsoft probably got a LOT of feedback and understanding of what console devs want in the process, which probably shaped future DirectX APIs as well as the original XBox.
> PS2 was coming
If the PS1 "$299" conference was the sucker punch, PS2's "Oh it's also a DVD Player" was the coupe-de-grace. I knew a LOT of folks that 'waited' but DVD was the winning factor.
interesting. i always thought this was an order from SOJ.
Namely, lean in hard on 32X for about a year or two to try and slow demand for Ps1 with cheaper hardware. Release the Neptune (Genesis with inbuilt 32x). They then take up Panasonics deal and use the M2 platform to be the Saturn. Release that in 1997 with specs far beyond Ps1/N64.
Neat idea but this is all just fantasy stuff at this point.
It's hard to really nail down without knowing about chip prices in the day, but my thinking was to wait on the Sega CD until 92 or 93, include a DSP or two for basic 3D operations (like the Sega Virtua Processor in Virtua Racing) and market the CD as allowing for cheaper, bigger games instead of FMV garbage.
Then release the Saturn in 95 as an upgraded version of the same architecture akin to the SMD/Gen being based on the SMS. Add a newer CPU (SH-3 or PowerPC 603), use an upgraded SMD's graphics chip for 2D (like VDP2 on the Saturn), the 68K for audio, and whatever 3D silicon Sega had developed (probably still quads)
If this was financially / technically possible, it would have staved off Sega's fear about the SMD/Gen falling behind the SNES in 92-95, allowed backwards compatibility, and been less jank to develop for.
The fact that the Saturn was harder to develop for, had a smaller market share and Sony were paying studios to release on the PlayStation, it’s no wonder Sony won the console wars that generation.
People beat Sega up back then, and also now, but I do not think their hardware was that bad. The pricing was a huge issue.
If I were them, I would have NOT released the 32X as a standalone, NOT released the Saturn, and instead focus on a fusion of the two into a standalone cartridge based system. For everything people criticized the Saturn for, the cartridges made it work. The N64 showed off the advantage of using a cartridge over a CD based system.
If I were going to release a non-portable gaming system today, I'd build one around cartridges that are PCIE 5.0 x4 based and design it so that a) you can quickly shut off the system and replace the game rather than digging through ads/clunky ui/launcher. b) access and latency times are fast c) the hardware is potentially extendable in many different ways.
However, I actually liked the 32x and it's games. Maybe that is because I got the 32x on clearance at walmart for $10 and the games for $1-$2 each, or maybe it was because many of the games were fun and were a genuine upgrade over my 16 bit systems.
I don't think the Saturn was bad, but it was overpriced for the time and definitely rushed.
I DO think this rush to make consoles require an internet connection has left a sizable hole in the market, a hole that nintendo is only half filling. Offline gaming is a thing, and just because a console CAN be connected to the internet, doesn't mean it should be. I've been fantasizing about making one in the future. Something that is kind of like the old Steam Machine, but with the aspects I have mentioned. Maybe one day I will. For me it won't be about success, but rather about building something cool.
Anyways, I'm rambling. Have a great night.
sega was a dysfunctional business reacting to fickle changes in the market (32x was a response to the Atari Jaguar lol).
probably as they didn't have the strong cash reserves of a nintendo, sony or microsoft.
but ultimately i think they were an arcade business and the transition from arcade to home killed them. the same as snk/neo geo.
I think consumers were def skeptical of the 32X despite the marketing, and that was the main thing, in addition to an unimpressive library. Magazine coverage was decent but Gamepro in particular was very negative toward it. Like, Chaotix sucks but the music is amazing, and Gamepro not only trashed the game but gave even the music low marks because "no 32X audio is apparent" lol.
The actual result of Sega's infighting was far more stupid IMO. Sega of America wanted a more conservative design than the Saturn using a Motorola 68020 (successor to the 68000 in the Genesis) which would have lower performance, but developers would be more familiar with the hardware. After they lost this fight, they deemed the Saturn impossible to sell in the US due to its high price. SOA then designed the 32X, a $200 add-on to the Genesis that used the same SH2 processors as the Saturn but drew graphics entirely in software and overlayed them on top of the Genesis graphics. The initial plan was that the Saturn would remain exclusively in Japan for 2-3 years while the 32X would sell overseas. Sega of America spent a ton of money trying to build interest for the 32X and focused their internal development exclusively on the 32X. However, both developers and the media were completely uninterested in it compared to the Saturn. After it became evident that the 32X wouldn't hold the market, Sega of America rushed the Saturn to market to draw attention away from the 32X, but had to rely exclusively on Japanese titles (many of which didn't fit the American market) because they'd spent the past year developing 32X titles (the 32X had more cancelled games than released ones). All of this ended up confusing and pissing off developers and consumers.