^^
or the other possibility of just sticking with 32X
^^
or the other possibility of just sticking with 32X
Actually I always thought they should have done Digitalized sprites of the 3D Virtua Fighter models for the Genesis release. Kind of like Killer Instinct on the SNES.
The incentive was profit-structure. Something Sega managed to mangle in every manner, particularly as relates to legacy hardware in America (the/their biggest market).Quote:
Originally Posted by gamegenie
So far as incentive as disastrous consequence, few pieces of hardware can compete with the 32X -- the quality (contradiction in terms) of software was never going to be passed off as next-gen strata so far as technology, and other technical measures, sometimes even combined with that tech, made the dog look like it was choking on a bone next to the SNES.
It was a very effective advertisement, yes. For the Playstation, SNES and, long-form, N64.
That you've managed a hypothetical more asinine than Sega's 1995 reality is...well, not striking, but mind-numbing.
And killer instinct on the N64... and in the arcade. :p (the arcade game is mostly 2D, including the background which is streaming video -unlike the N64's realtime 3D BG with 2D fighters)Quote:
Originally Posted by kevro
And they did more or less used digitized 3D rendering in virtua fighter 2 on the genesis. (or they seem to have used that as the starting point and then edited them a bit more stylistically for the Genesis's color limitations -the limited animation weakens it a bit for sure though)
The 32x alone hardly managed all of that... it was obviously a culmination of overall problems at the time.Quote:
Originally Posted by 16bitter
On the note of a higher-end baseline system though, if anything maybe they should have had a low-cost duo CD system... but they'd have needed to get that firmly established in 1994 at the latest. (otherwise the vanilla Genesis -or maybe some on-cart enhancements/coprocessors or low-cost add-ons would have been the only viable options for the legacy/budget market)
Even if they felt they couldn't press on long-term with the MD alone, they already had the CD and many options for embedded/low cost enhancements to go with rather than something as elaborate as the 32x. (and if they did go with something as costly as the 32x, there was a lot more they could have optimized for high performance at the same price) Regardless of enhancements, there's some types of on-cart coprocessors that should have been used for late games. (especially custom AISCs -or generic DSPs/MCUs- for realtime data decompression, allowing much less ROM to be used for any given game content -or much more content for any given amount of ROM used -they could even have implemented a cut-down implementation of the SVP for that)
But from many accounts, SoA seemed to be out of touch with SoJ's plans... and that turned into a mess after the public announcement of the Saturn's Japanese release (not so much for the public/media in the west as internally at SoA, apparently shattering the newfound cooperative relationship with SoJ and SoA -in part built on the development of the 32x/Mars project)... but the worst part followed that with the 32x's hype diminished by Nintendo's new showings (especially DKC) and the subsequent mess with the Saturn and 32x throughout 1995 and following that as well -pulling back on the Genesis -and not pulling back on the MD soon enough in Europe for that matter- dropping the GG, making a worse mess out of the 32x, etc. (and from several accounts some of those critical decisions were tied to SoA asserting additional control over what had previously been independent, but details are sketchy)
There's a lot that's really open-ended, especially things like why Nakayma pushed for Mars in the first place and why it wasn't canceled after plans for the Saturn changed... but in hindsight at least, it seems like it would have been far better to allow SoA to weigh in on the final design of the Saturn (feature set, price point, development tools, software aim, etc) than to push a new project onto them instead.
And on top of that, if they did want to push something interim: they had options tied to the CD and much more conservative add-on options (external or cart based)... and the lower the cost, the better chance of wide-spread adoption. (if it was pushed early enough, maybe they could have made the western release of Virtua Racing lock-on, or separated the game into a separate SVP cart and Virtua racing piggyback cart -but given it was the only game initially released for that coprocessor, it would have made sense to make it a unified lock-on cart initially... or even after the fact they could have gone with a separate SVP cart, or dropped that and gone a step beyond with the DSP from the Saturn or an SH1 or SH2 -SVP would have been the cheapest option, so probably the most feasible. There would also have been some real potential for combined SVP+CD games taking advantage of the ASIC's hardware acceleration and offloading many of the duties ill-suited to the SVP while retainign duties the MD/CD was weak at -and a low-cost SVP add-on could have had a much larger adoption rate for potential SVP+CD games)
Actually, going back to the idea of the duo unit... if they were willing to eat the cost or push the price up a bit, they probably could have introduced that with integrated SVP too. (A CD duo definitely should have been down to about $200 retail in fall of 1994, so probably $230-250 if they integrated the SVP)
Sure, you'd lose the color advantages of the 32x, but that would simply give another advantage to the Saturn when it hit full market.
the CD+SVP is an idea that confuses me.
marketing wise, people tend to prefer simple concepts. a gaming console is a device where you insert a cart and play. dont need to think about OS version, ram, compatibility... so, keep it simple, genesis uses carts and you play the game. then we add the CD, mmmm, there are games built into CDs and you need the "reader", its still ok for the masses. but to think in a game that needs GEN+CD+SVP+whatever is against the simplicity of the "console". even worse with the late games GEN+CD+32x+cabling, what a mess!!
technically, I still wonder about GEN+CD power. you mentioned several times techniques like real time decompression, 3D and DSPs like SVP. consider the 3D counter part games available in SNES. they were way behind VirtuaRacing. in fact, SVP+GEN was so much faster that the comparison with FX was ridiculous. In my opinion that advantage was not needed by the time.
GEN+CD is a scenario with the GEN 68k acting as main CPU, CD 68k as DSP (3D, decompression, etc), YM + z80 just for sound, and scaling hardware. apart from the technical problems (dma, syncs, access to mem), the GEN+CD was a promising piece of hardware. more ram maybe helps, but with the stock gen+cd there is enough power to compete with snes+added chips. personally dont see color as a problem, late gen games look really nice. lets say with 128c tricks or dithering, ethernalch, comixzn, contra, gunstarH, rangerx, pitfall were really nice looking.
feasible games were: prerendered games (DKG style), basic 3D (cut down version VR), scaling (wolfenstein3D or even DOOM), rhythm based games (even with music videos), could be done with the beast gen+cd, and able to compete in those years market. and what about mixes of those technologies, like 2D fighting games with 3D scenarios, and added scaling to the 2D sprites plus CD music and clear sound voices
with a good library of CD games, the idea of cheap duo system rocks. even without svp (I still consider it dispensable)
actually, examples like bonus stages in ToyStory, or the brazillian duke3D, makes me think Wolf3D is possible on stock Genesis, or at least a cut down versión but on pair with the Snes+fx one.
and for the DOOM version, let the CD 68k manage map scenarios, and the scaling hardware do the trick with objetcs (items, enemies, wheapons). gens cpu + cd cpu seems to be hard to sync for this kind of task.
The Saturn's cartridge port lacking support for the 32X was also really dumb move on SEGA's part. Regardless if Genesis was discontinued. The 32X could have lasted much longer than it did if SEGA built Saturn right.
Sure it was a costly beast, but $400 dollars would have been more worthy if it played both Saturn and 32X games.
It would positioned Saturn better in competition with it's CD-ROM competitor PlaySation and it's cartridge competitor Nintendo 64.
Sonic 32X-Treme would have probably been a pack-in title for a 1996 Saturn re-launch to counter Super Mario 64.
But these are many ideas that SEGA was just incapable of thinking of and doomed them.
What the hell are you smoking that is the stupidest thing I have heard in a long time. I could understand the Genesis but THE 32X!?Quote:
Originally Posted by gamegenie
I have an issue of Game Players (Feb '94) where in an article they said it was rumored that the Saturn might be backward compatible with the Sega CD. That would've been interesting.
Nigga this is the 32X board, why the fuck should I be praising the Genesis up in here. http://betastart.com/SW/giveup.gifQuote:
Originally Posted by Da_Shocker
I had a '94 Game Informer mag that was rumoring the cartridge port was to be for 32X games. It never panned out.Quote:
Originally Posted by Cornholio857
Simple, it builds on existing tech to allow substantially better 3D than the CD or SVP could do alone... let alone non-3D stuff (decompression, mixed 2D/3D, etc).Quote:
Originally Posted by chameleon
It probably wouldn't have been as well supported as CD or SVP alone, but far more feasible than CD-32x, much more so if it became a standard feature on a duo system.
Yes, exactly why an SVP would simplify things, no wires, just a plug-in cart (possible with a built-in game), but facilitating use by the CD and additional cart games without added cost on every cart. (in that case they'd have been better to add a little bit more with some audio -maybe something simple like the 32x's PWM, not important for CD games, but rather significant for MD games)Quote:
marketing wise, people tend to prefer simple concepts. a gaming console is a device where you insert a cart and play. dont need to think about OS version, ram, compatibility... so, keep it simple, genesis uses carts and you play the game. then we add the CD, mmmm, there are games built into CDs and you need the "reader", its still ok for the masses. but to think in a game that needs GEN+CD+SVP+whatever is against the simplicity of the "console". even worse with the late games GEN+CD+32x+cabling, what a mess!!
Furthermore, you could have games that could run on a plain Genesis, but would be enhanced/expanded by SVP and/or CD. (the same was true for 32x, but would have been more wasteful as you'd either need redundant graphics or not using the 32x's video hardware at all -only the CPU grunt and RAM)
The CD has plenty of power for that, but pushign 3D is a bit tough... the ASIC helps a good bit (bitmap management, 2D filling needed for polygon rendering, and texture mapping), but in combination with a fast DSP like the SVP, it would have had a lot more potential all around. (you'd have more 68k time for game logic and such while having much more resource from the SVP DSP for 3D math and other things like ray-casting -the ASIC is good for scaling and line rendering, but not ray casting as in doom, so without the SVP you'd have to resort for CPU resource and only have the ASIC manage bitmaps and scaling 2D objects -given previous discussions, the CD may have been able to handle Doom fairly close to what the SNES did in terms of graphics, but with SVP it probably could have been more like the 32x but in lower color)Quote:
technically, I still wonder about GEN+CD power. you mentioned several times techniques like real time decompression, 3D and DSPs like SVP. consider the 3D counter part games available in SNES. they were way behind VirtuaRacing. in fact, SVP+GEN was so much faster that the comparison with FX was ridiculous. In my opinion that advantage was not needed by the time.
The CD 68k still is pretty weak compared to dedicated DSPs, but a good general purpose CPU... the ASIC offloads a fair bit compared to CPU alone, but the SVP would have helped a good bit more.Quote:
GEN+CD is a scenario with the GEN 68k acting as main CPU, CD 68k as DSP (3D, decompression, etc), YM + z80 just for sound, and scaling hardware. apart from the technical problems (dma, syncs, access to mem), the GEN+CD was a promising piece of hardware. more ram maybe helps, but with the stock gen+cd there is enough power to compete with snes+added chips. personally dont see color as a problem, late gen games look really nice. lets say with 128c tricks or dithering, ethernalch, comixzn, contra, gunstarH, rangerx, pitfall were really nice looking.
If pushed, it seems like the CD could manage 3D somewhat close to the Super FX1 on the SNES with some tradeoffs (it has advantages for texture rendering/scaling/rotation but weaker in some areas like fast 3D math on the SFX).
Chilly Willy mused a while back that the plain CD+MD could have been enough to manage a moderately more cut-down version of virtua racing. He's still setting up is development tools on the CD though, but I seem to recall he was planning on doing some tests on polygon performance on the CD.
Fonzie also once mentioned that the CD could probably push polygons about 3x as fast as a plain MD.
The CD was never pushed as such though and few games bothered with extensive use of polygons... in part because scaling 2D and limited 3D texture use was considered aesthetically preferable.
A wolf 3D port would be tough, much more practical for the CD. A total remake using a unique engine on the MD might have been possible, but not a port. (not sure if the SNES game is a port or a total remake, but Doom was a complete custom remake on the SNES -unlike pretty much every other version)Quote:
feasible games were: prerendered games (DKG style), basic 3D (cut down version VR), scaling (wolfenstein3D or even DOOM), rhythm based games (even with music videos), could be done with the beast gen+cd, and able to compete in those years market. and what about mixes of those technologies, like 2D fighting games with 3D scenarios, and added scaling to the 2D sprites plus CD music and clear sound voices
Yeah... less confusing for developers and consumers. Lots of cross-platform support, some games using carts+CDs (complex but really worth it)Quote:
with a good library of CD games, the idea of cheap duo system rocks. even without svp (I still consider it dispensable)
What they really should have done is had a low-cost duo out by 1993, if not earlier. By the time the CD model 2 was out, they probably could have had the duo down to $300 in '93... then drop it to $200 by fall of '94.
The software side was critical too though, both for support of lots of low-cost and/or enhanced games (ie games that did cost almost as much as the cart versions would have been more enhanced) to allow the system to pay for itself and attract new buyers.
Not only Sega games but some critical 3rd party killer apps. (Street Fighter 2 is one big one the CD sorely missed altogether) Not to mention improved/exclusive arcade ports. (especially Scaling games)
The FMV stuff wasn't too problematic (in terms of its general existence), but they seemed to put to much marketing emphasis on it over the breadth of other software, and lack of Sonic CD pack-in was odd. (for that matter, CD versions of the genesis sonic games would have been great, at least 1 and 2 compiled -maybe with the spin dash in 1- given the smaller size and easier conversion to CD memory than 3/K)
I was just thinking of the SVP as a better potential way to push into some late gen games on the MD/CD without the cost or conflict of the 32x. (ie something that could have been ~$50, at least soon after launch... or a bit more if VR had been integrated -they could have made an integrated VR and then later made a cheaper standalone cart)
Or if they did drop that whole idea, at least have a low-cost ASIC for decompression or some other things that could enhance or even cost-reduce late gen cart games. (including cart games with CD expansion support)
Yes... if it wasn't for the RAM on the MD, it probably could have managed a technically better version than the SNES. (let alone the removal of censorship hacking up that conversion)Quote:
Originally Posted by chameleon
There's not enough RAM to allow a port, but a totally new engine for the MD might have worked (not sure if the SNES did that for Wolf3D, but it did for Doom). The MCD has enough RAM that an optimized port of the original DOS game should have been possible. (it would have meant reworking hand-optimized 286 assembly into 68k assembly and a bit more work to take advantage of the hardware acceleration, but wouldn't necessitate a totally custom engine -a custom engine would be an option there too though)
Chilly Willy is considering doing a vanilla Sega CD port of Wolf3D after Wolf32x/CD is finished. (at one point he said he was going to do Doom CD32x first, but I'm not sure if that's changed or if he'd undecided)
Toy Story and Battle Frenzy mirror the floor and ceiling and thus only render 1/2, toy story also avoids putting much else on the screen and strategically designed the corridors to limit draw distance (Battle Frenzy does that too), so it's a stylistically optimized thing that would be tough to do with ports and impossible to do with a Doom like game.
Doom may have been possible on the MCD alone, but probably as a customized remake as the SNES got rather than a hacked up port. (same for SVP Doom, but it probably would have been a bit better than Sega CD Doom as the CD can't accelerate ray casting -only helpful for the scaled objects and bitmap to tile conversion, not column rendering unlike polygon games where the texture mapping/line fill comes in handy -it might have even been worth modifying doom into a polygon affine renderer and using the ASIC's line rendering at the expense of texture warping, but I'm not sure if that would be faster than software ray casting -3DO Doom probably should have been redesigned to use polygons/quads so it could use hardware rasterization/texture mapping like the Playstation port, the 32x had no such acceleration so software column rendering had a hefty advantage -as it would for the SVP or a CPU without acceleration, but the CD's ASIC muddies the waters there and my understanding is too limited to really comment further on that -even with SVP+CD it's a bit unclear)Quote:
and for the DOOM version, let the CD 68k manage map scenarios, and the scaling hardware do the trick with objetcs (items, enemies, wheapons). gens cpu + cd cpu seems to be hard to sync for this kind of task.
If you did do a software ray-casting engine on the MD, you'd almost certainly do it like Wolf3D or Zero Tolerance and use dithered pairs of pixels for simulated higher color (probably use mode H40 -320 pixel wide- for better blending) and for working with 8 bits at a time rather than 4-bit pixels (less CPU overhead to deal with bytes than nybbles -let alone single bits as the SNES/ST/PCE has to with the bitplane graphics) and either limit shading or remove distance shading gradients in favor of optimized colors with solid lighting (or per-sector lighting like 32x Doom). You could do simple dithered shading like Zero Tolerance if that ended up looking OK, but otherwise it might be worth avoiding. (ZT basically used increasing amounts of black bars to blend in as shading/lighting -and there's more options than that, namely using more than just black to manage shading with similar simple dithering)
That would apply to both SVP and plain MD/CD stuff.
One last thing is double buffering: a game should at least be sure to buffer enough to allow the screen to only tear for 1 frame per update (at 60 Hz, 1 messed up fame isn't too bad), it's also preferable to make that tear as even as possible (splitting the screen right down the middle vertically often works well -Zero Tolerance does that -probably doesn't buffer at all, but uses a small enough screen to update the display in 2 consecutive 60 Hz frames).
Cases like Duke Nukem 3D and more extreme with some FMV (Rebel Assault is horrible, Dune is iffy) should be avoided, and full double buffering (enough to allow no tearing -not necessarily total double buffering, but enough buffered to allow the final unbuffered update to occur in 1 vblank period) is preferable if the VRAM can be spared.
PAL games always have that easier due to the much larger vblank area... so you could effectively need less VRAM to double buffer (and potentially have a larger or higher res screen), or fully double buffer where you can't in NTSC. (which is good since 50 Hz makes tearing more obvious than 60 Hz)
Yeah, but that whole premise is already just bandaging a flawed arrangement...Quote:
Originally Posted by gamegenie
And to make that cost effective (ie not push it up another $100 for tacked-on compatibility), the Saturn should never have been designed the way it was at all... it should have been efficiently evolved from the MD+CD hardware to minimize hardware that was tacked on (preferably more efficiently than the MD did for the SMS -MD was pretty tacked on and held back by the SMS compatibility but it could have been worse -it also could have been way better though -either designed from the ground up to be SMS compatible or dropping internal SMS support and adding other features).
By that point though, you'd have a nice, fairly cost effective, fully MD/CD compatible system, so the 32x would be pretty superfluous anyway.
I was favoring a hypothetical Jupiter in place of the 32x for a while... in the context of a new machine ready (at a reasonable price) for the US in fall of '94 (say $200-250), basically a stripped down Saturn with no CD and less RAM along with expansion provisions to full Saturn spec.
But then I got to thinking... CD was the way to go and splitting the market with carts was a bad idea (from a consumer and profit making standpoint -CDs allow much higher profit margins and flexibility).
And in the context of the hsitorical Saturn, they could have done some "last minute" (ie late 1993/early 1994 initiated) modifications to really push for a more realistic and cost-reduced design. (some things probably would have needed more time to be really changed though -and there's a lot of sloppy/inefficient things in the design)
But in the simplest form, just strip it down somewhat like the "Jupiter" with a CD-Drive and rely more heavily on RAM expansion later on.
That's one of the biggest issues from Sega's standpoint on the market... not only getting a console out soon enough, but getting it out at a competitive price point with a realistic market model. (there were certainly other issues including 1st and 3rd party software support -most severely a lack of 1st party killer apps applicable to the North American mass market -and especially a lack of a Football and Sonic game at launch)
But having a Saturn that could have been cheap enough to push in the US when they (SoA and/or SoJ) felt the Mars project was necessary could have been critical.
On the technical side you've got a lot of RAM that could be feasibly cut back on (again with provisions for expansion -especially beyond what the cart slot offered -SDRAM support with 32-bit wide main bus and the same 16-bit video bus -that's 16-bit internally anyway). Cut the CD-ROM buffer way back and use cheap DRAM rather than SDRAM (perhaps one of the 128 kB DRAM chips in stock already), cut main RAM down to 512k-1MB, and maybe cut back some of the video RAM too. They could have cut audio back a fair bit too, maybe even removing the 68k and dedicated audio bus and putting the SCSP on the main bus and manage it with the SH2s. (and remove the audio DSP given how rarely it was used -if ever, or maybe even switch to a simpler or off the shelf sound system -a derivative of the OPL4 might have worked well)
So overall under 3 MB, perhaps close to 2.5 MB, and dropping the internal SRAM in favor of memory cards would have been nice. (and plenty of provision/plans for expansion, preferably culminating into a single definitive RAM add-on)
If you could change things earlier (ie not last minute), it would have been better to scrap the SH1 entirely and use a 2x speed derivative of the Sega CD's CD-ROM interface with a 68k managing CD operations as well as managing audio (and doubling audio RAM as the CD-ROM buffer -or maybe retain a small CD-ROM buffer -MCD used 16 kB, 3DO/PSX used 32 kB- and use audio work RAM for secondary buffering and audio only), use the same 512 kB 16-bit DRAM chip common to the MCD (may have also been used in the Saturn) and either use a cut-down SCSP (no DSP, maybe even no synth hardware) or an off the shelf alternative like the OPL4. (OPL4 would still need a bit of external interfacing logic to allow use with DRAM)
Then there's the various missed opportunities with the Genesis and CD themselves... and the screw-ups of pulling Genesis support back too soon (not just software support, but marketing as it went into the budget category -a time they could worry less about new games and more about re-releases along with maybe a few still unreleased Japanese/European games and promoting low prices as with the 2600/NES/SNES/PSX/PS2 late in life)
Sega seemed much too focused on hardware, and substantial leaps at that (ie no small/embedded on-cart enhancements as Nintendo -and several others- had been doing since the 80s). Nintendo made an obviously right choice to push back with new software for the SNES in late 1994 to curb the hefty "slump" on the US market... Sega responded with the 32x as well as new software in a far less coordinated manner. (not responded to Nintendo, but the North American slump starting in '93) That was exacerbated by the fact that Sega already had the CD to focus on, and 1994 could have been the definitive year with many of the very best games coming out then. (though there's things they should have done differently in '93 too, as well as the whole market -both SoA and SoJ)
Of course, it was SoJ who pushed project Mars in the first place... and it wasn't just because of the slump on the US market but also perceived threats from the Jaguar and 3DO in 1993 (the hype from which made for pretty convincing threats that didn't become clear non-issues until the 1994 holiday sales season)
Carts was a boneheaded move on Nintendo's part... in '93/94 it was still somewhat logical due to costs, but even then it was a pretty sound investment (especially as it was obvious how fast drive costs were decreasing) and by '95/96 it was plain stupid.Quote:
It would positioned Saturn better in competition with it's CD-ROM competitor PlaySation and it's cartridge competitor Nintendo 64.
Using carts doomed the N64 to relative mediocrity and especially lost Nintendo their near stranglehold on the Japanese console market.
They were really short sighted... even if they did think it was a goo idea back in '93/94, they should have corrected that later on, either with an added drive from the start or an add-on to follow by '97 or '98 at the absolute latest. (the DD was a horrible choice, too late, far too costly -optical drives and media are inherently more cost effective, onyl expensive early on due to patent holder's licensing and royalty costs... and it was rather dumb of Nintendo not to invest in a custom/secure optical format of their own if they were really concerned about controlling the content of their system -as Sega did with GDROM and Nintendo later did with DVD on the GC, and note GD-ROM really was pretty foolproof as such it took 2 combined exploits that Sega had overlooked to get around it -the first being use of the network interface to stream GD-ROM data that could not be extracted by PCs -no drivers available to read GD- and the 2nd being the ability to boot CDs/CD-Rs as games on the DC ... the route taken by Nintendo with the GC was even simpler and the GC discs were much closer to normal mini DVDs than GD-ROM was to CD)
http://sega-16.com/forum/showthread.php?t=13272&page=14
http://sega-16.com/forum/showthread.php?t=14836&page=14
This is all pushing back to these topics, and most/all has been discussed before. (though I think I may have rambled a fair bit more on other topics... and I think I've summarized some points better)
i know carts was a bonehead idea on Nintendo's part. I just don't think it would have hurt SEGA's fanbase as bad as it did if SEGA didn't completely screw the 32X users over in the fashion they did.
Cause as you know the 32X (as well as the Saturn) is highlighted as the downfall of SEGA, and I say it's all due to how they marketed the two. I think a simple bridge of the two systems could have done a lot more in saving their face amongst the industry instead of how they actually marketed them in reality.
Genesis was old hat by '95 and looking back now it probably would have been a better decision to freeze it and SEGA CD. Which make up the 16-bit market, and focus on the 32-bit market. 32X and Saturn.
32X hardware is essentially based off the Saturn. So the Saturn had all the tech of 32X inside of it, even a cartridge port. But SEGA didn't go all the way with the concept which I see as a mistake on their part.
and with that thought in mind, the standalone 32X they were working on, the Neptune. Makes even more sense now, which I could see being released later down the road like in '98 or '99, in years when most of the old Genesis stock, and 32X adapters are gone. A reasonable priced Neptune at $89 would have been good (presuming that the Saturn itself is somewhat a success, and there are numerous more 32X games made along side Saturn CD games that warrants demand for a standalone 32X).
Uh - no. We've been over this any number of times, but the 32X is NOTHING like the Saturn. Yes, they both has two SH2s as the main CPU, and one 68000 available for something (sound on the Saturn), but that's as far as the similarity goes. The 2D processor in the Saturn is miles ahead of the Genesis VDP, and the 32X has NOTHING for video except a simple fill circuit meant to clear a single line of the display.Quote:
Originally Posted by gamegenie