nesdev.org

It's no wonder the general populous have problems comprehending classic consoles. Sheesh.

Like how 32x32 sprites take "more CPU power" than 16x16 sprites.

My favourite is how Recca apparently pushes the NES to the maximum, to draw much more sprites than you'd think it should be able to.

I'm fairly sure Recca never draws more than 64 sprites, and at least half the game is running at 30fps.

"32x32 is slower" could be a conflation of several issues.

If the game decompresses CHR data from ROM in real time rather than doing all decompression in advance on a blank screen, more pixels means more CPU time. And compression is more necessary with larger cels than with smaller ones.

Super NES has the additional complication of a 2D VRAM mapping. Thus a VRAM allocation system that supports allocation across four rows of OBJ CHR tiles (for 32x32) may use more CPU time than one that supports only two (for 16x16) because you can't as easily get away with allocating an entire row to one actor; you have to allocate a square and blit it using four DMA calls instead of one or two. Genesis VRAM is 1D, and GBA VRAM is 1D or 2D depending on bits in the display mode register.

And on platforms without hardware support for larger sprites, such as NES, Master System/Game Gear, and Game Boy/GBC, larger sprites literally take longer to draw because they fill more OAM entries.

Ignoring dynamic animation, they take the same amount.