PS2 has texture compression, even if you've convinced yourself it doen't
It actually doesn't have texture compression, I don't have to "convince" myself of things that are true you know.
Palettized textures isn't a valid form of texture compression (it's simply colorspace reduction), and using the MJPEG decoder requires a lot of fiddling as the graphics chip can't accept MJPEG textures, you need to manually decompress each texture into a free buffer in main RAM before uploading the full-size uncompressed texture to the graphics chip. Naturally, as a result almost no PS2 games actually bother doing this. (I could challenge you to find a single one which does this, but then it'd turn out your google-fu is greater than mine and you manage to dredge up a few examples...
Nevertheless, they weren't many.)
That 16MB pool of memory in GC is too slow for 90% of actual tasks
Yeah? It's still there. It's being used, so it has to be taken into consideration. A-RAM is part of the GCs cohesive whole, you can't just dismiss it out of hand for some handwavey reason.
Bringing up things like TEV and claiming a win for GC while complaining no one used it is the exact counter point to bringing up VU1 on PS2
No it's not, because VU1 went unused in games because it was just too inefficient, difficult and cumbersome to use in real life, while the TEV was a comparatively straight-forward, functional piece of hardware that largely went unused because developers were unwilling to spend the time/resources to employ it (for whatever reason; bad Nintendo documentation/devtools likely reason, and/or poor returns on investment due to bad GC marketshare and games sales etc.)
Compare multplatform games and you'll more often than not see mipmap lines closer to the camera than on PS2/XB
That's unsubstantiated hearsay, and [original research]. Never ever have I heard this claimed about GC before, what's your sources? Anyway, at least you have games on GC using trilinear filtering, which you rarely if ever see on PS2 due to the graphics chip's broken-as-designed MIP map calculation logic. Even any mipmapping at all on PS2 was unusual since you had to manually "massage" polygon data to make it work properly. Most PS2 games were ant city as far as textures were concerned...
The console has limitations that weren't there on it's competition.
AS DO THEY ALL. So what?! Get off your anti-GC bandwagon already. The console was obviously quite well matched against PS2 overall,
in the real world, when not looking only at paper specs. It was just poorly utilized by developers for the most part, often including nintendo itself.
To put this another way from an earlier generation, look at PS1 and N64. N64 trounces PS1 in power and feature set
Feature set sometimes; while it had many more 3D feature checkboxes (which you often couldn't afford to tick in games due to weak GPU and memory subsystems), it was clearly inferior in storage space obviously but also sound, due to lack of dedicated audio hardware. Furthermore, it also lacked PS's serial port or an equivalent of PS's MDEC hardware.
Power, not so much really. N64 had poor main RAM bandwidth despite monstrous paper figures and even worse memory latency, bad fillrate (made much worse if you enabled Z-buffering) and a really weak CPU. Both of the latter ones largely due to the terrible Rambus main memory SGI chose to use. N64 also had a very slow cartridge interface, and carts were ludicrously expensive and cramped for space.
The arguments have gone back and forth wether N64 or PS was the stronger hardware, in a real-world scenario N64 probably would have been faster if Nintendo had allowed PS-level image quality in games, but they did not. You had to use perspective correct texturing, sub-pixel precision rendering and so on, which bogged down the system a lot. Nintendo's SGI-supplied 3D libraries were poorly optimized and even worse documented, meaning performance suffered and some hardware features were underused. N64 also had a color combiner for example which hardly anyone ever used. Only a few developers at the end of the console's life were allowed to write their own RCP vector code, and documentation was terrible and the hardware itself finicky and wonky in the extreme.
One of the few 60fps games on N64, F-Zero, looks extremely primitive even by the standards of the time. So games generally ran faster and more fluidly (certainly with less fogging!) on PS. They also offered much more varied graphics due to CD storage format instead of tiny-ass cartridges.
I'm curious, Grall, if you aren't judging power by achievement as you claim, and don't believe in paper specs, how are you measuring the power of a system.
"Power" isn't a precisely quantifiable metric when comparing different closed hardware architectures like games consoles. Even when running CPU benchmarks across different architectures you run into issues where one platform's compiler may be using suspect handwritten optimizations for that specific benchmark that skews the results.
...Not so much these days perhaps, as x86 is the lone survivor of the CPU wars (except in the big iron/supercomputer space, where a few competitors still barely cling to life), but we still see it more or less regularly in GPU benchmarks (see the "quack.exe" debacle and many others over the years), and more recently,
on cell phone platforms.
"Power" is largely a judgement call than anything that can be concretely measured IMO, even when it comes to quite similar systems like PS4 and Xbone (where PS4 is pretty much universally seen as the stronger box) will you find instances where one game runs better on the bone I believe. It's almost inevitable.