nesdev.org

Super Mario 3D World is the only one on that list I actually enjoyed.

Not even Splatoon?

Full disclosure: I don't own a Wii U, and aside from Smash 4 and a brief sample of Rayman Legends I've never played any of the games on that list. I'm just going by what seems to be the popular consensus.

Espozo wrote:The Xbox One vs the PlayStation 4 shows just how important initial impressions are.

More power at a lower price, in a machine that lets you own your own games and doesn't act like a telescreen from 1984 even while it's supposedly turned off? The PS4 wasn't even that great, but apparently Microsoft gonna Microsoft...

I've got to admit, I was kinda underwhelmed when I first saw the Wii U. I didn't really want one, and I'm not even sure why. I do want a Switch, and once I have money I may very well act on that desire.

calima wrote:Isn't that a question of style? Q2 is more realistic with 3d models, Hexen is cartoony with sprites.

I watched some of a high-quality video of Hexen 64, and then switched to a video of Quake II PSX. I physically felt the relief. Hexen is an ugly game.

Which may make it an unfair comparison. How about Quake on N64?

Espozo wrote:Not even Splatoon?

I haven't actually played Splatoon, to be honest.

I probably should, but it doesn't look like my kind of game (I have lousy reflexes) and I can't play multiplayer out here in the boonies (20 miles from nearest meatspace gamer friends + 300-5000 ping) so I imagine the main drawcard would be lost on me anyway.

Just watched some Colony Wars. I bet you could do it on the N64 (aside from maybe the cutscenes, assuming a period-appropriate ROM size), but you'd need to use special techniques. This game makes very good use of additive transparency, making for an instructive contrast with Star Fox 64, and it looks like there may be some high-res texturing too.

It's definitely possible; there's like, nothing going on in it.

I mean, you'd have to come up with a way of doing additive transparency using the color combiner rather than the blender, which at best is going to cut your fill rate in half for those elements. The video I watched makes it hard to tell, but it kinda looks like true-colour, which would hurt fill rate as well. And if any textures didn't fit in the cache you'd have to use a streaming technique like Rare. But yeah, I think there should be enough spare performance.

If all else failed, you could always just use the Turbo3D approach of (essentially) dropping to PlayStation-level rendering fidelity. The reported performance of ~500,000+ polys per second should give you plenty of headroom, and with antialiasing turned off you wouldn't need to worry about your additive transparency scheme screwing with the coverage bits (I haven't done the math here, but it seems like it might be a danger otherwise).

I mean, it may be inneficient as hell for the Nintendo 64 hardware, but I can't think of a single thing the PlayStation could do that the Nintendo 64 couldn't. You could definitely work around no hardware support for additive transparency in that case, either by layering or software rendering. The N64 has enough performance to make either possible.

Rhythm games.

I seem to remember fewer than a half dozen N64 games were 512 Mbit (Conker's Bad Fur Day, Resident Evil 2, PAL Paper Mario, and one of the Pokémon Stadium games) and none bigger than that. But let's say you do manage to talk your rhythm game's producer into paying for a cartridge that big. If you use 448 Mbit out of 512 Mbit for compressed audio at 64 kbps Opus, you can fit about two hours, enough for maybe 75 DDR-length songs. Can Nintendo 64 even decode Opus audio in real time? Otherwise, your music would need to be sequenced, and I imagine that licensing a multitrack recording in order to reduce it to an accurate tracker file is a bit more involved than licensing a studio master.

tepples wrote:I imagine that licensing a multitrack recording in order to reduce it to an accurate tracker file is a bit more involved than licensing a studio master.

It's not. It's the same amount of licensing "work" (i.e. sync license negotiation) but in general cover royalties are lower than those for using a recording.

tepples wrote:Can Nintendo 64 even decode Opus audio in real time?

There is one MIPS target supported and benchmarked by the rockbox project. That shows that Vorbis takes somewhere around 40-50MHz worth of CPU on a MIPS with SIMD instructions.

I'd note that ADPCM might actually provide adequate sound quality given for some sample rates.

Otherwise, your music would need to be sequenced, and I imagine that licensing a multitrack recording in order to reduce it to an accurate tracker file is a bit more involved than licensing a studio master.

I'd expect that the expensive part there is the salary time to convert from stems to sequence data.

lidnariq wrote:I'd expect that the expensive part there is the salary time to convert from stems to sequence data.

Professional music transcription services aren't that expensive, IMO. I'd say it's comparable to translation services for similar amounts of information. (Making a more "musical" arrangement rather than merely transcribing would cost a bit more, but there are probably a lot of people willing to do it for a relatively low price.)

(...but in this hypothetical we could be talking about a non-commercial context where even modest fees are prohibitive.)

tepples wrote:Rhythm games.

I was speaking purely theoretical anyway. If we're dragging in storage limitations, we might as well discuss the increased difficulty in programming for the N64. The PlayStation, theoretically, shouldn't have any advantage over the N64, although I don't know quite enough about the PlayStation hardware to say that decisively.

Espozo wrote:I mean, it may be inneficient as hell for the Nintendo 64 hardware, but I can't think of a single thing the PlayStation could do that the Nintendo 64 couldn't.

Long FMVs ;D CD full of data + mjpeg decoder, but storage mainly.

Vorbis has been proven, and I'll get out Opus etc benchmarks eventually, if only for my own curiosity. The GC controller compatibility is interesting too, but it's sad there was no Guitar Hero controller for the Cube (I do have the bongos, and there is a DDR dance mat).

Rhythm games.

Ha, now that I looked at the DDR list, there *was* a DDR game for the N64, including the dance mat, in Japan:
https://www.n64brasil.com.br/2010/08/ddrddm.html

About additive transparency: I may have been wrong about the fill rate hit.

The basic idea is that while the N64's blender (the thing that combines the pixel pipeline result with the framebuffer) doesn't clamp its output, I'm pretty sure the color combiner (further up the pixel pipeline) does. So clamped addition would need to be performed in the color combiner, meaning you'd need to get the relevant framebuffer data into the texture memory so the color combiner could use it. I've made a couple of realizations since I made my earlier post:

1) I had forgotten that copy mode (which is considerably faster than normal drawing speed) can be used to suck part of the framebuffer into TMEM.

2) I'm not clear on how fine-grained the programmer's control of the rasterizer is. Combining two textures requires two cycles per pixel, so it's possible the rasterizer could be toggled on alternate cycles between an arbitrary transform (to draw the glowy thing) and 1:1 marching (to combine it with the framebuffer texture). If the rasterizer can be used in such a way, you'd be looking at a theoretical fill rate of either 2.25 or 2.5 cycles per pixel depending on framebuffer bit depth, which is not much worse than two-cycle mode if you discount latency overhead. If the rasterizer is not capable of such a thing, it'd be more like 3.5-5 depending on framebuffer bit depth and on the drawing mode used to produce a pre-transformed glowy-thing texture.

It may also be possible to use this scheme without a texture for the glowy thing, by using vertex shading or suchlike. The color combiner is pretty flexible.

...

I have a feeling that the above would break antialiasing if you just added the two textures and dumped them into the framebuffer at full opacity. (My understanding of the N64's antialiasing is not great, but I'm pretty sure the coverage bits would get clobbered.) However, if the framebuffer data could be used to preclamp the glowy thing, instead of trying to generate the final image in the color combiner, you could do the addition with the blender without fear of overflow, and the antialiasing scheme might give you better results. (Or not - the description I'm using of the blender's ADD mode doesn't include a lot of detail.) I think what you could do is use the first color combiner cycle to add the two pixels, and then use the second cycle to subtract the framebuffer pixel from the combined (added/clamped) pixel. This wouldn't even change the fill rate, unless you were trying to use vertex colour addition in one-cycle mode - it would just remove the ability to use that second cycle to combine the pixel with any other colour, unless you can add a third cycle to the drawing pipeline...?

Unfortunately fog doesn't seem like it would be compatible with the blender's add mode, and I can't see it working all that well with the basic CC add scheme either. I'm sure there's something that can be done, even if it's just setting the glowy thing's palette based on distance from the camera...

93143 wrote:To be fair, the GameCube architecture was a really good one for the time and punched above its weight, while still being easy to program for.

The exact opposite of the Nintendo 64, which was not programmer-friendly

That arguably had more to do with the RAM inside of the N64 than the architecture of any particular chip like RCP, though.

93143 wrote:regularly hosted games that looked worse than similar titles on a system

I don't think this is quite true if you take a truly holistic approach (virtually all games on the PS1 suffer from at least one of its famous 3D defects - and the console was host to plenty of shovelware), though poor N64 emulation over the last 20 years has done no favors to the system's reputation for good graphics (missing lighting effects makes emulated N64 games look really bland).

IMO, the most popular PS1 games tended to be those with the best visuals on the console, while it was not quite the case with the N64, which I also think explains why opinions similar to yours tend to crop up every so often. It's also worth considering the PS1 had a selection of pretty looking 2D games and pre-rendered background games which were aesthetically pleasing, though that had nothing to do with raw system power or ease of programming...but rather the cartridge format and many developers steering clear of the N64's huge royalty fees.

93143 wrote:with a third of the power and half the RAM (the PlayStation)

Well the Playstation didn't have half the RAM of the N64. It had 2 MB main RAM, 1 MB VRAM, and 512 KB of sound RAM. That's 3.5 MB total (plus 128 KB CD cache). While N64 had 4 MB unified RAM (though it was a bit bigger than it seems due to having a 9th parity bit for anti-aliasing).

But that's not the real crux of the matter. The two consoles had extremely similar "peak" memory bandwidth. IIRC, the Playstation had 133 MB/s main RAM + 266 MB/s VRAM + 33 MB/s sound RAM for a total of 432 MB/s bandwidth, while the N64 had 500 MB/s bandwidth (+ 62.5 MB/s reserved exclusively for anti-aliasing coverage values along the parity channel).

When you factor in N64-in-its-console-generation-exclusive things like
-bandwidth hungry z-buffer (can be mitigated by using a microcode without a (or reduced) z-buffer - but not always practical to do so because a z-buffer could be a very good thing)
-many additional read-modify-writes for anti-aliasing and post-processing (can obviously be turned off, but then you aren't maximizing use of RCP's pipeline nor using the parity bandwidth!)
-alpha channel in some textures
-texture-cache needing manual refreshing for large textures
-unusually high random-access RAM latency (can be mitigated by very careful programming to avoid random access)
-every component in the console sharing a single RAM channel (bus contention hell unless CPU, RSP, and RDP cache use is absolutely maximized)

Then for all intents and purposes, you are left with less or much less practical memory bandwidth than the PS1. Because of this bad textures were probably caused more by developers decreasing the resolution to lower bandwidth usage more than the size the texture cache's size being the issue (4 KB was not small for a 1996 home GPU texture cache with four interleaves, it was big, though if it were even bigger it would have partially alieved texturing problems). Or decreasing framebuffer resolution making everything blurry (and that's before post-processing...). Or less music fidelity.

I don't know why people spend so much time taking about RCP and microcodes when trying to work out why developing for N64 was difficult, when the answer is so simple: it's the RAM. To make the N64 much easier to program all Nintendo had to do was give the CPU and RCP their own RAM channels, with more total bandwidth. Exclusively talking about RCP being so very fill-limited is IMO even more silly when you consider the memory controller in the N64 is designed to give RCP access priority (this is where the myth about the N64 CPU not having DMA comes from - like having an off-chip memory controller means the CPU has no DMA????) - if anything, poorly optimized N64 games are probably stalling on a RAM starved CPU rather than RCP - so much for 3x the clock speed!

It's pretty ironic that the Saturn was hard to program because the overlap of components was too complex, while the N64 was hard to program because the memory architecture was overly simplistic and (practically) inadequate to the extreme. At the same time, I don't think the Saturn could have ever been better than the PS1 at 3D even with perfect programming (2D is another story) because its hardware is just not that suited to full 3D simulations, while the N64 actually could meet its potential of around 3x or more the power of PS1 3D with a good enough program (arguably Conker's Bad Fur Day and a handful of other top-tier games demonstrate it). People tend to forget that the N64 uses a lot of its processing power to clean up 3D image quality behind the scenes - it's not a straight-up polygon count contest.

93143 wrote:I still can't get over the fact that the RCP's blender didn't clamp its output despite being capable of additive transparency

I'd say that's because additive blending support was thrown in at the last moment. The designers of RCP probably thought for a long time that having true % alpha-channel blending support was an advanced enough feature to satisfy everyone. Arguably if you had to pick between the two, they made the right choice since an alpha channel allows for much cleaner transparency all-round (though diminished in practice since many N64 developers were too pressed for bandwidth to make good use of it), but it's undeniable that additive blending looks great for explosions and fire effects.

RCP was a good little chip, much like Flipper was. Nothing at home had better "theoretical' (i.e. unbound from RAM) trilinear filtering performance until Voodoo 2, not even the first Voodoo. And RSP's vertex shader like programmability (and the proto-pixel shader color combiner in RDP) was unknowingly ahead of its time. If only Nintendo dedicated enough RAM bandwidth to it so it could fully move its legs.

93143 wrote:About additive transparency: I may have been wrong about the fill rate hit.

I think the only sane way to use hardware additive blending on N64 is just where the RGB values in your scene are very low, so you can avoid the glitchy overflow of blending a pixel beyond white. IIRC Doom 64 used a little additive blending, but that game is dark as all hell so they could probably get away with it.

EDIT: The more enterprising developers on N64 got around the lack of easy additive blending just by using an animated texture that has white-ish highlights. Not as good as the real thing, but IMO looked fairly convincing in Ocarina of Time's "how the world was made" cutscenes.

Sorry for continuing the derail of this thread about N64. I'd also be happy to discuss the Gamecube and its hardware-based children