If you've seen something on a line but now you don't, because the triangle is convex you're sure it can't show up again for the rest of the line, so we will be able to just skip empty space to the next row. To be clear, it's not in place in this video, it's coming soon!

This is a simulation of our own custom hardware so we are defining our own hardware and shading language and everything. The rasterization algorithm is pretty classic Pineda stuff from late 80s and as we're scanning across the line we can track if we have seen something so far.

Maybe, but I'm probably not the person to figure it out? I don't have a deep understanding of how SC1's code works, just the console.

what's this!? You're on bsky?!

Holy dooly. Never heard of that. Thanks for the PSA :)

Penguin has its own custom JIT which performs optimization passes on both SH4 and ARM7DI guest instructions. We emit code for both x86_64 and aarch64. I am currently writing a webgpu-based simulation of the powervr GPU which should have excellent accuracy and even be useful in other emulators.

Here you can see some breakdown of how cell shading works in Jet Grind Radio. Body parts are drawn twice, with the second one drawn completely black and "expanded" size, with all screen space depth values moved away from the camera to give the appearance of an outline. Maybe I should make a video...

Our GPU command buffers are written to system memory and pulled by the GPU on-demand. You can see in the screenshot that we also have debugging-related pseudo-commands in the buffer stream which the emulator show to help with debugging. #gpudev #emulator

Additionally, we have our own pipelined RISCV implementation now which is substantially faster and more fully-featured than the excellent picorv32 we were using before. Pictured here, we also created an emulator which can simulate the CPU and GPU at a very low level.

Sharing here the first on-FPGA triangle we rendered. This was some time ago, and we have performed significant pipelining optimizations to the design at this point. Rasterization can be easily parallelized. It's based on a moving grid of rasterizers based on Pineda-style edge-equations.

I have developed for both FPGAs and spent years writing emulators. What you said later is true: both have their pros and cons (like almost everything). FPGAs can have effectively zero latency and interact with real hardware. Emulators can do a much wider range of things and reach a wider audience.