As mention before 1. TMem / Texture Memory / Texture Cache What a stupid idea to make it so damn small 2. Shotty Microcodes 3. Nintendo's unwillingness to let coders write their own microcodes till the end (See Conker & Indy as great examples of what N64 could do with custom microcode) 4. Expensive Carts Google old adds to see how bad n64 game prices were back in the day.
Yeah, bloody thing. I;ve bought 4 off eBay (including one with the console) and all are a bit iffy. Cleaned them all out, you wouldnt believe the crap inside them. The one that came with the console is the best, but it does creak and click. The rest are starting to stiffen or ust getting loose. Seriously reliablity issues- they rectified big time with the Gamecube. Just think, one day there will be no good N64 controller left to use in the world..
The irony is that nintendo promoted the system as a "difficult to master but rewarding depending on how the developer adjusts the machine" but only let them dig into the microcode towards the end I think if the capable German folks of Factor 5 were hired early on, they could have made some pretty impressive tools for the whole span of the n64's lifetime. Just look at their audio system for the n64 -it revolutionised the quality of sound on the machine and the technology lived on in many games - they also made some impressive GB/C audio tools too! I admire Factor 5 and Julian a lot =)
Until recently, HW companies giving a crap about what the developers wanted was the norm in this industry. Just look at Shilpeed in the SCD: what GameArts did there was lightyears beyond what SEGA or even Argonaut were doing with their chips. SEGA could've bought GA and implement their technology in the addon's SDKs.
The N64 design was the best at the time - the 4KB joke of a texture cache was one major limitation (it means all logos have to be tiled). It really makes things a headache. RDRAM latency was also bad but again it's the best they had at the time, for the price. The one MAJOR downside of this was the ass-slow Z-buffer. The best thing to do is draw front-to-back to minimize writes to the buffer (or just turn it off and let backface culling take care of things). The cool thing is that you can enable/disable z-buffering WHILE rendering a single frame - the amount of control you have with the GBI is incredible. The whole structure of the system is incredibly flexible - if you have the tools. Which most developers didn't. Because Nintendo locked down the uCode development tools, most devs just used the SDK-provided Fast3D microcodes. It has been proven capable of MP3 playback WHILE rendering 640x480 hi-res graphics (good job Boss) and also capable of MPEG-1 decompression (Angel Studios). The original Fast3D microcode sucked ass. I used to use it in my own demos. Then I switched to F3DEX (later redesign) and things were a good deal better. Still lightyears behind Factor 5's rendering engine though. It's just a real bear to get it to do that
so technically speaking, which was more advanced in terms of technology? Conker's Bad Fur Day or Indiana Jones?
