Live data from Hacker News

Implementing a Tiny CPU Rasterizer

lisyarus.github.io

11–20 of 50 posts

Re: Implementing a Tiny CPU Rasterizer

#11
I was super into this sort of thing until I hit triangle clipping concerns in homogeneous coordinate space.

Filling the triangle and spinning the cube are the perfect level of difficulty if you want to get your hands a bit dirty and achieve that sense of accomplishment. Anything beyond this starts to feel like a very risky time-reward tradeoff.

Re: Implementing a Tiny CPU Rasterizer

#12
post #3

Wait, what? They rasterize a triangle by checking for each pixel if it intersects with the triangle? Where are the days when you learned Bresenham [1] or fixed-point arithmetic [2] to determine the extents of a scan line, and then fill it with an ordinary for-loop? [1] https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm [2] https://en.wikipedia.org/wiki/Fixed-point_arithmetic

There used to be a series of articles similar to this one that did things that way as well. As I recall, the author was making swiftshader, which I think was acquired by RAD Game Tools, then the articles got bitrot and eventually disappeared.

Re: Implementing a Tiny CPU Rasterizer

#14

Nostalgia flashback. Anyone else implemented a renderer based on fatmap2.txt[1]? I came up with my own approach using bresenham and storing spans, but it was slow and sucked. Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation. Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to…

I don't think I ever came across fatmap2.txt, but I do miss the good ol' times. I think my reference was 3DGPL, unfortunately can't find a live link to that.

Took a quick look at fatmap2 and surprisingly it doesn't do perspective-correct texture mapping (although it points to some other document in the introduction).

Re: Implementing a Tiny CPU Rasterizer

#15
post #11

I was super into this sort of thing until I hit triangle clipping concerns in homogeneous coordinate space. Filling the triangle and spinning the cube are the perfect level of difficulty if you want to get your hands a bit dirty and achieve that sense of accomplishment. Anything beyond this starts to feel like a very risky time-reward tradeoff.

I will cover triangle clipping in part 5, and it's much less scary than it seems to be!

Re: Implementing a Tiny CPU Rasterizer

#16
post #10
post #2

I love looking at stuff like this, working in the GPU space has only ever renewed my ambitions to work on similar projects. The hardest thing I always ran into with the more optimized fill algorithms was working around the single pixel holes that appear when doing everything with integers. Small nitpick though, there seems to be an issue with the source code views, the file names and the first line of the code are on…

It looks like for some reason Firefox isn't being served the same source as Safari or Chrome. In those browsers, the filename is wrapped in , , and elements, and followed by . But in the version of the HTML that Firefox receives, all that is missing and the filename is just some text that ends up immediately in front of the first line of code.

Yep, I've seen this problem when testing locally on chrome, but I've no idea what that is. Reloading the page usually works.

Re: Implementing a Tiny CPU Rasterizer

#17

Nostalgia flashback. Anyone else implemented a renderer based on fatmap2.txt[1]? I came up with my own approach using bresenham and storing spans, but it was slow and sucked. Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation. Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to…

I don't think I ever came across fatmap2.txt, but I do miss the good ol' times. I think my reference was 3DGPL, unfortunately can't find a live link to that. Took a quick look at fatmap2 and surprisingly it doesn't do perspective-correct texture mapping (although it points to some other document in the introduction).

> I think my reference was 3DGPL, unfortunately can't find a live link to that.

This one[1], code being here[2]?

> surprisingly it doesn't do perspective-correct texture mapping

Yeah it was covered in some other document, can't recall which. I have some memory of fatmap3, but I can't find any references to it, and any files I had were on my IBM Deathstar[3]...

[1]: https://www.gamers.org/dEngine/rsc/

[2]: https://www.gamers.org/dEngine/rsc/3dgpl/code/

[3]: https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_fa...

Re: Implementing a Tiny CPU Rasterizer

#18
I once wrote a tiny cpu rasterizer in dlang. It is more efficient than what is shown here, since it uses only integer arithmetic (based on bresenham's algorithm). E.g. for a triangle it outputs the points in the triangle without ever considering a single pixel outside the triangle.

It's based on ranges (similiar to the ones added to C++) and the concept works very well imo. Could be a good exercise to translate it to C++23 (using coroutines with the range "generator").

https://github.com/the5avage/shapes

Re: Implementing a Tiny CPU Rasterizer

#19

Nostalgia flashback. Anyone else implemented a renderer based on fatmap2.txt[1]? I came up with my own approach using bresenham and storing spans, but it was slow and sucked. Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation. Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to…

Yes I read fatmap. Writing software rasterizers was what got me into coding when I was a teenager. Quite honestly, it was a great way to learn: algorithms, hardware, assembly, software architecture, all had to be taken care of to get a usable 3D engine.

Re: Implementing a Tiny CPU Rasterizer

#20

Nostalgia flashback. Anyone else implemented a renderer based on fatmap2.txt[1]? I came up with my own approach using bresenham and storing spans, but it was slow and sucked. Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation. Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to…

I don't think I ever came across fatmap2.txt, but I do miss the good ol' times. I think my reference was 3DGPL, unfortunately can't find a live link to that. Took a quick look at fatmap2 and surprisingly it doesn't do perspective-correct texture mapping (although it points to some other document in the introduction).

Perspective correct texture mapping was too expensive for the hardware available at fatmap time I think ?

Edit: it was actually possible at the time.

Post reply on HN