Printable View
I see no reason a game with 2D play couldn't have been made of polygons. W/o decent texture mapping it would sound odd, but the Super Mario Worlds had prepared Nintendo fans for tracts of undifferentiated hues. Besides there was always ACM. Nor were the BGs of RE2 lacking.
It was my (laymen's) understanding that this is how the PSX handled 2D games, by using polygons, since it was not built to render 2D. 2D games on the PSX aren't actually 2D, but 3D made to look 2D (i.e. there's a 3D engine running).Quote:
Originally Posted by StarMist
That theory of Nintendo not making and 2D tools available does make me wonder. Because Capcom didn't bother with making any 2D fighters on the N64. I'm pretty sure the vs. games could've at least retained the tag feature on the N64. On a different note why on earth was SNK's support of the Saturn so lacking compared to the PSx? The NeoGeo was mainly a niche system just like the Saturn was. There was also the 4MB ram cart which couldve made the Saturn ports even better but I digress.
Note:
Credit to The New Guy for discussing this previously and making some excellent points about Nintendo's position in Japan.
It was probably more the other way around: Capcom not wanting to publish anything for Nintendo in general (and most games they did publish weren't exclusive and came years after the original versions), let alone a very niche genre. (even more niche outside of Japan)Quote:
Originally Posted by Da_Shocker
The N64 was unattractive to publish for for several reasons, even before the PSX had proven to be the solid market leader: Nintendo was still treating3rd parties like dirt in Japan, the N64 used carts (costly, limited, and risky to publish for), cart manufacturing was totally controlled by Nintendo with 3rd parties unable to produce their own (still that way for the DS), and Sony (and to lesser extent Sega) offered excellent alternative platforms to publish for . . . Sony doing so internationally as well. (unlike previous generations where Nintendo had been a virtual monopoly, or even with competition from NEC and Sega, still dominant in Japan and very strong internationally -had NEC managed things differently, the PCE may have ended up more like the PSX worldwide)
The biggest problems with the N64 (like the Saturn) were not technical at all, but political/bureaucratic/management related (and, like the Saturn, some of the actual technical problems were directly caused by management issues -like the N64's use of carts and the Saturn's lack of a realistic cost/price ceiling)
No, those aren't "modes" on the system, those are microcode implementations on the RSP . . . software (of sorts), not hardware, and in some respects like programming the VUs on the PS2. That was totally programmable: 3rd parties could even program their own custom microcode implementations, and some did, but the tools were extremely limited and difficult to use (and developers didn't have the same incentive as the PS2 to really invest heavily in custom tools -not to mention Nintendo never supporting better tools).Quote:
Originally Posted by j_factor
Fast 3D and Turbo 3D were the 2 standard, SGI-produced microcodes
That was never the argument . . . the only context was looking better than 2D on the Jaguar. (in the context of existing commercial software, not potential performance -as the N64 should technically outstrip the PSX and Saturn in 2D)Quote:
I don't think Yoshi's Story is as good graphically as even the middling 2D efforts on Playstation and Saturn.
On another note, Turbo 3D was rarely used (not sure if any games used it actually), and it makes sense given the limitations of N64 carts (making the much slower fast 3D code generally more attractive). Of course, a compromise would have been much better (even if CDs had been used), and that's what most custom microcodes ended up doing (cutting back on many of the effects and high-precision operations used in fast 3D, but still far more effects than "turbo 3D"). Of course, very few developers actually programmed custom microcodes. (and the most prominent example would probably be Factor 5's stuff -though a couple non-factor-5 Lucas arts games were also fairly impressive -Episode 1 Racer wasn't done by Factor 5 iirc, though I wonder if Lucas Arts was able to license use of some of Factor 5's development tools)
Nintendo obviously dropped the ball on supporting the N64's features . . . unless they'd actually wanted to limit the performance of 3rd party games and keep the good stuff to themselves. (which I wouldn't rule out)
That's from a software PoV, not hardware. From a hardware perspective, the N64 obviously worked well for 3D, but (like most 3D systems) also worked fine for 2D . . . and more so, the super flexible design (with a good amount of general purpose resource with the RSP rather than a fixed-function GPU like the PSX) was actually closer to the Jaguar's balance in some respects -or even more like the PS2 in some respects -with the RSP somewhat comparable to the PS2's VUs and both relying high-speed narrow width RDRAM. (aside from 2D, that made for massive potential in flexibility for 3D and pseudo 3D if programmed for such -of course, the RSP microcoding tools were notoriously terrible and very few devlopers used custom microcode -RARE, Nintendo, and Factor 5 are among those- . . . but it cerainly would have been interesting to see what other sorts of 3D it could have pulled off or pseudo 3D -ray casting and voxel stuff- or hybrid engines -polygon/sprite/ray-casting/voxel, like Outcast on PC; let alone plain 2D performance -though the latter should have been fairly capable with the standard "turbo 3D" microcode)Quote:
Originally Posted by sketch
If anything, the PSX was more 3D-specific than the N64, though it was quite capable of 2D as well. The GPU was primarily designed for 3D drawing, but -by definition- 3D is rendered with 2D operations, so you've already got a lot of 2D drawing resource (though far more silicon dedicated to 3D performance than a 2D-optimized system would). To help with that more, the PSX has a specific "sprite" drawing mode that makes the GPU behave more like a 2D blitter: in that mode, the GPU renders flat rectangles that can be scaled/stretched vertically and horizontally, but not rotated or skewed. (aside from plain 2D games, that's also useful for scaled sprites in 3D games since it takes less bandwidth than doing full 3D textures)
AFIK, the standard microcodes for the N64 had no such "sprite" support (for faster rendering of simple 2D/scaled textures), though you did still have the potentially massive bandwidth advantage of the N64's 500 MB/s RAM. "Fast 3D" was hindered for fast drawing by excessive use of high precision operations and many 3D effects, but Turbo 3D is a different matter. From what I understand, Turbo 3D focused on relatively PSX-like 3D drawing (simple affine texture rendering, no perspective correction or filtering, no AA, etc) and could do such 3D rendering several times faster than the PSX itself . . . so, while there would still be some added overhead than truly optimized 2D drawing support (ie a 2D-oriented microcode), it already should have been able to outstrip the PSX for 3D and 2D using "turbo 3D" due to it being so much faster. (a rough comparison for turbo 3D gives the N64 a 3x speed advantage over the PSX)
Most left Nintendo because they'd wanted to for years, but didn't have an option . . . they almost had with the PC Engine, but NEC didn't mange to pull near what Sony did (especially Sony efforts to specifically attract 3rd parties, let alone competitive marketing). It's no surprise Sony had Namco as a flagship publisher . . . Namco had been one of those trying hardest to break away from Nintendo, even so far as ceasing publishing in the late 80s only to be forced back by Nintendo's dominant marketshare (and forced to make a humiliating public "apology" to Nintendo).Quote:
As you pointed out, Japanese third party developers were the only ones making those types of games, and they left the N64 like rats leaving a sinking ship. All the arguments about N64's 2D capabilities are purely theoretical; using example of the small library of 2D games is pointless as obviously there was never any real effort put into 2D on this machine for the reasons stated previously.
Nintendo's use of carts didn't help attract developers either . . . rather it epitomized Nintendo's trends for being unfriendly with 3rd party publishers and striving for a tight grip over software production. (not only making games more costly/risky to produce -and more limited in capacity- but forcing all manufacturing to go through Nintendo, not allowing 3rd parties to manufacture their own games -same problem with the DS to this day iirc)
Nintendo seemed to treat 3rd party publishers almost like unwanted competition that should be happy to have the privilege to publish for Nintendo systems, rather than treating them as useful and desirable business partners. (this was worst in Japan by far . . . in the US, Nintendo had always been at least a bit more civil with 3rd parties and, by necessity, had loosened up licensing contracts substantially in the early 90s due to a combination of litigation/threats and competition from Sega -in Europe Nintendo had never had a hold over 3rd party publishers at all and they only got significant licensed 3rd party contribution after they'd started loosening their policies)
Also, there were western developers pushing 2D a fair bit too, but almost none of those games went to N64. (the Rampage games are the only ones I can think of) It's was still niche of course, even in Japan. (and likely wouldn't have helped Nintendo's sales much in general -though having better relationships with 3rd parties would reach far beyond 2D games)
Yes and no . . . the PSX uses its 3D-optimized drawing hardware to render 2D objects.Quote:
Originally Posted by sketch
3D rendering involves a lot of the same rendering performance as 2D (after all, you're projecting 3D graphics onto a 2D plane -that's what rasterization is), so while there's a lot of logic dedicated to 3D operations in the PSX (GTE for 3D math, hardware polygon projection/skweing/shading/texture mapping on the GPU), there's still a lot of resource for "normal" 2D rendering.
The GPU actually has a specific 2D drawing mode that optimizes that even further (omits most of the 3D drawing functions to cut overhead). Usually referred to as the "sprite mode," the GPU renders 2D rectangles that can be stretched/zoomed (scaled) but not rotated or warped. (the theoretical peak texture mapping speed is also equal to the peak sprite rendering speed -33 Million pixels per second- but sprite mode tends to get somewhat closer to that figure in real world applications due to lesser overhead in other areas) This mode still technically renders in triangles, but the GPU automatically attaches a pair of triangles and treats it as a single rectangle (so it's programmed as rendering rectangles, you're not rendering triangular sprites). To do rotated/warped sprites, you do have to use the normal 3D modes though. (albeit still with much less overhead than an 3D game would -mainly on the CPU end for simple game logic/no Z-sorting/etc)
The Saturn VDP1 and 3DO Cel engine are both also similar to the PSX in having 3D features in hardware along with 2D optimized drawing modes, but are generally less optimized for pure 3D rendering. (in some respects it's a bit like 3D drawing modes were built onto more traditional 2D blitters vs the PSX GPU being a 3D drawing processor with 2D drawing capabilities as an extension of that -the Quad rasterization of the 3DO and Saturn is part of that -somewhat like a direct extension of the Sega CD's ASIC -which rendered scaled/rotated rectangles without skewing- or the jaguar's blitter -similarly rendering scaled/rotated rectangles- in both cases requiring added overhead to skew objects -drawing 1 line at a time, and that was the primary feature the 3DO/VDP1 added -ability to skew the textures in hardware by setting 4 arbitrary points for the corners of the quad rather being limited to rectangles -the PSX GPU, by comparison, was designed around drawing triangles, not rectangles or quads, though it still worked on many of the same drawing principles -all used affine texture rendering, including the MCD and Jaguar)
The N64, by comparison, didn't have only fixed-function graphics hardware (albeit neither did the Jag). The fixed-function/blitter-like portion of the N64 was the RDP (the reality drawing processor) while the RSP was very flexible and programmable (and the part reliant on microcoding).
Neither of the standard microcodes offered in the SDK had a "sprite mode" as such, though both could still be used to render conventional 2D objects (Turbo 3D far faster than "fast 3D" due to the lack of unnecessary features bogging it down), though I'm not sure any of the 2D games on the N64 actually used that. (I'm not sure when the "turbo 3D" code was added to the SDK, but I don't think it was there from the start)
A fully optimized 2D microcode should have been best, but the existing "turbo 3D" code should have been enough to compete fairly well against the PSX and Saturn -if not outstrip both of those, at least in some areas of 2D.
But even with the existing tools (and lack of 3rd parties pushing custom microcodes), you still have a far more fundamental issue: lack of interest for 2D games and an even greater lack of interest in publishing those games on the N64.
It's not like the N64 got a bunch of weak 2D games on it . . . it got almost no 2D games at all. (it's not even an argument of sloppy ports to a less popular system, but a general void of software)
It sounds like you're talking about the texture cache on the N64, and confusing some things.Quote:
Originally Posted by Robotwo
The N64's "graphics memory" isn't very limited at all: it's got the whole pool of 4MB shared memory to work in (that 4MB is used similarly to the 2MB+1MB+512k of the PSX, but shared on a single high-bandwidth bus rather than slower dedicated buses -and also more flexible for parsing out that memory for different uses; the Jaguar, Xbox, and 360 also did that . . . PS2 sort of did -though it had a massive chunk of local video memory). Optimizing a system for a unified memory bus is one of the more significant cost optimizing design possibilities for any computer system.
You also had card memory to work from (which was slow, but far faster than CDs at least), but that was generally heavily compressed and used more like CDs or HDDs for better cost effectiveness. (uncompressed games would need huge ROMs . . . or far more limited in similar ROM sizes)
It's that main memory that the RAM pak expands, doubling it from 4 MB to 8 MB. (a stock N64 has a comparable amount of memory to the PSX or Saturn -more than the PSX and slightly less than the Saturn, but arguably effectively more than the Saturn due to it being shared rather than limited to dedicated subsystems -especially since 512k of the Saturn is limited to the SH1/CD-ROM buffer, and another 512k is used for the framebuffers -which usually need far less than 512k)
The only "limited" memory usually mentioned in context of the N64 is the texture cache, which is 4 kB (compared to 2 kB on the PSX and none on the Saturn). The limitation compared to the PSX is that the cache is software managed rather than hardware managed (so the RSP has to manually load texture data into it rather than that being done dynamically by caching logic). That can mean that poor programming (or a limited tool set or API) will restrict texture performance or make use of large textures more difficult (the cache can fit 32x64 or 32x32 16bpp textures -the latter if mipmapped, so anything larger than that would need to be tiled -reloading the cache for each segment of the large texture- which the PSX does automatically).
There may also be additional issues for trying to texture map outside of the cache (if there's no added buffering/logic to facilitate efficient uncached textures, that could be very slow compared to cached textures), so efficient use of caching may be even more important. (I think the PSX has some optimization for working outside of cache, and the Saturn is totally designed around uncached texture mapping)
The Expansion Pak doesn't help any of the difficulties of using the texture cache and doesn't help ROM limits much either, but it does provide that much more RAM to load into (for more complex/detailed games with fewer loading sequences -similar to adding RAM to any CD/DVD based system -or PCs). A framebuffer can take up a lot of space for higher resolutions, so it's no surprise that highres modes were one of the most common features of Expansion Pak supported games. (640x480 in 16bpp double buffered takes ~1.2 MB -so almost a third of the entire N64's RAM and more than the entirety of the PSX's VRAM- compared to just 300 kB for 320x240 double buffered -which is also why high-res Saturn games are limited to 256 colors for VDP1, 256 color graphics use 8bpp framebuffers, so half the space of 16bpp)
No they didn't . . . Nintendo didn't get very good JP publisher support at all, and it's no surprise why: Nintendo's stubbornness following the same pattern it had towards 3rd parties since the Famicom (ie extremely unfriendly -carts on the N64 putting that over the top). Many (like Namco) had been trying to get away from Nintendo for years, but (until Sony) that had no real alternative. (Namco in particular had tried to stop publishing for Nintendo in the late 80s only to be forced back in by Nintendo's sheer dominance on the market -NEC might have offered an out like Sony did later on, but they didn't push nearly as hard as Sony in a number of aspects -though, aside from management decisions, NEC was in a very similar position with the PCE as Sony with the PSX)Quote:
Originally Posted by Team Andromeda
Hardware had very little to do with Nintendo's problems . . . and the cart use on the N64 was more a symptom of their internal problems than an actual hardware design flaw. (hardly a design flaw of the chipset/based hardware, but obviously a marketing/management decision tied predominantly to maintaining Nintendo's status quo -something that obviously backfired)
This was discussed before, here:
http://www.sega-16.com/forum/showthread.php?17275/page5
Even with the available toolset, the N64 should have been quite capable in 2D . . . and had it gotten the 3rd party interest, they would have likely pushed far more for custom micerocoding (for 2D and 3D -since SGI's standard codes weren't especially good for either, and they never expanded upon the limited fast and turbo 3D codes -or if they did, Nintendo kept those to themselves). Rather like how the PS2 got custom tools/support in spite of limited SDKs. (the PS2's VUs and N64 RSP are somewhat comparable in that respect -except the N64 arguably had better default API support, though still with limited performance from only having the standard microcodes to work with)Quote:
but it was clear from NCL own direction and tool set they were all for the 3D route and so 3D parties followed suite so rather than make a 2D Castlevania Konami made a 3D one, rather than make a 2D Bomberman Hudson made a 3D one and so it went on .It also can not be overlooked that the High Price of Carts and NCL launching so late gave a huge advantage for the Saturn and PS to become the home of Arcade ports for smaller parties in Japan and that's an advantage they kept
The hardware itself should definitely have outperformed the PSX in 2D and likely the Saturn as well. (obviously outstripping VDP1 -which the PSX does easily- but possibly not beating certain types of games with very heavy use of VDP1 BGs and relatively limited use of sprites -ie games pushing so hard for BGs that VDP2 actually gets maxed out and VDP1 is not a bottleneck)
The software support was so limited for those arcade boards, it hardly makes for an argument at all. (like arguing the same for the Co-Jag for that matter -the Jag hardware should have managed more impressive 2D than anything on the co-jag including prorotypes . . . and more impressive than anything 2D on the N64 for that matter ;) -closer to the best 2D on the PSX with some trade-offs- . . . the Cojag could have pushed that even further though)Quote:
Also has confirmed by Seta their Arcade 64 board (ALECK64) had boasted 2D graphics to help it compete with the likes of ST-V and System 12 and even then it was outclassed by the ST-V
The Dreamcast, GC, PS2, and Xbox were all totally superior to the Saturn/PSX/N64 for 2D (and 3D), but there wasn't a whole lot to show 2D performance on those either. (perhaps enough to demonstrate they were better than the old systems, but not nearly enough to show them maxed out for 2D simply due to lack of interest in that genre of games)
I'd Say Mario 64's textures are no exception at all. All games varied a bit, but there's inherent trade-offs when working with limited storage (ie compression artifacts vs lower res vs fewer unique textures -the latter meaning samey environments and/or small textures repeated/tiled over large areas).Quote:
Originally Posted by Team Andromeda
It varied a lot depending on the specific game's art design as well as technical aspects. (larger ROMs didn't always mean better textures since that memory could go to other things -like larger/more varied levels/worlds, not to mention a few games using streaming soundtracks -Pod Racer did all music that way)
As it was, the larger N64 games should have been getting fairly close to most single-disc PSX games (at least games that used a lot of the disc for CD-DA and/or cutscenes), but that's variable too. (the best cases would be large -ie 32/64 MB- N64 games with fully synthesized audio and no FMV with limited speech vs PSX games that used uncompressed game data and at least 2/3s of the disc for non-game data -streaming audio, FMV, etc- otherwise you'd still have a pretty massive discrepancy between N64 and PSX game sizes -compression on cart probably wasn't going to manage much better than 4:1)
The texture cache is sometimes claimed to be a major limiting factor, but that really shouldn't have been the case. (it's twice the size of the PSX's cache, though software managed -and thus more programmer dependent . . . probably limited by the standard tools as well) The N64 may also have a bigger penalty for uncached texture rendering compared to PSX or Saturn (Saturn only does uncached textures -there's no cache), but I'm not sure on the details of that. (it limit imposed by the standard microcodes and not an actual hardware limitation)
I'm not sure if the N64 homebrew community would have any more info on the subject. (N64 homebrew seems relatively limited -though the Everdrive 64 might change that- and I'm not sure how much low-level hardware documentation was ever leaked)
The N64's memory bandwidth alone points to a major advantage over the competition (especially for something like 2D where CPU overhead is very limited -so not much bandwidth contention), but to know the full extent of that advantage would require more detailed information.
They are modes. The designers created two microcodes that developers could select from. Two different methods of implementing the hardware -- two modes.Quote:
Originally Posted by kool kitty89
Only specific developers were allowed to microprogram the RCP. And doing so was a separate endeavor, with separate tools. It's not correct to say it was "totally programmable". Standard N64 development did not include that ability.Quote:
. . . software (of sorts), not hardware, and in some respects like programming the VUs on the PS2. That was totally programmable: 3rd parties could even program their own custom microcode implementations, and some did, but the tools were extremely limited and difficult to use (and developers didn't have the same incentive as the PS2 to really invest heavily in custom tools -not to mention Nintendo never supporting better tools).
Right, and my point, which you ignored for whatever reason, is that SGI, the designers of the chipset, did not see fit to create a 2D optimized microcode. They only created two different "3D" microcodes (which were nevertheless used for some 2D games). None of the custom microcodes were for 2D either -- they were only small tweaks based on the two standard ones.Quote:
Fast 3D and Turbo 3D were the 2 standard, SGI-produced microcodes
Right, and you never really elaborated on why you think Yoshi's Story looks better than Rayman. I'm just not seeing it at all.Quote:
That was never the argument . . . the only context was looking better than 2D on the Jaguar.
Isn't Yoshi Story 2D?
Now since when did I ever try and make out using Carts was a hardware design flaw ? . And the fact of the matter is N64 had a lot of the Major 3rd Japanese 3rd parties working on it and they just went down the 3D route rather than the 2D route . I really don't know why you bring up Namco ECT. Yes Anyone with a knowledge of history knows there was deep hatred between the 2 corps Masaya Nakamura even publicly knocked NCL and its then chairman and only ever supported NCl after due to marketshare , but then again Namco were hardly a 2D powerhouse on the PS either .Quote:
No they didn't . . . Nintendo didn't get very good JP publisher support at all, and it's no surprise why: Nintendo's stubbornness following the same pattern it had towards 3rd parties since the Famicom (ie extremely unfriendly -carts on the N64 putting that over the top). Many (like Namco) had been trying to get away from Nintendo for years, but (until Sony) that had no real alternative. (Namco in particular had tried to stop publishing for Nintendo in the late 80s only to be forced back in by Nintendo's sheer dominance on the market -NEC might have offered an out like Sony did later on, but they didn't push nearly as hard as Sony in a number of aspects -though, aside from management decisions, NEC was in a very similar position with the PCE as Sony with the PSX)
Hardware had very little to do with Nintendo's problems . . . and the cart use on the N64 was more a symptom of their internal problems than an actual hardware design flaw.
Here you go again. I'm sure you just post this to wind people up. I seriously doubt the N64 could have handled the playfields of the Saturn , and I've never ever saw a PS 2D with better graphics than Cotton II on the Saturn , which is a 2D showcase of the system might. Why you have such a hard time giving and accepting the Saturn was the king of 2D at that time I really don't know , more so when more or less every developer (working on all systems) said when it came to 2D the Saturn was in a class of it own. Even Namco praised the Saturn 2D strength and better texture maps, which surprised me to say the leastQuote:
The hardware itself should definitely have outperformed the PSX in 2D and likely the Saturn as well. (obviously outstripping VDP1 -which the PSX does easily- but possibly not beating certain types of games with very heavy use of VDP1 BGs and relatively limited use of sprites -ie games pushing so hard for BGs that VDP2 actually gets maxed out and VDP1 is not a bottleneck)
Now just compare Treasure 1st Saturn game (which was early) to their 1st N64 game and tell me which is the best for 2D - I think its quite clear to anyone that plays both.
Mario 64 is the only N64 game that does't suffer from washed out textures and blurry graphics , more or less every other N64 game I've played does, even ones that use the RAM cart. Seems to be an issue with the SGI chipset to me and if it was only down to issues of RAM , well the RAM cart didn't fix it and then one would have to question the engineering at both SGI and NCL for not addressing this issues before the system launched.Quote:
I'd Say Mario 64's textures are no exception at all. All games varied a bit, but there's inherent trade-offs when working with limited storage (ie compression artifacts vs lower res vs fewer unique textures -the latter meaning samey environments and/or small textures repeated/tiled over large areas).
Now you can carry on with your 1000 worded replay to try and put people to sleep and beat them into submission, but everyone knows when it came to textures and a crisp clean display the humble Saturn and PS were simply much better than the N64 and they were also better for 2D games and graphics, end off.
Just play the actual games on the actual systems and it's as clean as day, The end
No, those aren't hardware, they're software . . . like using 2 different game engines. (in a very, very generalistic sense) And actually, I think "fast 3D" was the only one available initially. (not positive on that, though few if any developers used the "turbo 3D" code in any case -which definitely should have been the one to use for 2D games due to its feature set catering far better to that than "fast 3D")Quote:
Originally Posted by j_factor
Having those microcode implementations called "fast 3D" and "turbo 3D" doesn't mean they're not good for 2D either . . . though it does imply that they're at least oriented towards 3D. (even so, you could have such a case where 2D performance was still quite substantial and competitive for the time -which appears to be the case for Turbo 3D, though I haven't seen enough details to be absolutely sure on that -from what I have seen, it appears to have a similarly optimized feature set to the PSX's rendering methods)
It's obviously not a hardware limitation, but a limit of the development tools: both in selection of default microcode and general lack of microcoding tools.
If the PSX was released with tools and an API that supported only the 3D rendering, it wouldn't make the hardware any less capable . . . just make it less convenient for programmers to actually get performance out of the system . . . or for that matter, if they released it with no API or high-level tools at all and just low-level documentation. (except you'd be better off there too unless the documentation was buggy/incomplete) Albeit that's still a vague analogy for microcoding vs general programming on a system. (more comparable to what happened with the PS2's VUs -except you saw FAR more support pushed for those due to Sony's dominance and general 3rd party interest -and Sony's good treatment/relationships with most 3rd parties)
The hardware design was inherently flexible, but (like a few other platforms) the development tools for said hardware. (and not just high-level programming support, but a lack of good low-level documentation or tools -something that was a problem on the Saturn too, on top of lacking high-level stuff)
Again, I wonder if Nintendo intentionally limited the microcodes available and the development tools for 3rd parties . . . given some of their other actions, it wouldn't be out of character.
AFIK, it wasn't so much "allowing" developers to do so, but having extremely limited tools that made programming RSP microcode a major investment. (something not many N64 developers were willing to make)Quote:
Only specific developers were allowed to microprogram the RCP. And doing so was a separate endeavor, with separate tools. It's not correct to say it was "totally programmable". Standard N64 development did not include that ability.
If Nintendo had intentionally witheld microcoding tools or prevented use of custom microcoding, that would be another story too . . . certainly not a hardware limitation, but Nintendo basically crippling the hardware for 3rd parties. (which, again, wouldn't be totally out of character for them -and would make me wonder even more how Sega might have managed a partnership with SGI ;))
Apparently they also didn't see fit to produce decent microcoding tools . . . allowing customized microcoding should have been a touted feature of the system like the VUs were on the PS2 (also difficult to work with, but at least better supported than for coding 64's RSP).Quote:
Right, and my point, which you ignored for whatever reason, is that SGI, the designers of the chipset, did not see fit to create a 2D optimized microcode. They only created two different "3D" microcodes (which were nevertheless used for some 2D games). None of the custom microcodes were for 2D either -- they were only small tweaks based on the two standard ones.
On top of that, SGI should have been willing to produce (or aid) further microcode implementations at very least if Nintendo deemed it necessary (which they obviously would have if 3rd party interests were taken to heart -as it is, they may have done so and kept them for internal use only).
If the design concept was anywhere close to be planned with such limited "modes", it would have been hugely wasteful to use the RSP at all rather than custom hardwired logic capable of similar performance with far less silicon. (more like the PSX or Dreamcast -or various PC video cards)
As for 2D specific support, yes that probably would have been up to 3rd parties to push regardless (with less heavily invested 3rd parties simply opting to use the most 2D-favorable standard microcode) . . . 2D was (and still is) intrinsically niche on the mass market, so explicitly investing in that wouldn't make much sense. (providing flexible customization for 3rd parties to use for tweaking 2D and 3D performance would be another matter though -and even with decent tools, RSP programming would still have been fairly intensive . . . just nowhere near as bad as it currently is)
There's also 1 other option: bypassing the RSP and software rendering with the CPU . . . or possibly using the CPU in conjunction with the RDP. (but either of those would probably be worse for 2D than the Turbo 3D microcode -perhaps not as bad as fast 3D . . . probably somewhere along the lines of software rendering on a Pentium PC with 66 MHz SDRAM and a PCI SVGA card)
Namco was just 1 example . . . pretty much all of Nintendo's 3rd parties had been treated similarly in that respect, and you didn't see a lot of 3rd party support from any of them. (Capcom's support for the N64 was certainly a pittance, Konami similarly so though perhaps not quite extreme, among many others)Quote:
Originally Posted by Team Andromeda
I'm not trying to wind anyone up . . . just trying to point out the truth of the matter as far as I can see.Quote:
Here you go again. I'm sure you just post this to wind people up. I seriously doubt the N64 could have handled the playfields of the Saturn
And yes, as I said, VDP2 would be the only possible area of contention for superiority, but only for games that really pushed the BGs hard and were not bottlenecked in the sprite department . . . VDP1 was a weakness for 2D (aside from 3D) against the PSX (super sprite-heavy games -or games using sprite-like BGs would favor the PSX more, though full-plane BG heavy games would obvioualy favor VDP2's capabilities).
The N64 has TONS more bandwidth for rendering than the PSX (500 MB/s peak vs 133 MB/s peak), closer to the Dreamcast in that area (assuming you had software to actually tap that).
The Saturn was obviously good at 3D, but some people seem to think it was better than it actually was . . . or degrade the potential of other designs due to the existing software (which may or may not have any relation to the hardware's capabilities).Quote:
Why you have such a hard time giving and accepting the Saturn was the king of 2D at that time I really don't know , more so when more or less every developer (working on all systems) said when it came to 2D the Saturn was in a class of it own. Even Namco praised the Saturn 2D strength and better texture maps, which surprised me to say the least
If the Dreamcast, GC, Xbox, or PS2 (or PCs of the period) happened to have no showcase 2D games produced at all (thus leaving the Saturn with more impressive 2D games), that still wouldn't take away from the hardware being more capable of 2D than the Saturn. (though it would indicate a lack of developer interest in those genres)
Or from the other perspective: the Neo Geo has tons of impressive looking/sounding 2D games, but that doesn't change the fact that it's actually weaker at 2D rendering than the jaguar, PSX, Saturn, or N64 (and 3DO in some respects).
It's obviously a matter of context. (if Nintendo had actively TRIED to push 2D on the N64 and/or the market of the time had a major interest for 2D games and the N64 got many 2D games but still had relatively poor 2D game performance in those games, it would be a decent indicator of hardware limitations, but that couldn't be further from the case)
I really don't see it . . . Mario looks just as blurry/limited as most N64 games, if not worse in many respects (very few, repetitive, blurry textures and highly stylized art that caters to limited textures or no textures at all). Either of the Zelda games are far more impressive in that regard IMO, or almost any of the Lucas Arts titles.Quote:
Mario 64 is the only N64 game that does't suffer from washed out textures and blurry graphics , more or less every other N64 game I've played does, even ones that use the RAM cart.
The only thing Mario 64 did well on graphics, was using a very stylized/surreal setting/art style that made the limited textures rather fitting.
Why would RAM help? (RAM would allow more complex game engines, fewer load times, and higher screen resolutions, but wouldn't do much for textures if they still had to be loaded from ROM carts -had the system used cheap/high-capacity disc storage, then RAM expansion generally should have meant significantly improved textures too -since mass storage capacity is virtually unlimited- but that's not the case with the N64 . . . plus the N64 started out with enough RAM to be more than competitive with the PSX and Saturn)Quote:
Seems to be an issue with the SGI chipset to me and if it was only down to issues of RAM , well the RAM cart didn't fix it and then one would have to question the engineering at both SGI and NCL for not addressing this issues before the system launched.
Carts were the primary limitation, the second biggest issue was using the texture cache efficiently for large textures (probably ignored far more due to the limited ROM space).
If later gen games had been just as simple and limited as early gen ones, but used the larger ROMs exclusively for added textures, it would be another story, but that's not the case. Most games got larger and more complex as time went on, so rather than simply using larger/higher-res textures, there was always the issue of needing a larger number of unique textures for those larger worlds (if you didn't want everything to look samey), not to mention the added game data and 3D model information. (not to mention sound data)
Compression schemes could only go so far as well, especially in the context of lossless compression. (and late gen games probably didn't see a massive improvement in compression over early ones)
From the perspective of existing software, yes, from any other perspective, absolutely not.Quote:
Now you can carry on with your 1000 worded replay to try and put people to sleep and beat them into submission, but everyone knows when it came to textures and a crisp clean display the humble Saturn and PS were simply much better than the N64 and they were also better for 2D games and graphics, end off.
Again, a totally different context . . . you're talking about games that were made . . . I was talking about what the hardware was nominally capable of. (had Sega or Sony had the same hardware, it would obviously have gotten far different software support)Quote:
Just play the actual games on the actual systems and it's as clean as day, The end
Where do you come up with this stuff?! :|Quote:
Originally Posted by Team Andromeda
Honestly most of its so off base that much of the time I can't be bothered to have an in-depth argument with you (you just disagree without providing counterarguments most of the time anyway)
The only big 3rd party Japanese companies who put anything much on the system were Konami, Hudson, and Treasure, and none of them were developing primarily for N64 (Treasure, and Hudson gave about equal attention that generation, whilst Konami's primary market was PS1).
Capcom made a pitiful two games, Magical Tetris Challenge and Mega Man 64, Mega Man 64 was a lazy port arriving two whole years after the PS1 game (Resident Evil 2 on N64 was ported by a US company)
Namco made nothing (Ridge Racer 64 was developed by Nintendo)
Taito made one title in total, Bust-A-Move 99' (the earlier Bust-A-Move for N64 wasn't even ported by them, it was ported by Probe for Acclaim)
Compile just released a couple of their popular Puyo Puyo games
SNK made nothing
Square made nothing
Bandai published one (bad) game.
Tecmo made nothing
Enix published 1 game (Treasure's Mischief Makers)
Game Arts made nothing
Data East made nothing
Sunsoft just made the two crappy Chameleon Twist games.
Atlus just published the Snowboard Kids series for Racdym
Masaya, Eighting, Imagineer, Cave, Technosoft all of those companies made nothing
:ok:Quote:
Originally Posted by StarMist
I recognize the N64 has certain limitations which have often been pointed out on these boards, but I liked the system. It had its strengths as well (reduced load times being an obvious one). It's unfortunate that the system didn't get a lot of support in general, as who knows what it could have done in both 2D and 3D if it were pushed to the max by all the talented developers at the time. I don't pretend to follow everything you say above:), but it sounds to me like the system would have been a great 2D machine in the right hands.Quote:
Originally Posted by kool kitty89
I recall reading that Nintendo required a minimum cart run for any games that were published for the N64. I'm sure that's a big reason why a lot of smaller and medium sized developers eschewed the platform (not to mention some of the bigger companies like Capcom who probably didn't like being told how much risk they had to take on any given game, whether they could afford it or not). Japanese developers didn't support the system, but also it got weak third party support in general compared to PSX. Nintendo really did treat their third parties like crap. It's amusing because it's almost like they thought they were still the market leader and were so attractive that they could dictate terms to developers and they would just snap in line (a bit like Apple does these days). They were so wrong:)Quote:
Originally Posted by kool kitty89
Agreed. 2D games, RPGs, and to some extent, fighting games were almost nonexistent on this platform. A shame, really.Quote:
Originally Posted by kool kitty89
Wiki claims RE2 was ported by a combined staff of Capcom Production Studio 3, Angel Studios and Factor 5, and that Capcom also published it in the US. (though not Europe)Quote:
Originally Posted by Thenewguy
All excellent points in any case . . . I'd rep you but I have to spread more around first. ;)
I didn't say they were hardware. But microcode isn't software either.Quote:
Originally Posted by kool kitty89
Most systems aren't microprogrammable at all. Considering Nintendo didn't design the system, or even create the standard microcodes*, it was probably a genuine oversight; Nintendo just didn't know what to do with it.Quote:
Again, I wonder if Nintendo intentionally limited the microcodes available and the development tools for 3rd parties . . . given some of their other actions, it wouldn't be out of character.
* - Did Nintendo ever create any custom microcodes, even? I'm not aware of any first-party N64 games that did, but I'm not positive.
That was not the impression that I got.Quote:
AFIK, it wasn't so much "allowing" developers to do so, but having extremely limited tools that made programming RSP microcode a major investment. (something not many N64 developers were willing to make)
Nintendo? Did they produce the tools in the first place? Or did SGI?Quote:
Apparently they also didn't see fit to produce decent microcoding tools
It's hard to classify as such, but microcoding the RSP (in RSP local RAM) is software as much as coding machine language on a CPU.Quote:
Originally Posted by j_factor
For many DSPs, the microcode is the instructions and the chip is programmed directly with microcode in local memory (either on chip or an external scratchpad). It's a different case than CISC CPUs with microcode in ROM used to decode complex instructions to simpler operations handled by the logic on the chip . . . for such DSPs, there is no decoding of complex instructions as such, but the bare logic directly programmed through microcode. (in some respects, comparable to stripping a CISC CPU of its microcode and programming to the bare logic directly)
Many DSPs (especially DSPs produced up to that point) were programmed directly through microcode as such . . . in fact, I believe the Super FX chip was programmed in such a way.Quote:
Most systems aren't microprogrammable at all. Considering Nintendo didn't design the system, or even create the standard microcodes*, it was probably a genuine oversight; Nintendo just didn't know what to do with it.
Nintendo obviously knew about the programmability of the RSP eventually, since they (and several 2nd parties -and close 3rd parties) implemented custom microcode in some in-house games.
Unless there were specific restrictions imposed by SGI's contract, it should have been in Nintendo (and perhaps SGI's) best interests to invest in better tools and documentation for the RSP and the system in general. (I'm not positive on what was available, but making detailed, accurate low-level documentation available would have opened up the possibility for optimized custom APIs -in addition to RSP programming . . . obviously less-invested developers would tend to stick to the standard high-level tools -or perhaps tools licensed by other 3rd parties- but the morededicated developers could have made much more of such documentation -sort of like developers complaints about the PSX initially lacking complete low-level documentation, though they obviously also appreciated the relatively well thought-out library available in the SDK . . . and at least it wasn't like the 3DO where they actively prevented ANY low-level programming including assembly language optimization for CPU code)
It was my impression they did, though I forget which games specifically used it. (I think Majora's Mask did) RARE and Factor 5 both put effort into RSP microcoding though.Quote:
* - Did Nintendo ever create any custom microcodes, even? I'm not aware of any first-party N64 games that did, but I'm not positive.
I assumed it was a collaborative effort (perhaps with another party involved too), but in any case Nintendo should have had some influence on tools and documentation for the hardware (ie commissioning them from SGI) . . . unless there were specific exceptions to that in their contracts. (or, again, if Nintendo wanted to intentionally limited 3rd party developers -or especially to have power over who could get added tools/documentation)Quote:
Nintendo? Did they produce the tools in the first place? Or did SGI?
I also wonder if Nintendo had a special deal with SGI for the development units . . . the only standard/licensed Nintendo dev system was a high-end ~$10,000 SGI workstation, and only thanks to 3rd parties did the likes of the Doctor 64 come to market for only a few hundred dollars.
Regardless of all that, the standard tools available still should have allowed decent (if not highly competitive) 2D for the time (especially "turbo 3D") . . . but the fact of the matter was that few publishers bothered with 2D games on the system at all, good or bad there were almost none at all. (somewhat comparable to 2D games on the Dreamcast, PS2, GC, or Xbox)
Well, I'm basing what I said mainly on this interview -Quote:
Originally Posted by kool kitty89
http://www.gamasutra.com/view/featur...l_studios_.php
Which to me indicates very little Capcom input on the programming side (it does mention Factor 5 helping them with the sound quality though)
Correction to earlier post - I don't think Taito actually made Bust-A-Move 99 either (the start screen says "Realtime Developments" which is a Euro company), so Taito don't seem to have actually made any games for N64 at all either, the Bust-A-Move games were on N64 due to Acclaim.