Discuss alternate realities here!

**sheath** · 09-08-2010, 01:19 PM

Originally Posted by Chilly Willy

The DMA on the Genesis is "crappy" because it can't update an entire screen worth of tiles in one frame. It doesn't matter that the SNES is worse. Fast scrolling games like Sonic work by having most of the tiles in vram, and only changing the table that determines which tiles will be shown. The table (the pattern name table) is small and can be changed quickly enough for 60 Hz games. If you wish to change the tiles themselves, the DMA rate on the Genesis limits you to 15 to 20 Hz games. that's why games like VR are only 15 to 20 Hz.

The SEGA CD graphics ASIC is designed to generate rotated/scaled gaphics by generating all new sets of tiles for the rotated/scaled graphics. Do see what that means? The way the ASIC generates graphics is the SLOWEST way the Genesis graphics work. If SEGA had added a video layer to the CD, then the CD could update that layer at 60Hz, not the Genesis layer at 20 Hz. So CD games with lots of scaling and rotation (or FMV) would have been faster.

I actually haven't even fully understood the difference between Hz and Framerate in technical speak. I do know that a game running at 60FPS doesn't run as smooth at 30Hz, but the graphics are still smoother than a 30FPS game would be on the same screen. My RPTV only displays 1080i at 30Hz, so I've messed around with Dreamcast-X360 and PC games to see what was best.

With 3D 32X games and Saturn games that run below 30FPS, I can use my video capture card and frame advance to see how many frames per second there are. I have been very careful about how the card de-interlaces to be sure that isn't affecting the measurement. Typically anything less than the rendering speed of 29.97FPS shows up as a succession of static images. Anything over that shows up as static images with every 2nd or 3rd frame a blurred double image of the last frame and new frame. This accounts for the relative perception of "smooth" on SDTVs.

What I don't know, mainly because I haven't looked, is how the physical output Hz affects any of this. I've only tested real hardware using the maximum output quality available without mods.

**villahed94** · 09-08-2010, 04:34 PM

Of couse a new reality, the E one

**Chilly Willy** · 09-08-2010, 05:48 PM

Originally Posted by sheath

I actually haven't even fully understood the difference between Hz and Framerate in technical speak.

Hz is simply the number of times anything happens per second. When talking about framerate, which is given in Hz, it means the number of times a frame is shown per second, or the number of times a frame is updated per second (which may or may not be the same value). All consoles outputting SD video show 60 frames per second, unless the frame is interlaced, in which case they show 60 FIELDS per second, where each field is half the frame, giving a framerate of 30 Hz.

When you give the framerate of the GAME (not the console), you normally mean how many times per second the frame is updated with new graphics. The fastest games, like Sonic, are updated every single frame the console shows, or at 60 Hz. A game that redraws most of the tiles from scratch (like VR) takes three or four video frames worth of time to update the screen due to low DMA rates to vram. 60Hz / 3 = 20 frames per second update rate (20 Hz), while 60 / 4 = 15 Hz.

**chrisbid** · 09-08-2010, 06:58 PM

Originally Posted by sheath

That is just incorrect. Sega the hardware manufacturer released higher quantity of well reviewed *and* fairly unique titles every year than Nintendo ever did.

what is incorrect about my statement? sega had no software that the masses wanted. they had no software that pushed hardware sales in the mid 90s, and as a result, every sega platform ended up getting trashed. virtua fighter 2 made the saturn a hit in japan, but it was seen a boring tech demo in the states.

sega had plenty of quality titles available for enthusiasts and hardware junkies, but there was no 32-bit title that pushed hardware like sonic the hedgehog pushed the genesis.

In fact, Sega proved that releasing well designed highly playable games, that also receive great press, in high quantity is not what the masses want.

high quality/high praise titles and mass-appeal 'killer app' titles are not mutually exclusive. in fact, every title i mentioned was highly rated by the press.

I predicted way back when the Dreamcast was canceled that it was the beginning of the end for gameplay innovation and new IP, and I was right. One of the top conceptual comments from publishers today is excusing the fact that the industry won't take chances on new ideas today. Sega did that almost constantly as a hardware manufacturer, which is probably one of the top reasons why they ultimately had to stop.

The masses want simple, familiar, and especially popular brand names. Art doesn't sell, uniqueness doesn't sell, innovation definitely doesn't sell. Quality can make a game successful among gamers though.

are you blind? are you ignoring the ds and wii?

the masses want new experiences, but they do not want uniqueness and art simply for the sake of uniqueness and art. they want fun.

**sheath** · 09-08-2010, 07:12 PM

Define "fun," and develop a way to measure it in a game that does not involve buzz or sales. Fun is subjective, even arbitrary. It is not a criteria for a "good game, and developers cannot predict whether their game will have it.

**kool kitty89** · 09-08-2010, 07:15 PM

Originally Posted by sheath

I actually haven't even fully understood the difference between Hz and Framerate in technical speak. I do know that a game running at 60FPS doesn't run as smooth at 30Hz, but the graphics are still smoother than a 30FPS game would be on the same screen. My RPTV only displays 1080i at 30Hz, so I've messed around with Dreamcast-X360 and PC games to see what was best.

No, it displays at 60 Hz, just like SDTV, that's how interlacing works: 2 fields per frame, 60 fields per second.
See: http://en.wikipedia.org/wiki/Interlace
30hz interlace would flicker like mad!

Hz in terminomogy just means times per second "/s" or cycles per second to be more specific, and that could be applied in context for framerate as well (ie a "30 Hz" renderer), but the opposite if not true, you cant say your monitor runs at 60 fps instead of 60 Hz as FPS is a more limited term.

I actually thought most/all 1080i CRTs at least had 480p native support (via 540p, which is the same sync rate as 1080i, just like 480i vs 240p SDTV)

FPS is just the framerate, it how fast the game can draw the screen and update it: the display itself is limited to a fixed scan rate (or refresh rate for LCE/Plasma), but the 2 are independent of eachother: the framerate is limited to the refresh rate though, and flexibility of framerate is somewhat limited by refresh rate as well. You can have variable framerate too, but that can be rather jerky.

But in the context of this discussion, you have 60 Hz NTSC and 50 Hz PAL TV standards, doesn't matter if it's interlaced or progressive (though for all but 1 or 2 games it's progressive: 240p 60 Hz/50Hz), and the main issue is the greater number of scanlines in 50 Hz:
for a 60 Hz NTSC display, you get 525 interlaced lines (625 PAL), but in this context each field is a frame, do it's practically 262 lines per frame vs 312. (though much of that is in overscan, so you get ~240 lines NTSC and 288 PAL -or in most cases more like 224 and ~268 lines due to TVs tending to be calibrated with excess overscan)

Now, the reason that matters is because the VDP only updates in VBLANK (the non active parts at the top and bottom of the display).
In both cases you need 2 lines for other things (V/H sync iirc), so you have 260 and 310 lines to work with.
Then you subtract however many lines are used for the active display (up to 240 lines PAL on the MD and usually clipped to 224 in NTSC -often in PAL as well) and you have the number of vblank lines for DMA each frame.
You have 2 resolution modes in the MD: H32 (256 pixel wide) and H40 (320 wide), H32 gives 166 bytes per vblank line while H40 has 207.5 bytes (I think).

And, taking a standard 224 line game, you get 86 vblank lines in PAL and 36 in NTSC per frame. (and even taking into account that there's 6 vblank periods in 60 Hz for every every 5 in 50 Hz, that's still 2x the bandwidth)

You can clip the vertical display further than that too, to get more Vblank time, though for PAL optimized games it's less necessary than NTSC. (and that's the main reason why games like Street Fighter II, Virtua Racing, and some FMV on the SCD have clipped displays)

For animation/video/updates that exceed one vlbank frame, you have to double buffer in VRAM or have tearing: http://en.wikipedia.org/wiki/Screen_tearing
That uses more VRAM space, though you might be able to clip the screen enough to fit the whole thing into one vblank period, but that would be a lot to sacrifice in NTSC. (PAL could be fairly reasonable)

Edit:
For example, if you were willing to cut the screen all the way down to 160 lines in H40 (ie 320x160 letterboxed), you'd be able to update a 320x128, 288x144, or 256x160 area in one vblank period in NTSC (the latter 2 with some horizontal boarder as well), or in H32 (ie 256x160) you could have 256x128, 224x144, or 200x160 and then there's no need for double buffering and you can go up to 60 FPS. (or have room for other updates)

In PAL you wouldn't need to clip nearly that much though. (and with a dedicated VDC for the SCD, you wouldn't have that limit at all, though due to the PAL resolution having more lines on-screen already, the boarder will still be large -320x224 already shows a large boarder, and 192 lines in PAL has a boarder about the size of 160 lines NTSC) Many games didn't have the clipping specifically optimized for PAL (or take advantage of the added DMA bandwidth), otherwise Sonic CD's ASIC stuff should have all run at 25 FPS, and Virtua Racing probably could have been 216 or 224 lines. (depending how much VRAM space was left)

**chrisbid** · 09-08-2010, 08:50 PM

Originally Posted by sheath

Define "fun," and develop a way to measure it in a game that does not involve buzz or sales. Fun is subjective, even arbitrary. It is not a criteria for a "good game, and developers cannot predict whether their game will have it.

a company knows when a game is fun. companies know when they have a hit on their hands. the hard part is in the design. there have only been a handful of hardware pushing killer apps. if hardware companies knew how to pump these out with more regularity, they certainly would do so.

that is not an argument against my original statement... segas problem was not in the hardware department, it was a software problem.

**kool kitty89** · 09-08-2010, 09:11 PM

Originally Posted by Chilly Willy

The SEGA CD graphics ASIC is designed to generate rotated/scaled gaphics by generating all new sets of tiles for the rotated/scaled graphics. Do see what that means? The way the ASIC generates graphics is the SLOWEST way the Genesis graphics work. If SEGA had added a video layer to the CD, then the CD could update that layer at 60Hz, not the Genesis layer at 20 Hz. So CD games with lots of scaling and rotation (or FMV) would have been faster.

Of course, that's only for stuff that's limited by DMA bandwidth, and in most cases FMV was limited by CD bandwidth/compression capabilities (CD bandwidth alone for uncompressed stuff). Of course, there's the VRAM restriction as well. (and you wouldn't have the screen tearing seen in a couple games like Rebel Assault and Dune)

But as it is, most FMV is usually clipped to the extent of allowing much higher framerate that it otherwise would. Even with a 224 line display in H32 NTSC (pretty much the lowest bandwidth) you'd need at least 2.5-3:1 video compression (depending how much went to audio) before you hit the bandwidth limit. And as it is, I don't think you can go too much past 2.6:1 with Sega-Cinepak before compression starts getting nasty. (whatever they did in Rebel Assault is truly horrible -though the compression is rather ugly on PC as well, and the cutscenes -other than buffer animation- aren't any better)
And once you clipped the video a bit or went to H40, that opened things up too. (it's the FMV games with large boarders that don't tend to clip as much though, but still aren't usually limited by that -and compromising a few lines for added bandwidth would be reasonable in most cases -especially given the amount of filler in many of the boarders)

Stellar Fire's intro is clipped enough that it doesn't even have to be double buffered (320x128) and could run at 60 FPS if that was the only limiting factor, but that's not the case.

But 20 FPS is generous for screen updating in general.

At 224 lines you'd be stuck with 12 FPS tops for NTSC, though you could stick to updating only part of the screen or only render to sprite tiles. (or a compromise to both) But even then you'd be lucky to get past 15 FPS -Sonic CD ASIC bonus sections are stuck at 15 FPS in 256x224 -the clouds int eh intro are 20 FPS I think. (PAL could have been 25 FPS for both -I think the clouds might be, but special stages aren't -possibly because they didn't want to put the time in to re-do the speed for a higher framerate)

And any ASIC rendering that does max out the ASIC's own bandwidth wouldn't benefit from a dedicated VDP either (other than avoiding clipping and adding more color). Batman and Robin supposedly maxes it out.
I also wonder about BC Racers as the screen is clipped to 182 lines and the active game window is 256x128 (all on a single BG layer with no hardware sprites -so possibly all ASIC rendered including the scrolling BG; the only sprites used are overlaid on the status bar), but it only runs at 12 FPS (though it staggers updates of BG and scaled object updates within the 5 frame update period -probably to appear smoother). And clipped to 182 lines, even the whole 256x128 area could be updated within 2 frames and still leave another ~2700 bytes left over for DMA in that 2nd frame)

What sort of limitations does the PCE's VRAM updating have for updating outside of Vblank?

**villahed94** · 09-08-2010, 09:43 PM

Yeah, ASIC Capabilities not used , it has been demonstrated it could generate faster scaling, would have supported 30 fps(for NTSC)

**kool kitty89** · 09-08-2010, 09:51 PM

Originally Posted by sheath

The Graphics Coprocessor makes sense as an "off the shelf" consumer grade solution to boost the effects of Sega CD close enough to Y-Board capabilities without adding another VDP. I'm really not sure what all of this "no rotation in scaler games" is all about. After Burner, G-Loc, Galaxy Force II rotates the entire screen, Power Drift tilts the screen, as does Gale Racer/Rad Mobile. After Burner animates rotation of the jet as it crashes. Crackdown animates sprite rotation as they die. Aurail was an over head game designed around full screen rotation. It seems pretty simple to me, the arcade machines could depend on excessive ROM for effects and the Sega CD could not. Perhaps SoJ didn't port all of these to Sega CD because they had already figured out that arcade ports didn't make enough money?

Animation is a different thing entirely.... they probably considered that as part of it, but there's a lot more to it than that. If that really was the case, that's an extreme coincidence. (it's also a bit odd -in general- that no arcade games used hardware rotation/warping effects prior to full texture mapped 3D, that would seem really significant, I mean, there's even a limit to what you can practically do with ROM/RAM -cost wise- in the arcade, hence hardware sprite scaling being used vs plain prescaled animation)

I thought the ASIC for the Sega CD was custom though, not anything off the shelf or direct derivative thereof (like the SVP's off the shelf DSP licensed from Samsung). There were almost certainly off the shelf solutions of the time, but most would likely be expensive unless sega could get a good deal on a license. (various DSPs -or some CPUs/MCUs; the ARM2 was on the open market by then and a low-cost embedded CMOS version had been released iirc- or the TMS34010 GPU, etc)

That's why I said: "Sega both tended to design their console hardware using their arcade designs and custom design their console video processors." What is your point of contention, that the rest of the "off the shelf" components also had nothing to do with Sega's arcade configurations? Sega tended to use components of their arcade hardware, especially the CPU, alongside custom video processors.

You'd have to ask the tech guys to give a better description, but yes, the configuration of the components would be different too (memory map, I/O, etc -the Z80 in the MD is used in a manner in which it never is in the arcade other than MD derived arcade hardware). And again, the graphics hardware is dissimilar.

SG-1000 came out first as a PC, then as a console last I checked. Whether or not it was patterned after Arcade tech doesn't change the three systems that followed it. If Sega wanted to, they could have focused on making the most powerful home console they could each generation, be it custom of off the shelf. They could have focused on making the cheapest console they could, or a slightly better console than whatever else was already on the market. Instead, they looked at their arcade hardware, and then did whatever it took to release a console that could come as close as possible to duplicate the games on a standard Television.

No, No, NOOOO. The SG-1000 was launched as a game console in the exact same day in 1983 as Nintendo's Family Computer. There wasn't even a computer expansion available for the Mk.I.
The Mk.II was released in 1984 with provisions for expansion to a computer (64 kB RAM and keyboard), and the full SC-3000 computer was also released.
The MSX was released in 1983 though, but several months before the FC or Mk.I.

I think Sega rushed a console out the door to get their foot in the door, that and if you recall, that was just before Nakayma+Rosen+Okawa bought Sega back with CSK, so management was a bit iffy.

Even the Dreamcast is a cheaper derivative of Model 3 capabilities, and it is the only time Sega released better tech than its previous arcade machines as a console and arcade system. Sony did this first with the PS1, though the arcade tech was inferior to stuff Sega had on the market previously. The only time Nintendo tried to do it was with the faked Ultra 64 arcade machines like Killer Instinct and the torrid Cruisin' USA.

Dear god, the DC has nothing to do with the model 3! it's closer to the N64, PSX, or some PC accelerators in many respects. One MASSIVE difference is the Dreamcast used conventional triangle polygons while the Model 3 uses quad based rendering exclusively. (like the Saturn)

Exactly, NEC and Nintendo focused on similarities with NES and older tech and cost saving.

And many similarities to the arcade.

But what game(s) actually manage that even in cutscenes? Also, you can't leave out the fact that the Sega CD scales sprites at the same time as the ground, that's a whole different level of capability.

All mode 7 is 256 colors, and most is 30 or 60 fps. It's limited in what it does, but it does it well. (and yes, the Sega CD can render scaled objects as well as a warped perspective layer, and do multiple warped layers, and rotated objects -and full texture mapped polygons as I said, though anything beyond flat object scaling/rotation adds CPU overhead, just like anything mode 7 that's not flat scaling/rotation -an interrupt on every line iirc)

Looking at the RE docs for the Genesis doesn't expose any "crappy" DMA limitations. From what I can find the VDP's DMA was 7.2 KB per 1/60th of a second to the PPU's 5.7 KB. I've documented the sources for these numbers here. I'm sure you'll find it too simplified, but the numbers are documented. Your whole argument sounds like you just don't like the way the Sega CD worked with the Genesis, more than the approach actually being demonstrably bad.

I already explained this in detail (Chilly Willy can confirm) and the DMA limits aren't fixed either, but those figures sound like they're for 224 lines and mode H40 on the MD (320 wide), at 224 lines, H32 (256 wide -Street Fighter II and many others) on the MD is ~5.8 kB/frame (NTSC), it's proportional to the lower resolution.
Both can be expanded by clipping the screen (as SFII and several others do), and are far less limited in 50 Hz PAL as I explained. And a 256x224 16-color bitmap would be 28 kB, so that would take 5 frames to update (12 FPS) and require double buffering: leaving little room for anything else in VRAM and next to no DMA time for any other updates unless you dropped below 12 FPS. (in H40, it would still take 4 frames -max 15 FPS, and it wouldn't be full screen -320x224 would be 5 frames and couln't be double buffered)
Again, clipping to give more vblank helps a lot, but the trade-off is losing screen space (the more lines sacrificed, the larger the letterboxing).

Thanks for pointing out the SNES DMA speeds though.

The PC Enigne/TG-16 is great as it isn't limited to Vblank for DMA updates, so FAR more flexible.

For what the Sega CD can do it does better than the SNES could without the FX chip. Textured Line scrolled ground with scaling sprites is more like Sega's arcade games than Mode 7. That happens to be what the Sega CD's graphics coprocessor does relatively well. You're trying to shoe horn the Sega CD into the "Mode 7" killer model, and as you are demonstrating, the facts just don't line up.

Line scrolled? It's a warped perspective plane, more or less a single texture mapped plane, like SNES mode 7 (but 16 colors, framerate limited, but not as limited in texture resolution). And again, nothing in the arcade did anything like that warped perspective layer prior to 3D, unless you could given an example I'm not aware of. (it's all plain scaling and some animation -which is used for plain rotation, no warping -some late 2D machines mucht have had fast enough CPUs to software render it though -System 32 might manage it a little, CPS3 could easily, but that's after 3D hardware was already common)

At some point though, the framerate limits of the VDP are goign to make scaling so choppy that it's not very impressive compared to mode 7: even if the objects scale a bit better than pop-up animation, the "mode 7" like tile is going to be a fraction of the speed it is in the SNES. (and low color to boot)

Of course you can compromise by clipping the screen, which some games really should have done. (Sonic CD's special stages are literally worse in every way than SNES mode 7, non-scaled sprites, 15 FPS warped layer, 256x224 resolution, etc -they should have clipped enough to at leat manage 20 FPS and/or scaled objects)

From what I have seen, the Sega CD's "sprite scaling" limit occurs before the VDP's sprite limit. BC Racers, specifically designed to throw as many sprites around as possible, chugs it doesn't flicker.

It would be impossible for BC racers to ever flicker as there are no hardware sprites used in the game window. (just a few used in the status bar overlay)

That's interesting about the BG layer being used for scaling though. I always thought that the VDP sprite size limit would cause the sprites to "hit" the screen much smaller than they do. I never bothered to look at anything in Kmod to see how it was done.

You wouldn't have to limit yourself to single sprites either, just like normal genesis games, you could have objects composed of many hardware sprites. (and remember, the sprite limit for drop out/flicker is only per scanline, ie horizontal -there's a separate limit for max number of sprites the VDP can control onscreen, but the per-line limit is far less -I forget what it is, but I think it's 320 pixels or 20 sprites, whatever comes first)

I haven't played either in over a decade, I just remember the sprites and levels looking the same, though slightly enhanced in AB III.

I was looking at playthrough videos and then played them again for myself. The levels are rather different for sure, or at least they're in totally different order, and the Genesis game seems more fun, though you can't seem to select cockpit/external view manually like in ABIII. There's a cool "textured" ground effect used pretty early on in the cart version. (I might have even mistaken that for an ASIC effect had it been on the CD -it's a bit like that used in later VR stages of the Genesis version of Lawnmower Man)

Oh I agree, in fact I think it was smart for Sega to cheaply port Genesis games that were already great and add stuff that CD-ROM makes possible. I wish they spent a little bit more time making Sega CD games from the ground up, but the sales never would have justified the expense.

Yeah, both would have been nice, though I wonder (had the MCD become the dominant format for Sega in Japan as with NEC) if SoJ could have focused mainly on optimizing Sega CD released, and then converting the more practical ones of those to cart after the fact to cover the rest of the userbase. Depending how much resources they dedicated to that it could have meant less MD cart games... though SoA invested a good deal in that too, and it would have been early on (1991-1993) that would have been the most important anyway.
It really is weird that Sega of Japan was rather limited in their activity on the MCD.

Hell, if it was well supported enough, it could have been much more attractive in the US as well, thought he price point was a bit daunting, the lower cost of many games could be a major factor for more thoughtful consumers. (and it seems to have been more affordable than the 32x by the time it was released: $150)

And a low-cost Duo unit really could have helped for 1993 and 1994 in the west. (given the price of the Genesis and CD at the time, a cost-optimized duo would have made sense at $300 in '93 and $200 in late '94 -when the combined suggested retail prices were $360 and $250)

Regardless of any hardware design changes, that should have been done. (there's some key areas the Sega CD could have been managed better in general though)

It would have been tough in Europe either way though with the higher electronics prices.

And I apologize if I sound really know-it-all-ish on the tech stuff, but if it really should be addressed.
Hell, I didn't know much of it myself a year ago, but I picked it up fairly quickly from discussions. (albeit I still only have a rather general understanding of how it works, and it helps that I'm really interested in the whole technical side of things)
Actually a lot of stuff I learned was from being corrected on things too.

And as it is, I'm not really the best one to explain this stuff, especially as I tend to go a bit on information overload if I'm not careful.

As it is, the reasons behing many design engineering aspects of the Sega CD (let alone Genesis) are still speculation overall, though I know the interview featured in EGM is still significant in that regard. (depending how that was handled it's still not straightforward though)

Originally Posted by villahed94

Yeah, ASIC Capabilities not used , it has been demonstrated it could generate faster scaling, would have supported 30 fps(for NTSC)

It could do up to 60 FPS NTSC if you clipped the screen enough.

**kool kitty89** · 09-08-2010, 10:24 PM

Originally Posted by chrisbid

a company knows when a game is fun. companies know when they have a hit on their hands. the hard part is in the design. there have only been a handful of hardware pushing killer apps. if hardware companies knew how to pump these out with more regularity, they certainly would do so.

that is not an argument against my original statement... segas problem was not in the hardware department, it was a software problem.

But what did Sega do differently at that period than before? I know some would argue less japanese games were the problem (and that might be true to some extent), but otherwise Sega was pushing out a lot of software for the Genesis though 1995 at least.

The Saturn had a lot of good, compelling games compared to the PSX early on (for now, lets ignore 1997 onward), the 3D was comparable if not better in some areas, sheer number of games were comparable, both were lacking in some key genres early on (certain sports titles, especially American Football), and both were getting somewhat equal Japanese and western 3rd party support.

Sega had some distractions with the 32x, but even then that didn't account for a ton of software (especially not high-budget stuff) not going to the Saturn or Genesis for that matter. (and late 1996 and more so 1997 were the critical times where the 5th gen consoles hit mass market)

The Saturn itself had several critical problems not related to 1st party software support or hardware design: management and promotion.
The biggest one early on was the May launch that screwed things up all over the place. If the Saturn had been held back until September as originally announced: it would have launched at $300 like the PSX, the launch lineup would have been very strong (with more games than the PSX), developers and key retailers wouldn't be left out of the loop with the launch date, and several launch titles would have had more time to be completed. (basically any released prior to September that weren't released in Japan first -and some Japanese games could have had additional tweaks before the US release -VF Remix would likely have been the only VF in the US as it came out before September, and maybe Daytona would have had some additional optimization)

As it was Sega was dumping a ton of money into Saturn development. (hence why you saw some really high-budget stuff like Panzer Dragoon early on)

A developer may know when it has a "fun" game on its hands by public response, but there's no simple formula for what's "fun" and even if you re-use the template for an old formula (ie Sonic) it wears out after a while. (though a good 2D/2.5D sonic early on for the Saturn could have helped -though a full 3D platformer of some sort by late 1996 would have been very important -Nights might have been something though, but probably not as much as a good 3D platformer at the time -in any case the Nights ad campaign for 1996 got halted so we'll never know -it was huge in Japan though)

Sony got a lot of their system selling exclusives by paying off developers: ie Crash Bandicoot and Tomb Raider II. The big 3rd party title that pretty mcuh made the Playstation the success it was and flattened the Saturn with a lack of it was Final Fantasy VII.
And that being a PSX exclusive almost certainly has to do with a deal with Sony. (be it attractive licensign agreement, advertising budget, etc) Otherwise it doesn't make all that much sense that Square wouldn't at least port a lesser version of FVII to the Saturn. (let alone fully parallel developments or Saturn priority stuff as had been the case with other things, even in the west like Tomb Raider being released for Saturn slightly earlier than PSX)

Either that, or SoJ totally botched things by not even trying to attract Square. (given the past success tied to Square in Japan, it was pretty significant) And I rather doubt that, but it's possible.

And beyond that, SoJ could have focused resources into a direct competitor with a high-budget 3D Phantasy Star V, but there was no new PS title on the Saturn at all.

Granted, Tom Kalinske left before FVII was even released in the US, and Stolar really did some odd things at that point. (whatever problems the Saturn was having before then, Stolar made worse at E3 1997)
What he did was insane from any conventional or even moderately reasonable marketing perspective. (some stuff made sense, but "Saturn is Not Our Future did not)
Especially pulling that twice in a row, pulling the plug on the 32x early on, and then prematurely cutting off the Saturn. (which was effectively what happened even if they didn't discontinue it until '98)

**sheath** · 09-08-2010, 10:54 PM