1) Renders the models to the depth, colour, normal and material buffers
2) Renders shadows into the stencil buffer
3) Performs a light pass using the normal buffer into the light accumulation
4) Performs edge detection based on the normal and depth buffer into outline buffer
5) Merges the colour, light, stencil and edge buffers into a final back buffer
Steps 3 through 5 are full-screen effects. All about fill-rate and how fast I can pull in texture data. So the size and speed of the bus on the GPU side is the most important factor, next to texture cache size, and then the number of SIMD's on the GPU.
And most, if not all modern renderers work in a similar fashion.
The main trick to the PS2 was having it all run in parallel while keeping stuff off the main bus. To be honest, I had more problems getting physics code on the XBox to run as fast as the code on the PS2.
You could debug DLL's My first task at my first employer was to write a plugin for 3DS Max, and I was using VC5 at first. Plugins were just DLL's and I spent a LOT of time attaching to Max to debug my plugin. As you say, it was buggy, but it did work. Sort of. Well....depending on the alignment of the planets.Well, VC6's Debugger was actually quite buggy and far from being as easy to use as the stuff we had since VC8 and on. I think people also never think about it.
Profilers for Visual Studio are common now and do wonders, but back in VC6 times I think there wasn't any of them and you probably couldn't even debug DLLs and stuff like that as you can now.
So compared to a full-blown profiler which could work with low-level programming, yep, there was a huge gap.