Are you sure? You have shipped games with software rasterizers and they did this exact algo (no matrices in transform, computing gradient for each scanline)?
If you did division for each scanline, you were running at 1/4th of the speed at most - division was that expensive on 386-Pentium, not to mention other platforms, where CPU's could not even have hardware div.
> Generally speaking, game programmers will do whatever it takes, and painstakingly optimizing algos down to minimum processor operations has always been pretty common in the field.
I am not even talking about crazy optimizations (like using intel's x86 half register to do ghetto fixed point), I am talking about common sense stuff.
I, frankly, do not understand what you and jblow read into this other than what I said.
"Nobody really wrote software rendering like that beyond CG classes".
I read this as a claim that nobody in general wrote software renderers. When by "like that" you just meant using the specific techniques he used.
That said, I still have to disagree, in the sense that, to get to a fast software renderer, you start with a slow software renderer. Nobody does all the crazy optimizations a priori ... so stuff like a divide per pixel was common, say. Calling trig functions in inner loops is of course goofy, but my presumption is that in the next step of refinement those would be lifted out of the loops, because that is the way things are always done.
Yeah, .. but no. Depends on what era you're talking about I guess.
When I wrote my first low-level rasterizer + basic 3D poly engine-ish-thing in 1998, I honestly wouldn't have considered for a second to do a division per scanline. An integer add was one tick, a mul was 3-10 (iirc), but a division was 10-40 ticks. Depending on what point you start considering the optimizatons "crazy", yes, had I known (and cared) about perspective correct shading back then, I would have started designing the algorithm, a priori (which for me usually meant on grid-paper) hunting for some way of faking a sufficiently accurate reciprocal using adds, shifts and at most 2 muls (per scanline, cause per pixel even a single mul was madness, obviously). With what I knew back then, probably go for a 2nd degree polynomial that might be sufficient to at least give the impression it was doing better than naive bilinear? :) Had I been aware of Carmack's (objectively crazy) inverse sqrt hack, I would probably have started looking in that direction (abusing the IEEE float spec on the bit level woohooooo).
Sure you could write a perspective correct triangle rasteriser with a div per scanline, and it would be too slow, it would be a nice theoretical proof of concept, but it would also be kinda useless if it turned out you couldn't make the above crazy hacks run fast enough. They were a real hurdle that had to be crossed or you might as well not bother. Also, why save the fun stuff for last? ;-)
It enforces the stupid idea, that you rasterize 2D triangles for a 3D renderer. People, who think this way are then completely shocked and mystified as to why there is perspective distortion to the surface attributes.
And then, on 2D triangles, it enforces a bizarre notion that a triangle is not flat, so the surface attributes gradients can change from scanline to scanline.
Just curious, what's this and how does it work?
In those days there was so little information easily available - and very little contact with other coders. Once you had figured out something that kinda worked, you got on with making a game.
The European demo scene did a lot to move ideas around, but was not quite the same as game development.
I remember ATI came to demonstrate their GPU at the Breakpoint demoparties (02/03 or so?) .. it was not unimpressive, and I didn't really understand what a "shader" was in the context of a GPU back then (it was also a dumb choice for a name, given what "shading" meant in gfx programming back then, the term "vertex shader" was borderline nonsensical). But they mainly showed stuff we could already do, except doing it in a higher resolution (on what had to have been the most high-end consumer hardware available, ATI brought themselves, it wasn't the official compo machine, for sure). Given I now know what a GPU shader does (parallelism, domain specific instructions but mainly parallelism), I know that "the same thing but on a higher resolution", is absolutely the most obvious thing you can do with a GPU over just a CPU. In demoscene terms, boooooring :-P
This was a few years later, THIS is what a demoscener does to a GPU: https://directtovideo.wordpress.com/2009/10/06/a-thoroughly-...
Either way, at some point (late 200X's?) professional game industry blew past the demoscene in production level. It did happen. I always thought it was the Hollywood movie level budgets (because those exploded too, in that era, didn't they?), but there might have been other factors.
> it was also a dumb choice for a name
Blame Steve Jobs and his Renderman :) At the time consumer GPUs with shaders came out it's been long established term for any code processing graphics data during rendering.
>Either way, at some point (late 200X's?) professional game industry blew past the demoscene in production level. It did happen. I always thought it was the Hollywood movie level budgets (because those exploded too, in that era, didn't they?), but there might have been other factors.
I remember in mid 90s some demo-groups claimed to work on actual games ("Into the shadows" guys said it's a prototype for the game they had been writing) and even on hardware (Pyramid3D lol) but I don't think anything noticeable came out. Remedy Entertainment is, probably, the most successful exit from the demoscene and it never set the bar for the AAA industry. The difference between demos and games is the difference between dancing and fighting. You move your body in both cases but with dancing you are fine as long as you pull some cool moves, while in fighting you actually need to survive and harm your opponent as much as possible. Same as in games you need to draw what the artists want and in demos you can draw anything as long as it's cool. There was never a sensible competition between the two. I imagine game programmers suck at making demos just as much as democoders suck at making games :)
If you were smart enough to use lookup tables, you were already too smart to transform each vertex in multiple steps instead of folding all transforms into a single matrix.