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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The question is not if Rust is more expressive but if C is expressive enough for the Linux kernel. So far there is no evidence that Rust adds any value here. And if C is missing certain features, they can be added. It looks like ISO is looking at that very thing in C2x and beyond.
These extreme fire events extend across the entire Northern hemisphere right now (Oregon, Washington, Montana, Greece, Turkey, Siberia etc.). Blaming California specific forest management practices is disingenuous at best.
What kind of false positives are you seeing with gcc?
Personally I have never seen gcc spitting out a false positive. IMO it's always a good idea to explicitly downcast even if you know that it's 'safe'. That way someone else will see instantly what's going on. The fact that Rust requires it should tell us something.
Consider modern C++ practices as outlined here: https://github.com/cpp-best-practices/cppbestpractices/blob/...