5 ms·

All these 'for' loops and sequential trigonometric calls... See, I wouldn't say that art was lost. It was obsoleted to dust by a more modern and scalable appro

All these 'for' loops and sequential trigonometric calls... See, I wouldn't say that art was lost. It was obsoleted to dust by a more modern and scalable approach.

pandaman 10y ago
Nobody really wrote software rendering like that beyond CG classes. I'd think author is simplifying for the sake of accessibility but it's actually more complicated than what production renderers did. One could also think it's to show a GPU's internal work, but, again, GPUs don't do this either.
- jblow 10y ago
  Wrong, wrong, wrong, wrong. Wrong. People in the video game industry wrote tons of this stuff. We would spend weeks figuring out how to get one or two instructions out of the rasterizer or scanline converter, etc. I know this because I was there. I wrote several software rasterizers, and I learned how to do it by reading papers and magazine articles written by other people who wrote software rasterizers. I have no doubt that other industries did so as well. Even more recently, companies like RAD Game Tools built as products software rasterizers that are very fast (e.g. Pixomatic). Also, what's in this article is a simplified introductory take. It is actually much much more complicated than this. (It doesn't look to me like he is doing perspective-correct shading, for example.) Also this guy's code is crazy slow compared to what you'd write in the real world, but hey, it is a tutorial.
  - pandaman 10y ago
    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)?
    - psyc 10y ago
      I also wrote software renderers in the 90s. I would say it was mixed. Some people used matrices, and some didn't. You really can't say that everybody used the matrix formalism across the board. For that matter, I worked on an engine at a well-known game company as recently as 2013, where there were definitely hand-optimized paths for several different cases of transforms where the constraints were known. Generally speaking, game programmers will do whatever it takes, and painstakingly optimizing algos down to minimum arithmetic operations has always been pretty common in the field.
      - pandaman 10y ago
        I too wrote software rasterizers in 90s and even shipped a game with one. If you used a single sine for each vertix, least computing full rotation, you were fucked. There was no hardware, which could handle this at real time in 90s. 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.
        psyc 10y ago
        Ah. I think you're talking about something completely different from what jblow and I were talking about. If you mean that the code in the article is not optimized, and is doing crippling amounts of redundant computation, then of course I agree with you.
        pandaman 10y ago
        The guy asked what kind of magic is calling trig functions in inner loops? I replied that nobody really did it and I am confused as to what the author was trying to show. I, frankly, do not understand what you and jblow read into this other than what I said.
    - dragonbonheur 10y ago
      Look up tables for pre-computed sine values. Search for "Denthor's tutorials" from the Asphyxia Demo group.
      - pandaman 10y ago
        Q: "Did you ship a game doing this?" A: "Lookup tables!" 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.
    - samlittlewood 10y ago
      Yup - it happened - I remember several games that just used trig. via lookup tables. (Esp. If they were mostly Z only rotation - cf. battlezone). Also, many games rasterized convex polygons, so gradient per scanline was a thing. 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.
      - pandaman 10y ago
        Demos are not production games, it's kids teaching themselves. I should have written "beyond CG classes and demoscene".
        tripzilch 10y ago
        That's one way of putting it. In the early 2000s, commercial production games were just as much "demos done inefficiently" (for good business reasons, mostly). Maybe I sense an unintended connotation with the term "kids", though. 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-modern-particle-system/ 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.
  - tripzilch 10y ago
    > Also this guy's code is crazy slow compared to what you'd write in the real world, but hey, it is a tutorial. I read pandaman's comment to mean this, actually. Not that nobody wrote their own handcrafted rasterizer/poly engine whatnots. It's that the article is both not showing what GPU's do internally, but it also doesn't quite show what a reasonable "artisanal" poly rasterizer gfx engine would look like for a system with no GPU. On the one hand, sure, it's a tutorial, so it just shows an overview of the steps a proper engine would need to complete, but it's done with an almost pseudocode-level of inefficiency. Sadly (just a little), it'll run fast enough on a modern computer that I am sure that some people will just take this example and use it as the core of an engine to build something crazy cool around :) And frankly, more power to them. Analogously if someone had told me 17 years ago that Javascript would one day associated with the term "web assembly", that it would be used as a low-level target for compilers, and for many purposes the first choice in application (even graphical) development ... I never expected the future to be anything less than weirder than I could possibly imagine, so let's just write code! hahaha :-) (actually edited that from 15 to 17 years ago, because I remember in 2002 there were already some possible inklings of hints of what could be done in JS, XHR was on the glimpse of becoming mainstream accessible, the possibilities were all but not quite crystallised)
khedoros1 10y ago
No one used sequential trig calls; it was still all matrix multiplications, and such. If you're trying to explain the effects without jumping into matrices though, calculating the trig like that is the way to do it. The for loops are always present, but they're handled in the driver or the hardware itself. If you assume that all you've got for drawing graphics is a setPixel function, then they end up exposed directly in your code.

All these 'for' loops and sequential trigonometric calls... See, I wouldn't say that art was lost. It was obsoleted to dust by a more modern and scalable approach.

pandaman 10y ago

Nobody really wrote software rendering like that beyond CG classes. I'd think author is simplifying for the sake of accessibility but it's actually more complicated than what production renderers did. One could also think it's to show a GPU's internal work, but, again, GPUs don't do this either.

jblow 10y ago
Wrong, wrong, wrong, wrong. Wrong. People in the video game industry wrote tons of this stuff. We would spend weeks figuring out how to get one or two instructions out of the rasterizer or scanline converter, etc. I know this because I was there. I wrote several software rasterizers, and I learned how to do it by reading papers and magazine articles written by other people who wrote software rasterizers. I have no doubt that other industries did so as well. Even more recently, companies like RAD Game Tools built as products software rasterizers that are very fast (e.g. Pixomatic). Also, what's in this article is a simplified introductory take. It is actually much much more complicated than this. (It doesn't look to me like he is doing perspective-correct shading, for example.) Also this guy's code is crazy slow compared to what you'd write in the real world, but hey, it is a tutorial.
- pandaman 10y ago
  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)?
  - psyc 10y ago
    I also wrote software renderers in the 90s. I would say it was mixed. Some people used matrices, and some didn't. You really can't say that everybody used the matrix formalism across the board. For that matter, I worked on an engine at a well-known game company as recently as 2013, where there were definitely hand-optimized paths for several different cases of transforms where the constraints were known. Generally speaking, game programmers will do whatever it takes, and painstakingly optimizing algos down to minimum arithmetic operations has always been pretty common in the field.
    - pandaman 10y ago
      I too wrote software rasterizers in 90s and even shipped a game with one. If you used a single sine for each vertix, least computing full rotation, you were fucked. There was no hardware, which could handle this at real time in 90s. 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.
      - psyc 10y ago
        Ah. I think you're talking about something completely different from what jblow and I were talking about. If you mean that the code in the article is not optimized, and is doing crippling amounts of redundant computation, then of course I agree with you.
        pandaman 10y ago
        The guy asked what kind of magic is calling trig functions in inner loops? I replied that nobody really did it and I am confused as to what the author was trying to show. I, frankly, do not understand what you and jblow read into this other than what I said.
  - dragonbonheur 10y ago
    Look up tables for pre-computed sine values. Search for "Denthor's tutorials" from the Asphyxia Demo group.
    - pandaman 10y ago
      Q: "Did you ship a game doing this?" A: "Lookup tables!" 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.
  - samlittlewood 10y ago
    Yup - it happened - I remember several games that just used trig. via lookup tables. (Esp. If they were mostly Z only rotation - cf. battlezone). Also, many games rasterized convex polygons, so gradient per scanline was a thing. 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.
    - pandaman 10y ago
      Demos are not production games, it's kids teaching themselves. I should have written "beyond CG classes and demoscene".
      - tripzilch 10y ago
        That's one way of putting it. In the early 2000s, commercial production games were just as much "demos done inefficiently" (for good business reasons, mostly). Maybe I sense an unintended connotation with the term "kids", though. 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-modern-particle-system/ 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.
- tripzilch 10y ago
  > Also this guy's code is crazy slow compared to what you'd write in the real world, but hey, it is a tutorial. I read pandaman's comment to mean this, actually. Not that nobody wrote their own handcrafted rasterizer/poly engine whatnots. It's that the article is both not showing what GPU's do internally, but it also doesn't quite show what a reasonable "artisanal" poly rasterizer gfx engine would look like for a system with no GPU. On the one hand, sure, it's a tutorial, so it just shows an overview of the steps a proper engine would need to complete, but it's done with an almost pseudocode-level of inefficiency. Sadly (just a little), it'll run fast enough on a modern computer that I am sure that some people will just take this example and use it as the core of an engine to build something crazy cool around :) And frankly, more power to them. Analogously if someone had told me 17 years ago that Javascript would one day associated with the term "web assembly", that it would be used as a low-level target for compilers, and for many purposes the first choice in application (even graphical) development ... I never expected the future to be anything less than weirder than I could possibly imagine, so let's just write code! hahaha :-) (actually edited that from 15 to 17 years ago, because I remember in 2002 there were already some possible inklings of hints of what could be done in JS, XHR was on the glimpse of becoming mainstream accessible, the possibilities were all but not quite crystallised)

khedoros1 10y ago

No one used sequential trig calls; it was still all matrix multiplications, and such. If you're trying to explain the effects without jumping into matrices though, calculating the trig like that is the way to do it. The for loops are always present, but they're handled in the driver or the hardware itself. If you assume that all you've got for drawing graphics is a setPixel function, then they end up exposed directly in your code.