I learned PCB design, 3D printing and C just to listen to music

Until you get a panning shot and then it looks very juddery. Filmmakers have gotten quite good at dealing with the limitation but it is a limitation. (That said, you do have a challenge with higher fidelity video because it makes it harder to hide the imperfections in what the video is capturing, which makes things tend to look more fake)

Anime (and most animation) can adjust the framerate for what makes sense for the shot or even the element. It's common, for example, that panning happens on ones while the animation happens on twos or threes, because low-framerate panning looks bad and it's relatively easy with cell shading to animate the pan at a higher framerate. And again, the animators use a ton of techniques to deal with the low framerate and avoid the situations where it looks bad.

Which could also apply to train stop displays, if the graphics were designed for it (and almost certainly a consistent 24fps will look better than an inconsistent ~50-60fps).

a hold-over from 60Hz AC power, baked into NTSC television and inherited by arcades and early consoles as a structural default. Then it became a benchmark of sorts when the 3D era made 60fps harder to reach, and got exacerbated by early LCDs pretty much standardizing on 60Hz.

Then come games like COD (2007) with marketing for its 60fpsness, and the 2010s "cinematic 30fps" debaucle.

Personally, I'm fine with 45fps with butter smooth frametimes and no pop-in.

Edit: The semi-recent discourse of 'fake-frames' comes to mind aswell..

> Do you have any specific projects you'd like to build? Post here and we can talk through it.

Sure thing. Yeah, I wanted to build a handheld cyberdeck, like these:

https://www.clockworkpi.com/uconsole

https://hackaday.com/2025/02/27/a-precisely-elegant-cyberdec...

https://hackaday.io/project/202522-cyberdeck-handheld

https://youtu.be/u8kYHgKKhjY

https://youtu.be/IB5OJr_MimQ

The truth is I use my phone a lot. I even write code on my phone, touch screen and all. It's limiting but I put up with it because the handheld form factor is too comfortable, I can use it from anywhere, even in bed.

The cyberdeck is meant to replace the phone with a real keyboard and x86_64 Linux computer, plus any useful peripherals I can cram into the thing. I wanted to use the LattePanda Mu, an Intel N100 System on Module.

I've actually downloaded KiCad and just started using it, figuring I just needed to get started and I'd figure it out as I went along. I just opened up the example schematics I downloaded and started connecting dots like a baby. I actually made some progress, even identified some issues with builtin KiCad libraries, like host/card PCIe socket mismatches that would lead to ERC failures, even tried to contribute those. Then I got severely intimidated when I realized I was trying to route PCIe lines, something even literal professional engineers on discord balked at. That killed the project for some time.

My second attempt came after I subscribed to Claude, who made me aware that the PCIe lines I was dealing with were third generation, and therefore "forgiving". Then I made more progress.

I managed to make some mockups and measure the exact comfortable typing range of my thumbs, and from that I derived an awesome keyboard layout. The keyboard prototype, the thing that will make or break the design, is already at the part where I need to spend real cash on it to have manufactured and shipped so I can test the switches. The taxes involved make it very expensive to make mistakes, though. It doubles the costs of everything.

So I switched to trying everything I can to make the entire system correct before I ship it. Finish the system as a whole and pay for a professional review of the entire thing before shipping even a single prototype. Asked Claude to help me design a safe power supply with BQ25792. Chose the screen for the deck, the same screen used by the Asus ROG Ally.

Wanted to design the full PCB too but I'm unsure if I should create a standalone keyboard first in order to test it out as a separate project. I feel like the whole project depends on it, but it doesn't make financial sense to prototype just that component.

Is there a way to ensure correctness before spending money on this hardware? I'd hate to spend money on this stuff, only to find it doesn't work. How can I reduce this risk?