I'm sure you don't remember me, but we used to work together at Improbable – you sent me such a wonderful email when I left to go back to Sweden, thank you!

Anyway, just wanted to say congrats and hope you're doing great buddy. All the best! :o)

That's right, I was in Florida visiting family. Would love to reconnect, don't hesitate to ping me an email at [email protected] if the feeling is mutual! :o)

What matters is I got the opportunity to reconnect with an old pal, I'll gladly pay the spam tax if it comes to that. Worst case scenario I guess I'm getting a new email address eventually. :o)

Good tip though, thanks!

My favorite chapters are those about drawing raster lines and triangles. One of my first programs was writing (in 386 16-bit asm) the routine to draw a triangle, and I love these algorithms dearly.

An important and beautiful thing that is missing in the book is the drawing of anti-aliased lines (easy) and triangles (not trivial!). I find that rendering carefully shaded smooth objects with a pixelized boundary loses a big part of the magic.

I explain a bit of this in the introduction, most of the time I present not the best/fastest algorithm, but the one that it's the simplest to understand. For example, I don't even mention Bresenham's algorithm; instead I present a super simple but inefficient one, which achieves two critical things: (1) you're drawing lines in no time, (2) it motivates the linear interpolation method that is then used for shading, z-buffering and texturing.

And finding your Imdb profile was a nice addition on top ;)

All the best.

is that why you ended up working for improbable? ;)

You're not far off the mark, though! It was my other series of articles about client-side prediction [0] that brought me to Improbable's attention :)

[0] https://gabrielgambetta.com/client-server-game-architecture....

Almost every modern source however uses engines or big frameworks and skips the parts I actually want to look into. Compiling a reading list or figuring things out myself of course would have been an option, but I guess others can relate to the problem of having too little time for hobby projects :)

Big bonus points also for trying to remain programming language agnostic! I immediately preordered your book and find it hard to express my excitement, can't wait.

It's a classic in the computer graphics field, like Knuth is for algorithms. I'd recommend it alongside the OP's new book.

EDIT: But for anyone who is reading this wanting to learn about practical computer graphics, CG:P&P is NOT the resource to use! Learning the low-level rasterization algorithms used in computer graphics is an important thing to learn at some point, just like learning assembly language provides valuable insights even if you never touch a line of assembler again. But if you actually want to write graphics code on modern hardware with GPUs, I'd highly recommend Real Time Rendering instead: https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Aken...

What would you say are the prerequisites for this one?

Also from the description it sounds as if it also goes a bit more into 2D graphics too, is that correct?

You might think this has nothing to do with 3D graphics, but in fact there is a big overlap. The graphics driver + GPU takes a description of a 3D scene and projects it into 2D primitives whichs are rasterized onto a bitmap (the display) just as one might render a font glyph.

So IIRC the book begins with the basic theory and techniques of 2D graphics, and then shows how projective geometry can be used to render 3D scenes onto 2D displays, and progressively adds various corrections which we take for granted, such as perspective-correct interpolation of texture values, which these days is done automatically by the hardware.

I don't think there's any pre-requisites other than a basic understanding of beginner computer science, coding, and algorithms. If you can read Knuth, you can read CG:P&P.

Also, see my edit to the grandparent comment.

[0] https://www.amazon.com/Computer-Graphics-Scratch-Gabriel-Gam...

[1] https://www.barnesandnoble.com/w/computer-graphics-from-scra...

[2] https://bookshop.org/books/computer-graphics-from-scratch/97...

[3] https://www.penguinrandomhouse.com/books/645952/computer-gra...

Things got very hard with ray tracing and later u,v texture mapping, etc. Making a note here so I can try your book out sometime!

The idea of a pixel is that it's the smallest area of the screen that can be independently controlled, thus the designation "pixel" for "picture element".

In most modern phone screens or monitors, each pixel is formed by a group of three smaller elements with fixed colors (usually red, green, and blue) but _variable brightness_. By controlling the brightness of these sub-elements, we can control what the overall color of the pixel appears to be - once you get more than an inch or two away from the screen, the light from the element group blends into what we see as a single color - so 100% green + 100% red + 0% blue looks like bright yellow. 50% each for red, green, and blue looks like a middling grey. You can usually see the structure of the pixel with a magnifying glass, though this is easier with an old TV or monitor than a modern phone.

These pixels are laid out on a regular rectangular grid, and your display controller will offer some way to set the color of each pixel and to then update them all at some (usually) regular interval, for example 60 times per second. In computers, it's common to keep a "frame buffer" around that stores separate values for the red, green, and blue components of every pixel on the screen. If these are 8-bit values, that implies that each R/G/B component can have 256 different levels of brightness, and in combination they allow each pixel to take on one of about 16,000,000 possible colors. So, a program can change pixel colors by writing different values into this buffer and waiting for the updated buffer to be processed by the display controller to change what the display is showing.

Of course, the electronics, physics, chemistry, timing, and logic of display generation have changed quite a bit since Pong. And not all displays even have pixels - vector displays used to be a thing, and are still used in some very specialized applications.

Details like how and why pixels work are much easier to understand and retain if they're in some kind of context. Gamers learn about pixels to better understand the games or their gear. Devs learn about them in order to control them. Artists learn about them to better understand why computers mangle their art. So maybe choose an area the grandkids are engaged with and look for something there that also touches on display tech.

If you can zoom in enough to see subpixel elements, and pull up a color wheel, it's very intuitive to see that the screen is made of pixels, and the pixels are made of three elements.

https://en.wikipedia.org/wiki/RGB_color_model#/media/File:Ad...

The Pico-8 might be a approachable way to explore retrocomputing. It's an in-browser console modelled after GameBoy-era consoles.

https://news.ycombinator.com/item?id=18240375

I don't know about books, though. I remember reading the binary/computers chapter of How Things Work and being thoroughly confused at that age. There was some extended allegory about white mammoths and black mammoths.

Now I have both editions and have looked through them side-by-side. It's a bit unfortunate that some pages were dropped to make room for the expanded digital section in the newer edition, but well worth the trade-off for more/better explanations in the digital realm.

Just took a look over my bookshelf, but they haven't made it with me through moves.

I do still have Incredible Cross-Sections. That was another of my favorites to flip through. It looks like there are reprints and new versions. Would definitely recommend for kids.

https://www.amazon.com/Stephen-Biestys-Incredible-Cross-Sect...

It's not like modern display panels and HDMI signals and digital protocols are simple, but you don't have to go into the details to understand how pixels and framebuffers work.

If you're trying to explain how pixels work, going back to 1980s era technology is a detour into arcane technical details that aren't really relevant any more. They're pretty cool to read about if you're into retro computer technology but they don't have much educational value or relevance to the modern day.

https://www.youtube.com/watch?v=niKblgZupOc - PC CGA

https://www.youtube.com/watch?v=_rsycfDliZU - Apple and Atari

https://www.youtube.com/watch?v=mpNWEbZdXNw - GBA

There's also a linear algebra appendix [0] that presents the operations, explains how to use them, and how they can be interpreted, without going in any theoretical depth about why these things are the way they are.

[0] https://gabrielgambetta.com/computer-graphics-from-scratch/A...

On modern machines, a pixel is just a set of three numbers indicating how much red, blue and green light should be shown at a particular point. Ex: {0.75 red, 0.0 blue, 0.5 green} for a kinda-dark, orange pixel. The GPU keeps a big 2D grid of these number-triples in memory and on a regular schedule sends out a copy over the DVI cable to your monitor. The monitor has a bit of memory to hold it's copy. And, it has hardware to scan over the grid of numbers to produce a sequence of voltage levels that are used to change the color of the points on the LCD.

There's a bit of math involved in how to do a good job representing colors with numbers and how to convert those numbers to voltages. But, at the most basic level, an image is just a big 2D grid of numbers. If you want to change the image, poke the grid. People want to change images a whole lot. So, we've developed pretty sophisticated hardware and software around poking 2D grid... But, that's a whole other topic.

I think this is the final kick I needed, so thanks!

This is one of the few tutorials that covers raster rendering. Lots of introductory material on ray-tracing, not a lot on raster graphics.

Where can students look for more stuff on rasterization after they finish this book?