Sorry to be blunt, that C/C++ code is crustyyy. Just to start with run this through an decently complete clang-tidy profile and fix all errors and warnings. That should become part of your build. The longer you hold out on that the harder it will be. Your code has no provisions to handle fuzzed/corrupted content. Maybe a better idea would be to switch this entire code base over to Rust.
You got a long way to go. Writing a rasterizer from scratch is a huge undertaking.
What's the internal color space, I assume it is linear sRGB? It looks like you are going straight to RGBA FP32 which is good. Think how you will deal with denormals as the CPU will deal with those differently compared to the GPU. Rendering artifacts galore once you do real world testing.
And of course IsInf and NaN need to be handled everywhere. Just checking for F::ZERO is not enough in many cases, you will need epsilon values. In C++ doing if(value==0.0f){} or if (value==1.0f){} is considered a code smell.
Just browsing the source I see Porter Duff blend modes. Really, in 2025? Have fun dealing with alpha compositing issues on this one. Also most of the 'regular' blend modes are not alpha compositing safe, you need special handling of alpha values in many cases if you do not want to get artifacts. The W3C spec is completely underspecified in this regard. I spent many months dealing with this myself.
If I were to redo a rasterizer from scratch I would push boundaries a little more. For instance I would target full FP32 dynamic range support and a better internal color space, maybe something like OKLab to improve color blending and compositing quality. And coming up with innovative ways to use this gained dynamic range.
You didn't mention one of the biggest source of 2d vector graphic artifacts: mapping polygon coverage to the alpha channel, which is what virtually all engines do, and is the main reason why we at Mazatech are writing a new version of our engine, AmanithVG, based on a simple idea: draw all the paths (polygons) at once. Well, the idea is simple, the implementation... not so much ;)
> Just browsing the source I see Porter Duff blend modes. Really, in 2025? Have fun dealing with alpha compositing issues on this one.
What should we be using in 2025? I thought pre-multiplied alpha is essentially what you go for if you want a chance of alpha compositing ending up correct, but my knowledge is probably outdated.
Great article! I'm going to have to take my time on that one.
But I guess I'm confused why @morio said "Just browsing the source I see Porter Duff blend modes. Really, in 2025?" because I'm not sure what they were expecting to be used in 2025.
It's device sRGB for the time being, but more color spaces are planned.
You are correct that conflation artifacts are a problem and that doing antialiasing in the right color space can improve quality. Long story short, that's future research. There are tradeoffs, one of which is that use of the system compositor is curtailed. Another is that font rendering tends to be weak and spindly compared with doing compositing in a device space.
Yeah, there is an entire science on how to do font rendering properly. Perceptually you should even take into account if you have white text on black background or the other way as this changes the perceived thickness of the text. Slightly hinted SDFs kind of solve that issue and look really good but of course making that work on CPUs is difficult.
What's difficult with font SDFs on the CPU? The bezier paths?
I made myself a CPU SDF library last weekend, primarily for fast shadow textures. It was fun, and I was surprised how well most basic SDFs run with SIMD. Except yeah Beziers didn't fair well. Fonts seem much harder.
SIMD was easy, just asked Claude to convert my scalar Nim code to Neon SIMD version and then to an sse2 version. Most SDFs and gaussian shadowing got 4x speedup on my macbook m3. It's a bit surprising the author has so much trouble in Rust. Perhaps fp16 issues?
I haven't looked at this recently but from what I remember rendering from SDF textures instead from simple alpha textures was 3-4 times slower, including optimizations where fully outside and inside areas bypass the per pixel square root. Of course SIMD is a must, or at least the use _mm_rsqrt_ss.
The majority of US homes use a split phase setup. So 240V is readily available and in fact the only way you can run central AC. Nominal voltage of a single phase is 120V. Technology Connections has an entire video about it.
One example from the software side: A common thing to do in data processing is to obtain bit offsets (compression, video decoding etc.). If a byte would be 10 bits you would need mod%10 operations everywhere which is slow and/or complex. In contrast mod%(2^N) is one logic processor instruction.
I find hand soldering QFN is faster, easier and more reliable than (T)QFP once you got enough practice. If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe. Do not use one of those flux pens, those do not dispense enough flux.
> If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe.
I've never tried this but this makes a lot of sense in my mind's eye. I'll try this next time I have such an issue.
-------
TQFP seems nice because I can sloppily shove tons of solder down, and then just wick up all the excess solder with solder wick. In fact, I purposefully over-solder all the TQFP joints for this practice. (Too much solder during reflow, and then just a quick cleanup step with a soldering iron later).
I concur, bought insurance for a new car early January and got it instantly using esurance.com (Allstate) by just entering my VIN. Yes, I am in SF/Bay Area.
interesting. i forget if it was allstate or state farm but one of them refused to do online and also refused to do fewer than 14 days out - this was like two days ago.
To be clear: I already had my old car insured with them for several years, so I just removed the old car and added the new car. I am also 50+ with no negative record and a garage in a single family home.
Ok, I'll bite. Uploaded my gerbers using https://instantdfm.bayareacircuits.com/ Site does not respond for 10 minutes+ which is is not a good start. It's instant on the Chinese sites.
Quote for 100 boards (ENIG) on Bay Area Circuits, 10 days lead time, excluding shipping: $1000 ($1244 for 5 days lead time)
Todays quote for exact same 100 boards (ENIG) on pcbway.com, _including_ DHL shipping cost, 2 days lead time: $148 (shipping to Bay Area is usually 2 days with DHL, so really 4 days lead time). I've never had any quality issues and my boards have fine pitch 0.4mm BGA parts.
Yeah no, not even close. Certainly not marginally higher.
It's slightly cheaper than oshpark.com, they want $15 a board.
I do this all the time. OP is talking about of their ass.
China is dramatically cheaper than domestic.
If it wasn't for the DoD requiring all military parts be domestically manufactured, there probably wouldn't be a board house (or metal fab) left in the US.
And that is domestic versus imported. In Shenzhen they do production of smaller quantities in 12 hours overnight for $30 extra with local express delivery.
I hung out with a friend of mine in Shenzen who does this stuff all the time (and is Chinese not that is super important other than the fact being fluent helps a ton).
Together we prototyped a product over a 2 month period, him handling the HW and EE bits and me writing the board firmware and HIL simulator/test-harness.
We would get some boards, he would find and correct any issues with the board, get a new file to the board house before 5pm and we would get new boards in the morning at 9am delivered by a motorbike courier for about $20 or something. As a software guy that seemed pretty insane to me.
All up we probably did about 6 or 7 HW revisions like that and a few of those probably could have been avoidable if more care was taken but why would we when it's so cheap to iterate so quickly?
Unfortunately for various reasons we didn't choose to continue the project but I learnt a hell of a lot and really enjoyed hanging in Shenzhen and getting to understand the hacker culture there a bit more. We burnt overall a pretty small amount of money to learn some important lessons that I think would have been much more expensive anywhere else in the world.
If you every write more about it, please post a link here in HN, I'm sure tons of people would be interested in more details about the what, why, how of what you were doing, and life in Shenzhen.
I haven't used pcbway so maybe they're much better, but I can say that messups and throwaway board issues are common enough with JLCPCB assemblies that their "sorry, here's a $5 coupon" response is a meme in hobbyist communities. They're very hard to trust for anything truly complex or critical.
I’ve heard very positive things about pcbway. I use JLCPCB regularly for fab and assembly. Most issues I’ve had come down to misunderstandings due to problems in their web order PCB viewer, which can be slightly janky. I have however learned to use it properly and I don’t have that type of error anymore.
As far as PCB fab or PCBA quality issues, I’m unable to think of any problems I’ve had across 15+ orders over the last three years. I just got another two PCBA jobs back in the last couple weeks and they were great.
I’m honestly in awe of what JLCPCB does and it’s a big inspiration to me for how much better things could be in the USA if we were committed to manufacturing.
The short answer is yes. The long answer is that most of the VideoToaster software and hardware were specifically designed for the Amiga hardware architecture and therefore did not easily port to other systems. The extension card was Zorro II and the performance critical software was written in 68k assembly. In some cases the assembly code is written in such a way that it depends on cycle exact sync with the video signal. Original source code is on github.com, search for OpenVideoToaster.
If I recall correctly the original video toaster, and I believe even the revised toaster 2000 and 4000 all occupied the video slot, a dedicated internal interface that provided direct access to analog RGB component signals as well as some other video timing and audio channels. There was no connection to the Zoro II or later Zorro III system buses. The Amiga 4000 video slot added digital rgb counterparts to these analog signals, and also some oddball 8 bit connections to,I believe the parallel port UART pins.
You can buy Prusa MK3 kits from Aliexpress for half the price of the original. I bought a kit from Prusa and one knockoff from Aliexpress. Parts wise they are 100% the same and perform the exact same way. Do I feel bad about it? Kind of. The Chinese seller certainly did not put R&D into any of it. And being in China makes sourcing much easier.
Yeah, I've bought a knockoff on Aliexpress too, but mine was not a 100% clone. I bought a kit that came with the Bear upgrade and didn't come with the parts that would be replaced during the Bear upgrade. Those are the ones I think are hard to define without being vague. My worry is that by adding vague and all-encompassing restrictions, the license will no longer be free.
Consider modern C++ practices as outlined here: https://github.com/cpp-best-practices/cppbestpractices/blob/...