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

21–30 of 50 posts

Re: Implementing a Tiny CPU Rasterizer

#21

Post by amelius »

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

They probably do that because shading uses the same general approach (a float computation per pixel, with some shared terms).

Re: Implementing a Tiny CPU Rasterizer

#22

Post by DeathArrow »

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 had tough times with graphics under DOS. BorlandC C had a limited graphics library called Turtle. So I used DOS mode 13H for fancy 320x200 display with 256 colors.

Later, somebody gave me the source code for some graphics libraries together with some drivers and I could use 800x600 resolution with millions of colors.

After that I went to Windows and Linux and graphics APIs quit being an issue.

Re: Implementing a Tiny CPU Rasterizer

#23

Post by Joker_vD »

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 thing poking out of the fog before you, then you turn the camera to the left, and now the thing is visible well and clearly near the screen border. Turn camera back, and it goes back into the fog.

Re: Implementing a Tiny CPU Rasterizer

#25

Post by gmiller123456 »

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…

A spherical cuttoff limit is also not how the human eye sees. Light can travel from any distance to reach your eye. The view frustrum is an optimization, and there will always be cases where it fails.

Re: Implementing a Tiny CPU Rasterizer

#26

Post by Joker_vD »

gmiller123456 wrote: post #25
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…

A spherical cuttoff limit is also not how the human eye sees. Light can travel from any distance to reach your eye. The view frustrum is an optimization, and there will always be cases where it fails.

> Light can travel from any distance to reach your eye.

Yes, but it won't necessarily register so unless we're talking about insanely bright distant object that should be visible through fog from any distance and which also is not a part of the skybox, this particular problem practically never arises. The flat far plane, on the other hand, is glaringly obvious in e.g. Minecraft, or any Unity game with first-person view and fog.

Re: Implementing a Tiny CPU Rasterizer

#27

Post by magicalhippo »

Agingcoder wrote: post #20
ggambetta wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: Implementing a Tiny CPU Rasterizer

#28

Post by nkrisc »

gmiller123456 wrote: post #25
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…

A spherical cuttoff limit is also not how the human eye sees. Light can travel from any distance to reach your eye. The view frustrum is an optimization, and there will always be cases where it fails.

But it might more accurately reflect human visual perception. I can’t think of any case where your peripheral vision will perceive things that you won’t perceive by looking directly at them.

Re: Implementing a Tiny CPU Rasterizer

#29

Post by [deleted] »

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

[deleted]

Re: Implementing a Tiny CPU Rasterizer

#30

Post by randomNumber7 »

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

Someone in the comments here posted a version of that and was downvoted. Probably the author doesn't like competition.
Post reply on HN