4 ms·

I don't understand how 3d games are written or know what shaders are, so this is complete magic to me, and I'm surprised it's only 5k lines of C code!

by sbjs 8y ago

diamondo25 8y ago
Drawing cubes is basically one of the first things you do when starting with 3d rendering. Shaders are scripts that the GPU uses for translating your input (a cube in 3d data and your 'camera' and some more vectors) to viewport/screen coordinates. You can do a lot with it [0]. The classic OpenGL 1 framework had no shaders and a static pipeline. Its straightforward in doing things but reduces the amount of fancy things you can do. Maybe check out a guide like here[1]. [0] http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/ http://www.adriancourreges.com/blog/2016/09/09/doom-2016-gra... [1] http://www.glprogramming.com/red/ http://www.glprogramming.com/red/
bena 8y ago
Shaders are basically transformations performed by the graphics card. Or sometimes not. It gets real vague at times because like a lot of things there are no hard lines. You take a point and figure out if it needs to be colored differently based on certain criteria. Like if it was in shadow, or if it's being hit by a bright light, or you just want a sepia tone across everything. You can even shift everything. Take the screen and distort it according to some kind of function. Like make it all wavy. 3d games are no more or less conceptually different than 2d games in a lot of regards. There are more things to track and be aware of, but you're effectively doing a lot of the same things. If you've ever messed around with making 2d games, you can even begin simple experimentation by just making another layer of depth. Like LittleBigPlanet, it's ostensibly a 2D game presented with 3D graphics. But it allows you to shift between 3 layers to give you some depth.
- gameswithgo 8y ago
  > Or sometimes not. No, shaders are always done by the 3d card =)
  - sbjs 8y ago
    Does this mean you effectively get it "free" in terms of CPU cycles, and can use the CPU for all 16ms (60fps) of each frame to do game logic, without worrying about render time?
    - meheleventyone 8y ago
      Yes but you still have CPU overhead in terms of organising and submitting work to the GPU. Although some of that work is itself making its way to the GPU now compute shaders are widely supported. There will always be a need to synchronise though. The other big change in this regard is with newer graphics APIs allowing the work on the CPU to be properly multithreaded.
    - bena 8y ago
      It's best to think of it as a real limited thread you can shunt off some of the work to. Effectively, a shader is no different than any other bit of code you have. Anything you can do in a shader you can do on the main program thread (and vice versa). Now, things you typically want to do with a shader are better done by the GPU for various reasons. Better floating point math processor, pipelines more suited for the task, etc. And you can make the shaders generic enough to reuse for multiple applications. Basically the shader says "Hey, here's where the light source is, here's the luminosity, here's the color, here's what it is shining on, here's how the color changes." And being essentially dedicated number crunchers, people realized that not everything sent to a graphics card needed to actually render. You could make a shader to do something crazy, like solve complex equations more quickly than a generic CPU could. So if this was 8 years ago, you might decide to write a shader that could effectively mine bitcoins. Which is what people did and why good graphics cards have become crazy expensive.
  - bena 8y ago
    I wanted to be careful because shaders don't really just shade anymore and I was pretty sure if I limited to just graphics cards, there will be someone that pops up that says the first shaders were actually blah blah blah. Basically, I knew I was going to be slightly wrong about something somewhere.

I don't understand how 3d games are written or know what shaders are, so this is complete magic to me, and I'm surprised it's only 5k lines of C code!

by sbjs 8y ago

I don't understand how 3d games are written or know what shaders are, so this is complete magic to me, and I'm surprised it's only 5k lines of C code!

diamondo25 8y ago

Drawing cubes is basically one of the first things you do when starting with 3d rendering. Shaders are scripts that the GPU uses for translating your input (a cube in 3d data and your 'camera' and some more vectors) to viewport/screen coordinates. You can do a lot with it [0]. The classic OpenGL 1 framework had no shaders and a static pipeline. Its straightforward in doing things but reduces the amount of fancy things you can do. Maybe check out a guide like here[1]. [0] http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/ http://www.adriancourreges.com/blog/2016/09/09/doom-2016-gra... [1] http://www.glprogramming.com/red/ http://www.glprogramming.com/red/

bena 8y ago

Shaders are basically transformations performed by the graphics card. Or sometimes not. It gets real vague at times because like a lot of things there are no hard lines. You take a point and figure out if it needs to be colored differently based on certain criteria. Like if it was in shadow, or if it's being hit by a bright light, or you just want a sepia tone across everything. You can even shift everything. Take the screen and distort it according to some kind of function. Like make it all wavy. 3d games are no more or less conceptually different than 2d games in a lot of regards. There are more things to track and be aware of, but you're effectively doing a lot of the same things. If you've ever messed around with making 2d games, you can even begin simple experimentation by just making another layer of depth. Like LittleBigPlanet, it's ostensibly a 2D game presented with 3D graphics. But it allows you to shift between 3 layers to give you some depth.

gameswithgo 8y ago
> Or sometimes not. No, shaders are always done by the 3d card =)
- sbjs 8y ago
  Does this mean you effectively get it "free" in terms of CPU cycles, and can use the CPU for all 16ms (60fps) of each frame to do game logic, without worrying about render time?
  - meheleventyone 8y ago
    Yes but you still have CPU overhead in terms of organising and submitting work to the GPU. Although some of that work is itself making its way to the GPU now compute shaders are widely supported. There will always be a need to synchronise though. The other big change in this regard is with newer graphics APIs allowing the work on the CPU to be properly multithreaded.
  - bena 8y ago
    It's best to think of it as a real limited thread you can shunt off some of the work to. Effectively, a shader is no different than any other bit of code you have. Anything you can do in a shader you can do on the main program thread (and vice versa). Now, things you typically want to do with a shader are better done by the GPU for various reasons. Better floating point math processor, pipelines more suited for the task, etc. And you can make the shaders generic enough to reuse for multiple applications. Basically the shader says "Hey, here's where the light source is, here's the luminosity, here's the color, here's what it is shining on, here's how the color changes." And being essentially dedicated number crunchers, people realized that not everything sent to a graphics card needed to actually render. You could make a shader to do something crazy, like solve complex equations more quickly than a generic CPU could. So if this was 8 years ago, you might decide to write a shader that could effectively mine bitcoins. Which is what people did and why good graphics cards have become crazy expensive.
- bena 8y ago
  I wanted to be careful because shaders don't really just shade anymore and I was pretty sure if I limited to just graphics cards, there will be someone that pops up that says the first shaders were actually blah blah blah. Basically, I knew I was going to be slightly wrong about something somewhere.