[HN Gopher] Implementing a tiny CPU rasterizer (2024)
___________________________________________________________________
Implementing a tiny CPU rasterizer (2024)
Author : PaulHoule
Score : 96 points
Date : 2026-01-25 22:45 UTC (5 days ago)
(HTM) web link (lisyarus.github.io)
(TXT) w3m dump (lisyarus.github.io)
| delta_p_delta_x wrote:
| This is a great resource. Some others along the same lines:
|
| TinyRenderer: https://haqr.eu/tinyrenderer/
|
| ScratchAPixel: https://www.scratchapixel.com/index.html
|
| 3D Computer Graphics Programming by Pikuma (paid):
| https://pikuma.com/courses/learn-3d-computer-graphics-progra...
|
| Ray-tracing:
|
| Ray Tracing in One Weekend: https://raytracing.github.io/
|
| Ray Tracing Gems:
| https://www.realtimerendering.com/raytracinggems/
|
| Physically Based Rendering, 4th Edition: https://pbr-book.org/
|
| Both:
|
| Computer Graphics from Scratch:
| https://gabrielgambetta.com/computer-graphics-from-scratch/
|
| I'll also link a comment[1] I made a while back about learning 3D
| graphics. There's no better teacher than manually implementing
| the rasterisation and ray-tracing pipelines.
|
| [1]: https://news.ycombinator.com/item?id=46410210#46416135
| ggambetta wrote:
| May I add Computer Graphics From Scratch, which covers both
| rasterization and raytracing?
| https://gabrielgambetta.com/computer-graphics-from-scratch/i...
|
| I have to admit I'm quite surprised by how _eerily similar_
| this website feels to my book. The chapter structure, the
| sequencing of the concepts, the examples and diagrams, even the
| "why" section (mine https://gabrielgambetta.com/computer-
| graphics-from-scratch/0... - theirs
| https://lisyarus.github.io/blog/posts/implementing-a-tiny-
| cp...)
|
| I don't know what to make of this. Maybe there's nothing to it.
| But I feel uneasy :(
| delta_p_delta_x wrote:
| Ah yes, great book; thanks for pointing it out. Added to the
| list.
|
| As for similarity, I think the sections you've highlighted
| are _broadly_ similar, but I can 't detect any phrase-for-
| phrase copy-pasting that is typical of LLM or thesaurus find-
| replace. I feel that the topic layout and the motivations for
| any tutorial or course covering the same subject matter will
| eventually converge to the same broad ideas.
|
| The website's sequence of steps is also a bit different
| compared to your book's. And most telling, the _code_ ,
| diagrams, and maths in the website are all different (such
| assets are usually an instant giveaway of plagiarism). You've
| got pseudocode; the website uses the C++ standard library to
| a great extent.
|
| If it were me, I might rest a little easier :)
| lisyarus wrote:
| Hi! Blog post author here. I have heard the "Computer
| Graphics from Scratch" book before, but I haven't read it
| myself, so it would be quite hard for me to plagiarize it.
| I guess some similarities are expected when talking about a
| well-established topic.
| gopla wrote:
| An additional resource on rasterisation, using the scan
| conversion technique:
|
| https://kristoffer-dyrkorn.github.io/scanline-rasterizer/
| Levitating wrote:
| I can vouch for scratchapixel, it taught me the basics of 3d
| projection
| feelamee wrote:
| > Triangles are easy to rasterize
|
| sure, rasterizing triangle is not so hard, but.. you know,
| rasterizing rectangle is far far easier
| maximilianburke wrote:
| ...as long as all points are co-planar.
| qingcharles wrote:
| Rasterizing triangles is a nightmare, especially if performance
| is a goal. One of the biggest issues is getting abutting
| triangles to render so you don't have overlapping pixels or
| gaps.
|
| I did this stuff for a living 30 years ago. Just this week I
| had Deep Think create a 3D engine with triangle rasterizer in
| 16-bit x86 for the original IBM XT.
| nottorp wrote:
| > One of the biggest issues is getting abutting triangles to
| render so you don't have overlapping pixels or gaps. > I did
| this stuff for a living 30 years ago.
|
| So you did CAD or something like that? Since that matters far
| less in games.
| qingcharles wrote:
| It still looks janky in games. Look at any old 8/16-bit
| pre-GPU games. Getting this stuff right is hard.
| ralferoo wrote:
| It's fairly easy to get triangle rasterisation performant if
| you think about the problem hard enough.
|
| Here's an implementation I wrote for the PS3 SPU many moons
| ago: https://github.com/ralferoo/spugl/blob/master/pixelshade
| rs/t...
|
| That does perspective correct texture mapping, and from a
| quick count of the instructions in the main loop is
| approximately 44 cycles per 8 pixels.
|
| The process of solving the half-line equation used also
| doesn't suffer from any overlapping pixel or gaps, as long as
| both points are the same and you use fixed point arithmetic.
|
| The key trick is to rework each line equation such that it's
| effectively x.dx+y.dy+C=0. You can then evaluate
| A=x.dx+y.dy+C at the top left of the square that encloses the
| triangle. Every pixel to the right, you can just add dx, and
| every pixel down, you can just add dy. The sign bit indicates
| whether the pixel is or isn't inside that side of the
| triangle, and you can and/or the 3 side's sign bits together
| to determine whether a pixel is inside or outside the
| triangle. (Whether to use and or or depends on how you've
| decided to interpret the sign bit)
|
| The calculation for the all the values consumed by the
| rasteriser (C,dx,dy) for all 3 sides of a triangle, given the
| 3 coordinates is here: https://github.com/ralferoo/spugl/blob
| /db6e22e18fdf3b4338390...
|
| Some of the explanations I wrote down while trying to
| understand Barycentric coordinates (from which this stuff
| kind of just falls out of), ended up here:
| https://github.com/ralferoo/spugl/blob/master/doc/ideas.txt
|
| (Apologies if my memory/terminology is a bit hazy on this -
| it was a very long time ago now!)
|
| IIRC in terms of performance, this software implementation
| filling a 720p screen with perspective-correct texture mapped
| triangles could hit 60Hz using only 1 of the the 7 SPUs,
| although they weren't overlapping so there was no overdraw.
| The biggest problem was actually saturating the memory
| bandwidth, because I wasn't caching the texture data as an
| unconditional DMA fetch from main memory always completed
| before the values were needed later in the loop.
| ralferoo wrote:
| Forgot to add, that when you're calculating these fixed
| values for each triangle, you can also get the hidden
| surface removal for free. If you have a constant CW or CCW
| orientation, the sign of the base value for C tells you
| whether the triangle is facing towards you or away.
| qingcharles wrote:
| It does, but all hell breaks loose if you start having
| translucent stuff going on :(
| qingcharles wrote:
| It's definitely not "fairly easy" once you get into
| perspective-correct texture-mapping on the triangles, and
| making sure the pixels along the diagonal of a quad aren't
| all janky so they texture has an obvious line across it.
| Then you add on whatever methods you're using to
| light/shade it. It gets horrible really quick. To me, at
| least!
| nottorp wrote:
| With the discrete GPUs pricing themselves out of the consumer
| space, we may actually need to switch back to software rendering
| :)
| Sohcahtoa82 wrote:
| I tried doing this in Python a bit ago. It did not go well and it
| really showed how SLOW Python really is.
|
| Even with just an 1280x720 window, setting every pixel to a
| single color by setting a value in a byte array and then using a
| PyGame function to just give it a full frame to draw, I maxed out
| at like 10 fps. I tried so many things and simply could not get
| any faster.
___________________________________________________________________
(page generated 2026-01-30 23:00 UTC)