Quote:
Originally Posted by
A Black Falcon
What? No, that's not true... sure, in some ways the PC was behind consoles in the early '90s, as is usually true right after a new console generation launches, but as always the PC caught up and passed the consoles, and then did the same after the 5th gen systems started launching as well.
I mean, maybe the PSX and Saturn were more powerful at 2d than most computers in 1995, sure, but by the end of 1996, PCs had surpassed consoles again.
Again (see my response to TA below), I wasn't even originally talking about mid 90s PCs (but the whole analogy to DC/Xbox/PC/GC/PS2 being 2D powerhouses with little 2D software and even less -or none- anywhere near to pushing the hardware).
However, PCs in 1995 could have been competitive (or more powerful) for 2D and 3D than the PSX or Saturn depending on the configuration used . . . even withno hardware acceleration you could have a 64-bit bus pentium class CPU with 33 MHz EDO DRAM and 266 MB/s bus (or a really high-end system with PC-66 SDRAM and a 533 MB/s bus) and PCI SVGA card, and that alone would be pretty powerful for 2D games.
But more realistically (cost-wise) would be a lower end system (be it a late-gen 486 board -possibly with PC- or a lower-end socket-5 or 7 board) with a PCI or VLB accelerated graphics card rather than a basic SVGA card. There were a number of high-performance 2D accelerators in 1995 (or earlier for that matter) like ATI's Mach or S3's Trio, Nvidia's cards, etc. ATI and S3 both introduced relatively long-lived consumer-level 2D/3D accelerator cards/chipsets in 1995 with the RAGE and ViRGE designs (the former expanding to a very prominent 3D accelerator line and the latter owing its long live to persistence in the budget market -though S3 moved on with more powerful 3D designs as well) and both of those had very powerful 2D performance with decent 3D capabilities for the time (more so for the Rage, and that also added MPEG-1 acceleration).
But that's all in the context of hardware performance and available products of the time . . . from the PoV of actual software produced, there wasn't much (or any) 2D accelerator supported games in 1995, so a good accelerator, while technically more cost effective than a fast CPU+fast RAM, wouldn't actually get you much until later on. (2D accelerated games didn't become common until 3D acceleration in games was common, though part of that was also the shift to API level programming in games actually favoring use of accelerators rather than optimized CPU coding) A few early windows games (which were API-oriented) did support 2D acceleration, but there's not many really good examples. (I think Sonic CD on the PC may have supported hardware acceleration . . . it was definitely windows-specific and library-level programmed)
Oh, and then there's the massive advantage or RAM on PCs facilitating far more animation/detail aside from other effects. (8 MB was the bare standard RAM requirement for most 1995 PC games) That's something that had a major impact on 2D and 3D games too.
Quote:
Oh come on, that's absurd. 32X games rarely have any textures at all, and when they do have them they're very blocky, much like PSX or Saturn 3d. The N64's greatest accomplishment was finally getting us a console with decent-quality 3d rendering, with features like Z-buffering, anti-aliasing, perspective correction, and more. Those really are extremely important things to have, and without them, 3d on the consoles before the N64 often looked terrible.
The higher res textures in better PSX and Saturn games do have advantages over the N64 though . . . the warping/distortion problems are bigger than the lack of AA/filtering IMO, but the higher res textures are really noticeable for some things. (granted, some things look better in spite of poorer quality textures while others don't make it worth it -Mega Man Legends looks better on the PSX in spite of the warping issues and jaggies . . . the texture detail is just SO much better)
But again, that should mainly have been a limitation of carts . . . and, again, even with larger, later-gen games you wouldn't see a general improvement in textures necessarily as there's so many other trade-offs for space. (sound samples, larger/more complex game design, more complex 3D models, far more numerous unique textures needed -the latter meaning a compromise for quantity/variety vs quality . . . you could have a very samey looking game with limited textures or just a limited game using a large ROM, but that's not very likely -ie you could have had a 256 Mbit re-release of Mario 64 with far greater texture detail and probably a fair bit more variety of textures as well, but that wasn't likely to happen for obvious reasons ;))
Quote:
Oh, and as for "N64 fog", that's because the N64 has a good fog effect, in order to cover up the pop-in that you'd see instead on those other systems. PSX and Saturn games have average draw distances every bit as bad, or worse, than N64 games do, they just often have to leave it as popup instead of covering it with fog
PSX and Saturn do a form of fog too in some cases . . . namely shading towards white for the objects near the edge of the draw distance (sometimes fading to black instead, depending on the case), but it's more primitive than the N64's distance fog. (or fog offered on PC accelerators -actually I think even the "3D poor" S3 ViRGE supported distance fog effects, though it slowed things down a lot iirc)
Quote:
But anyway, carts are issues because you do have less space to save data in. However, the main culprit causing the blurry textures is the texture cache size, not the medium.
No, I really don't think that's the case . . . and assuming the cache was a major limitation, the limited media certainly didn't give developers much incentive to push beyond those difficulties. (ie with such limited mass storage, there was far less incentive to bother using much larger than 32x32 or 32x64 textures)
The texture cache itself is 2x the size of the PSX's, but it's software managed rather than hardware, so imposes some different limitations (though also some potential advantages over a hardware cache), but that really shouldn't have prevented use of large/high res textures (by tiling a large texture from several consecutive small textures), let alone repeating a limited texture over a large area (so a limited, high-res pattern rather than a single texture stretched over the entire polygon).
There's also the separate issue of uncached texture performance, and I'm not sure if the N64 has problems there. (I think the PSX is fairly good for that, and that's all the Saturn and 3DO can do, but I'm not sure about the N64 -they may have included logic to support fast uncached texture rendering, like source and destination buffers on the RDP, or they could have implemented some of that in the RSP microcode, but I don't know enough about the N64 to say either way -and I'm not sure there's even enough leaked documentation on the system to say)
There's no way the hardware should be that crippled for texture mapping . . . it would be a horrible design flaw that would largely ruin the system's capabilities and I don't buy it at all. (I can see the software managed cache leading to some programming difficulties, but not a hard/fixed bottleneck for the system . . . even with inherently poor uncached texture mapping)
Nintendo made a massive mistake going with cartridges on the N64 . . . there were some technical/user advantages (some of which I like personally), but it was a horrible decision for the market overall (and degraded the software potential as well -both technical quality and quantity/support). Granted, Nintendo hardly did it for any technical advantages, they just wanted to screw over 3rd parties with their bullshit exclusivity of media production (among other areas of poor treatment of 3rd party publishers Nintendo tended towards -especially in Japan). If Nintendo had wanted to support the interests of 3rd party developers, CD-ROM (or even a proprietary CD-like optical format) was a no-brainer. (let alone the advantages for in-house game production)
It's pretty obvious that Nintendo didn't want to use CD because they wanted to maintain an iron grip on publishing for the system in every respect. (not just preventing piracy or unlicensed publishing, but control over the actual manufacturing and distribution of that software, deciding when and how much of a game could be produced, among other things . . . some things they're still pushing on the DS unfortunately)
Quote:
If those games did not continue to release through the generation, and other, higher budget 2d games didn't come to the platform, I really don't think that the chipsets should get the blame. The market, and the sales, should. Publishers just didn't think such games would usually sell well enough to make them. Also, some of the big 2d game makers, like Capcom, turned on Nintendo for most of the generation, and that didn't exactly help either.
Exactly!
I mean, sure, with a 2d-specific instruction set it would have helped them, but would that have actually resulted in many more 2d games on the N64? I am very doubtful.
Quote:
That doesn't mean I think Nintendo did fine with their restrictions on who could use their own microcodes, though. They didn't. Nintendo needed to be more open with their third parties, certainly. Sure, by limiting access you makes your own games look better, but when that hurts your third parties, which you are somewhat reliant on, how exactly is that a good idea? It's obviously a bad one.
This was Nintendo's biggest flaw in general: terrible treatment (and support) of 3rd party publishing (the whole cart issue was part of that). Nintendo had consistently treated 3rd parties (especially in Japan) as competition more than profitable business partners . . . and acted like said 3rd parties should be honored to be allowed to publish games for the system.
I seriously wonder how Nintendo managed to enforce licensing on the Famicom with no hardware lock-out . . . I could see maybe some "honor" coming into play from the Japanese culture, but that would largely have been degraded by Nintendo's horrible treatment of 3rd parties anyway. God knows that wouldn't have happened in the US (or Europe) if Nintendo hadn't had hardware lockout, and even then there's some quite notable unlicensed publishers. (probably would have been considerably more without Nintendo's underhanded tactics to deter retailers from stocking unlicensed games . . . and the rather ironic case of Tengen -ie going all-out to reverse engineer the lockout chip when others ended up using a far simpler, cheaper, and legally foolproof voltage-spike mechanism)
Quote:
Originally Posted by
Team Andromeda
Well you wouldn't , the machine was a poor seller in Japan and being Cart only hurt support. Points I made before, but listen to you NCL were right to delay the machine and SEGA should done the same with the Saturn.
When the reality is thanks to launching early and going with CD-Rom made sure SEGA had great support in Japan , but that was a mistake if we listen to you ....
Chicken and egg . . . new guy and I already went back and forth over this at length.
The N64 launched well in Japan initially, but the utter lack of3rdparty support (and obviously lack of copious 1st party titles -which few ever managed anyway, Sega being among those) quickly led to it falling behind. This was not the case in the US, where numerous major 3rd parties were developing for the system (or collaborating with Nintendo even) and some had substantial launch titles . . . and games that really did well in the public eye in that region. (vs Japan where the N64 was lacking in really attractive software)
Quote:
PC of that period were pretty much crap at 2D untill 3DFX Ect started to add in 2D support into their Cards . Almost every developer at the time said the Saturn was in class of it's own for 2D games and that was reflected in the Saturn games
Firstly, I meant PCs in the context of DC/PS2/Xbox/GC era (as per my general comment -obviously powerful machines for 2D, but next to no software).
However, if you want to get into mid/late 90s PCs:
Powerful 2D acceleration predated 3D accleration by a large margin on PCs (at least as far as mass-market proliferation). Hell, the entire first wave of consumer 3D accelerators put 2D first and 3D second (ATI's RAGE, S3's ViRGE chipset, Nvidia's ill-fated NV-1, and Matrox's cards). That 2D accleration support was initially spurred mainly by windows GUI acceleration, but (by the time 3D acclerators arrived in 1995) also by multimedia demands. (and ATI's original RAGE supported MPEG-1 acceleration on top of powerful 2D and moderate 3D performance -the Rage 2 added MPEG-2 acceleration and the Pro pushed that further to more complete hardware MPEG-2 decoding)
3DFX cam after that with the Voodoo, which itself was intended to piggyback on a previously installed 2D (or weaker 2D/3D) card with the passthrough VGA connector. It was intended as a high-end gaming and workstation accessory initially, leaving more affordable 2D and 2D/3D cards to the masses (or basic VGA and SVGA cards with limited 2D acceleration and far more reliance on CPU grunt). They did enter the mainstream as well once prices got more competitive, and they were quite notable for a time, but 3DFX hardly made up the majority of 3D support in mid/late 90s PCs. (they were never remotely close to a monopoly, and they fell behind the times by not supporting standard APIs -Direct X and Open GL- well -or at all- compared to the competition)
However, as far as games go, there's another side to this:
A huge number of games in the mid 90s used no hardware acceleration at all (or supported minimalistic VGA/SVGA acceleration only) and did almost everything with CPU grunt, as they had for generations prior to that (and as the Spectrum, Atari ST, PC88/980x, BBC Micro, Archimedes, etc). It wasn't until around 1996 that games started to consistently support hardware acceleration (2D or 3D), and that came around the same time that windows-specific games were really emerging, specifically those using API level programming rather than low-level assembly optimized code (and API support for hardware acceleration was a major advantage) . . . though there was a good deal of cross-over for software rendering through the end of the 90s. (some games using less intensive API level software renderers and a few supporting more optimized software renderers -especially for DOS games- as well as hardware accelerated versions -and a very few late 90s games with no acceleration at all, like Outcast -which did so for good reason)
Still, even for unaccelerated games, you could have a pretty damn impressive 2D machine with a mid/late 90s PC (especially in the context of games programmed the old way, or at least with some degree of low-level tweaks and optimization). A decent pentium machine with fast RAM and a fast SVGA card should have kept up reasonably well with the games being done on the PSX and Saturn, if not exceeded them. Memory bandwidth would be the biggest factor, and by ~1996 you had numerous CPUs sporting 66 MHz bus speeds (prior to that you had 33/40 MHz quite common and ~66 MHz for higher-end stuff), though actually having a system with PC-66 SDRAM would be still be a bit high-end at that point (which, with a Pentium -or other 64-bit bus chip- would provide 533 MB/s peak bandwidth -roughly the same as the N64 and several times the PSX or Saturn's speeds -or even compared to the combined peak bandwidth of the PSX or Saturn's subsystems). Though in the context of more common systems of ~1996, regardless of motherboard/CPU bus speed, EDO DRAM would be far more common (which topped out at 33 MHz for common grades) and FPM DRAM as the low-end option (which topped at ~22 MHz, though 16 MHz wasn't super uncommon by that time either) . . . but even with just 16.66 MHz (60 ns) FPM DRAM in a pentium system (64-bit bus) you'd have 133 MB/s peak bandwidth (more than the jaguar, much more than the 3DO) and not too outmatched compared to new consoles on the market . . . while 22 MHz would give 176 MB/s and 33 MHz 266 MB/s (the latter example definitely facilitating a relatively competitive system). Or even an older 486 system (or AMD's "5x86") with a 33 MHz bus and EDO DRAM could manage 133 MB/s.
Memory bandwidth was (and is) a major bottleneck for both 2D and 3D games, but unlike 3D games, it was the primary limitation for software rendering -or for hardware rendering too, but that's another topic. (vs 3D which required far more intensive calculation for 3D point plotting, rasterization, more complex AI and game logic, etc vs limited CPU overhead for logic/AI and the vast majority of resources spent on blitting/drawing the graphics -or a bit more logical overhead if translucent blending, shading, or scaling/rotation effects were used)
Quote:
You see you're just ripping the piss now
No, I'm being honest. I just can't see why you'd think Super Mario 64's textures were impressive compared to later gen releases . . . or even to some other early-gen releases. (the only thing impressive if the art style, not the actual quality of the textures used IMO)
Quote:
How are carts an issues . I've seen better texture mapping on the 32X and it didn't suffer for the display issues of the N64. Seems to me it was a Hardware as well as software issues
Name 1 better example of texture mapping on the 32x . . . excluding tech demos. (though even the Zyrinx demo's textures look pretty poor compared to most N64 games)
Quote:
Software and that's all we should go on, really .
Not hardly when the topic isn't about software at all.
Software doesn't define the capabilities of a machine, all it does is show what was developed at the time in the specific context of the market and the system at hand (defined by management, marketing, market interests, developer support, etc).
If the PSX had flopped and had software no better or more numerous than the Jaguar, that would make it no less capable of a system for 2D or 3D . . . or if it had gotten next to no 2D games at all, that still wouldn't change the fact it was a capable 2D machine . . . or same the Saturn for that matter. :p
Quote:
Pie in the sky stuff and going on what home brew coders can do or say they can do today. Not barring in mind our phones or more powerful that developer kits were back in the day, or massive advances on compression software and what not . Every machine can do something it shouldn't and can be pushed hard now,. But to me , its only fair we go on what was possible and available at the time of the machines shipped.
That's not what I'm saying at all, but you're just not listening . . . I'm close to giving up to your idiocy.
It's really frustrating that you can be so interesting and insightful at times, but act so stupid at other points . . . not just stubborn or biased either, but simply totally ignoring arguments outright.
