Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing a Tiny CPU Rasterizer

lisyarus.github.io

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Implementing a Tiny CPU Rasterizer

#31

Post by randomNumber7 »

vardump wrote: post #4
smokel wrote: 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

Checking every pixel is generally faster on modern hardware due to SIMD! Of course you’ll need to clip properly. There are some pathological cases, like a thin long almost diagonal triangles. But those (rare) cases can be handled too by some subdivision clipping.

I get that a GPU is doing it like that, but are you really sure this is the better algorithm for cpu?

Re: Implementing a Tiny CPU Rasterizer

#32

Post by vardump »

randomNumber7 wrote: post #31
vardump wrote: post #4

Earlier quoted context omitted.

Checking every pixel is generally faster on modern hardware due to SIMD! Of course you’ll need to clip properly. There are some pathological cases, like a thin long almost diagonal triangles. But those (rare) cases can be handled too by some subdivision clipping.

I get that a GPU is doing it like that, but are you really sure this is the better algorithm for cpu?

Yes, because you can handle 8 or 16 pixels in parallel with SIMD.

You have also less branches which helps a lot.

Re: Implementing a Tiny CPU Rasterizer

#33

Post by hakilebara »

I strongly recommend this course “3D Computer Graphics Programming”[1] from Gustavo Pezzi. It walks you through the creation of CPU rasterizer from scratch in C. I am working through it right now and I enjoy it a lot.

[1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...

Re: Implementing a Tiny CPU Rasterizer

#34

Post by greenbit »

saw-lau wrote: post #24

This might also be of interest to anybody who enjoyed these articles: https://www.scratchapixel.com/ .

Despite seeing code early in the series, didn't see any code that would actually put pixels on a screen, or even to write a static image into a file, at least not within the first 6 or 7 units. Somewhere around that point there is some reference to OpenGL, so presumably you could start to brighten patches of screen at that point?

Offering this as constructive criticism - the tutorials could be more engaging if the student could follow along and cause things to happen directly on the screen. It'd be awesome to organize the 1st unit as more than just confirming one has a compiler, to take it all the way to a kind of "hello, pixels".

Re: Implementing a Tiny CPU Rasterizer

#35

Post by Agingcoder »

magicalhippo wrote: post #27
Agingcoder wrote: post #20

Earlier quoted context omitted.

Perspective correct texture mapping was too expensive for the hardware available at fatmap time I think ? Edit: it was actually possible at the time.

It was but it was borderline. A typical trick was to do the division at the start and end of a span, and interpolate linearly, rather than per pixel. This worked well enough if the triangle was seen fairly straight on and was not too large. Quake popularized the per-8 pixels technique, which is close enough in most cases.

Ah yes indeed !I had forgotten about the quake trick. Thanks !

Re: Implementing a Tiny CPU Rasterizer

#36

Post by scoopr »

magicalhippo wrote: post #9

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 was reading 3dica[0], though I was too young or stupid to really grok it back then.

[0] https://www.modeemi.fi/drdoom/3dica/3dica.htm

Re: Implementing a Tiny CPU Rasterizer

#37

Post by virexene »

Joker_vD wrote: post #23

By the way, does anyone know how to modify the standard perspective projection to have a spherical cap instead of the flat rectangle as its far clipping plane? Having the flat rectangle means that you can see further from the corner of your eye than in front of you which is definitely not how the human vision works, and there are some games where this bizarre behaviour is very noticeable: you can barely see some thin…

If you want that projection to still be expressible as a matrix transformation, I don't think that's possible.

Re: Implementing a Tiny CPU Rasterizer

#38

Post by atan2 »

hakilebara wrote: post #33

I strongly recommend this course “3D Computer Graphics Programming”[1] from Gustavo Pezzi. It walks you through the creation of CPU rasterizer from scratch in C. I am working through it right now and I enjoy it a lot. [1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...

Oh yes. One of the best!

Re: Implementing a Tiny CPU Rasterizer

#39

Post by gustavopezzi »

magicalhippo wrote: post #9

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…

Thank you for posting this. I cannot believe I did not know about it yet!
Post reply on HN