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

Implementing a tiny CPU rasterizer (2024)

lisyarus.github.io

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Implementing a tiny CPU rasterizer (2024)

#21

Post by ralferoo »

qingcharles wrote: post #18
ralferoo wrote: post #14

Earlier quoted context omitted.

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/pixelshaders/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 equa…

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!

The first link I posted, specifically lines 200-204 ( https://github.com/ralferoo/spugl/blob/master/pixelshaders/t... ) isn't quite what I remembered as this seems the be doing a texture correct visualisation of s,t,k used for calculating mipmap levels and not actually doing the texture fetch - you'll have to forgive me, it's been 17 years since I looked at the code so I forgot where everything is.

It looks like the full texture mapper including mipmap levels is only in the OLD version of the code here: https://github.com/ralferoo/spugl/blob/master/old/shader.c

This is doing full perspective correct texture mapping, including mipmapping and then effectively doing GL_NEAREST by sampling the 4 nearest pixels from 2 mipmap layers, and blending both sets of 4 pixels and then interpolating between the mipmaps.

But anyway, to do any interpolation perspective correctly, you need to interpolate w, exactly as you would interpolate r,g,b for flat colours or u,v for texture coords. You then have 1 reciprocal per pixel to get 1/w, and then multiply all the interpolated parameters by that.

In terms of "obvious line across it", it could be that you're just not clamping u and v between 0,1 (or whatever texture coordinates you're using) or clamping them not wrapping for a wrapped texture. And if you're not doing mipmapping and just doing nearest pixel on a high-res texture, then you will get sparklies.

I've got a very old and poor quality video here, and it's kind of hard to see anything because it was filmed using a phone pointing at the screen: https://www.youtube.com/watch?v=U5o-01s5KQw I don't have anything newer as I haven't turned on my linux PS3 for probably at least 15 years now, but even though it's low quality there's no obvious problem at the edges.

Re: Implementing a tiny CPU rasterizer (2024)

#22

Post by ralferoo »

qingcharles wrote: post #19
ralferoo wrote: post #16

Earlier quoted context omitted.

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.

It does, but all hell breaks loose if you start having translucent stuff going on :(

I'm not sure I understand the problem you're having.

Obviously, if you have translucent, then you need to be doing those objects last, but if you're using the half line method, then two triangles that share an edge will follow the same edge exactly if you're using fixed point math (and doing it properly, I guess!) A pixel will either be in one or the other, not both.

The only issue would be if you're wanted to do MSAA, then yes it gets more complicated, but I'd say it's conceptually simpler to have a 2x resolution and then downsample later. I didn't attempt to tackle MSAA, but one optimisation would be to write 2x2 from a single calculated pixel and but do the half line equation at the finer resolution to determine which of the 2x2 pixels receive the contribution. And then after you render everything, do a 2x2 downsample on the final image.

Re: Implementing a tiny CPU rasterizer (2024)

#23

Post by cyber_kinetist »

nottorp wrote: post #10

With the discrete GPUs pricing themselves out of the consumer space, we may actually need to switch back to software rendering :)

That's too much of a stretch, but I believe games of the next era will be optimized more towards integrated GPUs (such as AMD's iGPU in the Steam Deck and Steam Machine).

When hardware is priced out for most consumers (along with a global supply chain collapse due to tariffs and a potential Taiwan invasion), a new era awaits where performance optimization is going to be critical again for games. I expect existing game engines like Unity and Unreal Engine falling out because of all the performance issues they have, and maybe we can return to a temporary "wild west" era where everyone has their own hacky solution to cram stuff into limited hardware.

Re: Implementing a tiny CPU rasterizer (2024)

#25

Post by tubs »

qingcharles wrote: post #8
feelamee wrote: post #6

> Triangles are easy to rasterize sure, rasterizing triangle is not so hard, but.. you know, rasterizing rectangle is far far easier

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.

As the other posters have shown it’s not that hard.

Most graphics specs will explicitly say how tie break rules work.

The key is to work in fixed point (16.8 or even 16.4 if you’re feeling spicy). It’s not “trivial” but in general you write it and it’s done. It’s not something you have to go back to over and over for weird bugs.

Wide lines are a more fun case…

Re: Implementing a tiny CPU rasterizer (2024)

#26

Post by nottorp »

cyber_kinetist wrote: post #23
nottorp wrote: post #10

With the discrete GPUs pricing themselves out of the consumer space, we may actually need to switch back to software rendering :)

That's too much of a stretch, but I believe games of the next era will be optimized more towards integrated GPUs (such as AMD's iGPU in the Steam Deck and Steam Machine). When hardware is priced out for most consumers (along with a global supply chain collapse due to tariffs and a potential Taiwan invasion), a new era awaits where performance optimization is going to be critical again for games. I expect existing gam…

> everyone has their own hacky solution to cram stuff into limited hardware

Limited hardware gave us a lot of classic titles and fundamental game mechanics.

Off the top of my head:

Metal Gear's stealth was born because they couldn't draw enough enemy sprites to make a shooting game. Instead they drew just a few and made you avoid them.

Ico's and Silent Hill's foggy atmosphere is partially determined by their polygon budget. They didn't have the hardware to draw distant scenery so they hid it in fog.

Re: Implementing a tiny CPU rasterizer (2024)

#27

Post by gustavopezzi »

delta_p_delta_x wrote: post #2

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/ Physic…

Thanks for mentioning pikuma. :-)

The 3D software rendering is still the most popular lecture from our school even after all these years. And it really surprises me because we "spend a lot of time" talking about some old techniques (MS-DOS, Amiga, ST, Archimedes, etc.). But it's fun to see how much doing things manually help students understand the math and the data movement that the GPU helps automate and vectorize in modern systems.

Re: Implementing a tiny CPU rasterizer (2024)

#28

Post by bool3max »

cyber_kinetist wrote: post #23
nottorp wrote: post #10

With the discrete GPUs pricing themselves out of the consumer space, we may actually need to switch back to software rendering :)

That's too much of a stretch, but I believe games of the next era will be optimized more towards integrated GPUs (such as AMD's iGPU in the Steam Deck and Steam Machine). When hardware is priced out for most consumers (along with a global supply chain collapse due to tariffs and a potential Taiwan invasion), a new era awaits where performance optimization is going to be critical again for games. I expect existing gam…

That's wishful thinking. The reality is that your iGPU will be used to decode the video stream of an Unreal game running on a dedicated GPU on some cloud server which you pay a monthly subscription fee for.

Re: Implementing a tiny CPU rasterizer (2024)

#29

Post by nottorp »

qingcharles wrote: post #13
nottorp wrote: post #11

Earlier quoted context omitted.

> 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.

It still looks janky in games. Look at any old 8/16-bit pre-GPU games. Getting this stuff right is hard.

It does. But gamers accepted it and played the hell out of it. That's why I assumed you did CAD.
Post reply on HN