
Computer Graphics from Scratch (2017) - pcr910303
http://www.gabrielgambetta.com/computer-graphics-from-scratch/
======
pseudosudoer
Like many other programmers, I originally picked up programming because I
wanted to write games. I spent time on my own in high school messing around
with rudimentary 2D libraries in C++. That feeling of awe and accomplishment
that was captured the first time an image successfully moves across the screen
was what got me hooked.

After starting college I soon learned of the trials and tribulations of
software engineers in the gaming industry. I changed my degree to Computer
Engineering, took the embedded track, and recaptured that sense of awe by
staring into the abyss of an Oscilloscope. Albeit, I did still take several
graphics courses as electives (simply because I loved the subject).

~~~
codesushi42
Seems like many people start and end this way. Games are a great motivation to
learn how to code. But once you do, you find that other subfields of CS are
more interesting and useful. And you just get older. :)

But that is not reason to quit game development entirely. It is still a good
hobby that makes you a much better programmer, because it touches so many
areas of CS and math. 3d graphics, state machines, trees/graphs, pathfinding,
multithreading, memory management, vector math, networking etc.

~~~
rujuladanh
> But once you do, you find that other subfields of CS are more interesting
> and useful. And you just get older. :)

It is true that some people, as they get older, claim to find games less
interesting. In my opinion, some of them simply jaded a bit, and would be a
good thing for them if they tried to find enjoyment again in the small things.
I know, because I was there too. It depends a lot on the culture.

There are also others that start claiming games are useless, immature and that
the world will end if youngsters keep playing them.

Entertainment has been useful even before civilization existed, and those that
enjoy the time to entertain themselves, do; even if it is in the form of
working on dream projects. Yes, that is playing too.

As for your other point, there are objectively very few (if any) topics as
interesting as games for CS people, given the so many areas of CS (and non-CS)
they encompass at the same time. Hardly any other area of work touches so many
domains. Only operating systems, browsers and CAD apps (and maybe Emacs ;) are
close as vast.

~~~
kmbriedis
Interesting is very subjective term. E.g. some find theory much more
interesting than games

~~~
rujuladanh
What do you mean by theory?

------
ggambetta
Author here. What a surprise to open HN and see this on the front page :)
Happy to answer any questions.

~~~
andrewshadura
Thank you very much for this. I'm glad there still are people writing books
like this one. When I was a teenager, I found a book by L. Ammeraal which was
awesome reading. It taught how to build a simple 3D graphics renderer with
hidden edges removal and other interesting features. Unfortunately, back then
I was a Pascal fan, so it took me some significant effort to translate bits of
the code from the book from C

Later, I found another book, can't remember the author, which described even
more things, like z-buffering and so on. Very interesting and very useful.

~~~
Bekwnn
[http://www.opengl-tutorial.org/](http://www.opengl-tutorial.org/) is a pretty
fantastic resource of learning this stuff.

Don't worry too much about opengl vs direct x vs vulkan. There are underlying
principles that apply broadly to both.

Alternatively if you want a book that goes more in depth, but still allows you
to take your first steps, opengl programming guide 8th+ edition is good.

Expect it to require some patience no matter what route you take. Graphics
programming is finnicky.

------
akdas
This is awesome! One thing I really appreciate is building up the mathematical
concepts. For example, instead of providing a ray-sphere intersection formula,
the tutorial talks about representing a ray and a sphere, and how the two
representations must match at intersection points.

When I was asked to teach a workshop on computer graphics, I wanted to make
the concepts accessible to those who were either rusty, or hadn't even
encountered the necessary math. Given a limited amount of teaching time, I
introduced only the most relevant math, but did so from first principles.
Hopefully my treatment can be useful to others: [https://avik-
das.github.io/build-your-own-raytracer](https://avik-das.github.io/build-your-
own-raytracer)

------
dancodes
I found it surprisingly hard to get access to the primitives mentioned in the
intro, on a modern pc. How does one draw a pixel on a specific coordinate in a
modern OS?

~~~
gameswithgo
the best/easiest way is still use opengl/directx/etc but draw your texture in
software, and then draw the texture full screen.

This is the approach I used to teach software rendering in gameswithgo.org we
make a putpixel function as in the old days, and use it to build up a texture,
which we draw each frame. The texture becomes what used to be the framebuffer.

~~~
Asooka
Copying the entire framebuffer over the PCI bus makes me sad, though it's
obviously way faster than when you could memory-map the framebuffer. These
days you can't map texture objects in memory because texture storage on GPUs
is its own black magic and textures are not stored as simple linear
framebuffers. It would be fun to restrict yourself to a well-documented
architecture, e.g. give everyone a cheap intel-based notebook and write out
commands directly for the graphics chip. I guess while fun that would teach
more about doing low-level hardware access than graphics themselves.

And while on the topic of changing hardware forcing us to change our
algorithms, I wonder if teaching scanline rendering is even worth it these
days. Every CPU supports SIMD and a SIMD-optimised software rasteriser is a
very different beast than the classic scanline triangle rasterisers of old.

Probably the fastest software rasteriser for modern CPUs is OpenSWR [0],
written by Intel mostly to keep themselves relevant in the data visualisation
space until GPUs eat HPCs (GPUs still can't help you when your dataset is
measured in hundreds of gigabytes of graphics data), but it scales perfectly
fine down to desktop CPUs. The code for it is in the Mesa tree [1]. I wish I
could explain exactly how it works, but it's a pretty big beast and I haven't
had the time to read and understand all of it. Intel gave a presentation on it
at the HPC developers conference back in 2015 [2]

[0] [http://openswr.org/index.html](http://openswr.org/index.html)

[1]
[https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/driv...](https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/swr/rasterizer/core)

[2] [https://youtu.be/gpYd18E3TWc?t=1531](https://youtu.be/gpYd18E3TWc?t=1531)

------
ssdsa
Yes, it is very rewarding to program your own graphics routines or your own
simple implementation of a raytracer and then see the correctly rendered scene
on screen for the first time.

I did this on my Amiga a lot time ago (1995), and then re-created the feeling
using ShaderToy:
[https://www.shadertoy.com/view/lds3z8](https://www.shadertoy.com/view/lds3z8)

It's so cool: A scene that took 10 minutes to render in 1995 - nowadays you
can see that scene through a moving camera raytraced in real time in your
browser!

------
frenchie14
Anyone know how this guide compares to tinyrenderer?

[https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting...](https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting-
started)

------
fuball63
Graphics was one of the hardest courses when I was in school for game
development. We started with raytracing, did rasterization from scratch, then
worked with DirectX and OpenGL. I formed lifelong friendships struggling
through toon shading, bump mapping, and particles with HLSL shaders.

------
hatsunearu
This ought to be super helpful for my toy rasterizer project written in Rust.

If anyone is interested, I'll post the link (it's crappy)

I suggest everyone to try implementing a rasterizer in a new language; it goes
over a lot of language fundamentals and a lot of reasonably efficient memory
manipulation (if you try to, at least) is required, which forces you to be
intimate with the lang. Great Rust practice for me, at least.

------
person_of_color
Any dummies guide to shaders?

~~~
formalsystem
[https://thebookofshaders.com/](https://thebookofshaders.com/)

------
philshem
The capitalization of Scratch in the title made me first guess that they were
using the educational programming language Scratch.

~~~
ggambetta
This is the capitalisation the OP used; the one I use myself is lowercase.
Perhaps a mod (paging dang?) could fix this?

------
code_duck
This is primitive, but not quite from scratch - that makes me think of
TempleOS. This is more like, computer graphics without libraries.

~~~
ggambetta
Fair enough. It's definitely "from scratch" compared with most graphics
courses which start at the OpenGL level, but as with whether a language is
"low level", it's somewhat subjective.

