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.
Sharing a fun visualization of what the early shader-based rasterizer on our custom #gpu looks like in-simulator. Threads walk over the bounding box area of a triangle. Next optimization here is: on a row, if you have seen some pixels and now you don't, skip to next row. #fpga #emulator
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?!
More progress on #webgpu #dreamcast GPU simulation. This is opaque list-only rendering with just base colors (no texturing). You can see how Soul Calibur would multiply these base colors with albedo texture to produce per-vertex lighting. Progress!
Holy dooly. Never heard of that. Thanks for the PSA :)
#webgpu -based simulation of the #dreamcast PowerVR GPU is making progress slowly. The entire ISP/TSP processing of lists is done via compute shader. The shader walks over TA-generated data structures in dreamcast VRAM. Stutters are understood and will be fixed. PROGRESS!!
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...
The "Penguin" project, a #dreamcast #emulator collaboration between myself and uchinokitsune for many years at this point is nearly in a release-able state. It is neither the most accurate nor fastest emulator, but has /many/ tools for inspecting and debugging games.
www.youtube.com/watch?v=OaIa...
Re-sharing the rough first take on the #dreamcast #gpu #powervr internals. Goes over tiled rendering, the Tile Accelerator, and basic PowerVR ISP/TSP operations.
Because of "life", it will still be a few weeks until I can have a cleaned up version of this out.
I got tired of figuring out markdown site generators that didn't quite do what I want, so I just made my own in like <200 lines of python.
sh4.dev is made of
github.com/gh-sh4/bloggg < tool
github.com/gh-sh4/sh4.d... < site
It's ugly as sin right now, will update the template CSS later 😁
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.
Threads to catch up existing projects:
sh4.dev/dragon/ is the product of myself and uchinokitsune developing a "new" fantasy console in #verilog for use on real #fpga. We design the hardware, all software, and games. Currently still deep into GPU development. Architecture notes in the link
Hello everyone! I was previously on Twitter/X, left because it's a bit of a dumpster fire at this point. I post on FPGA, emulation, retro gaming, low level optimization, maybe sometimes music.
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.
