How about Saturn and PS1 time? In that time CPU done only T&L and low-poly scene?
Original PS did not do geometry on its CPU; it was (as I recall) the first consumer device to feature a dedicated hardware geometry processor for that. Or at least the first mass market device to do it that way. It didn't support what has become known as geometry shading though, so it couldn't do skinning for example in hardware.
This lead to stuff like arms, legs and such being discrete objects from the torso of a character.
To be honest, I don't think I understood what you say here.
OK! Well, how to try and explain it more clearly...
We begin with sprites then! In early computers, shifting around pixels was processor intensive. CPUs were very slow, memory was also slow. Early 8 or 16/32-bit CPUs like the MOS 6502 or MC68000 could only work on one instruction at a time, and an instruction generally took multiple clock cycles to complete, say, 3-8 clocks or so. More complex instructions like multiplies and divisions on the 68k took 60-100+ clocks IIRC, and that was integer math. These chips did not support floating point math at all (in hardware; you could emulate it at ginormous performance hit in software.)
So to draw several objects, every frame, you would quickly end up burning a large percentage of your processor time just to update the screen. Nevermind anything else you might want to do in a game! So thus sprites were born. The graphics chip has a bunch of registers that A: accepts an address to a memory location for the sprite data itself, B: a palette register holding colors or address to a set of colors in RAM, C: screen coords for where you want to display the sprite. There could be some other fluff as well, like priority register for making sprite appear in front or behind the background, collision register telling you when the sprite hits something (like another sprite or the background), and often horizontal/vertical flipping of the sprite, because such operations are also expensive for old-time processors.
So now you have an independent object you can move around just by poking a few values into some registers, giving you a perhaps 100-fold saving on work. The video chip takes care of all the work of actually drawing the sprite, it even does the work of telling you if you crash into something. Great!
However, memory is slow, so you can't fetch enough data to show very many sprites per video line (giving rise to the dreaded sprite flicker). There's no overdraw elimination in these old sprite engines; there must be enough bandwidth for the background AND each sprite, even if they all end up covering one another in the end. You were often also limited in sprite size, amount of colors and so on. Also, if you need advanced features such as scaling and rotation, transparency and so on, only your video chip does not support them, then having sprites doesn't much help you (this was frequently an issue when doing arcade ports back to home consoles.)
So you have a set of factors that are hard limits for your game software. If you don't have enough sprites with the features you need, or perhaps if you have no particular need for sprites at all - like you're doing 3D graphics for example - then you've wasted a fair bit of transistors on hardware sprites.
So Saturn - and original Playstation - did away with that. Playstation did not have separate video processors for 2D/3D graphics and background compositioning, but the basic principle is the same. You use the 3D rendering hardware to draw flat, square or rectangular polygon objects aligned perpendicular to the viewport (IE, monitor screen); this makes the object look like a traditional sprite, only you get "free" rotation, scaling and also transparency if your hardware supports that kind of thing (Saturn had some quirks and peculiarities on that front). "Alpha channel" texturing mode is used, so that the background color of the texture is replaced with whatever color is behind the object. Also, making these objects flat and aligned to the viewport lets you skimp on the calculations to generate them IIRC, thus making them faster and more efficient to draw.
As neither Saturn or PS supported Z-buffer, you would sort your polygon objects on the CPU using a fast algorithm before rendering so that they would appear in the right order on screen, then draw them back to front, covering up objects as you go. (This was true for 3D graphics as well, so when the sorting algorithm failed you would get polygons "fighting" with each other over which one to stay on top. Very occasionally visible even in modern hardware/games btw.)
Now, polygons aren't separate objects floating on top/under the background like sprites are. They're drawn permanently into the framebuffer (well, until you clear the buffer of course). This is not that a big issue, because at this point in time drawing speed and memory bandwidth are vastly higher than they were in older hardware. You could probably draw a couple thousand "sprite"-sized objects per frame at 60 frames/sec without breaking much of a sweat on either PS or Saturn consoles.
