Part of me was hoping there would be some sort of official arm mainboard announced, I know there's the third party version but they don't seem to sell the main board only.

There was a Not Just Bikes video about how Google Maps is optimised for driving where it pretty much actively hides the biggest walking routes and promotes roads for driving by making them bigger. Useful in the USA for sure but actively harmful in Europe, given that you're more likely to plan a route by which roads you can see, and unless you know what to look for you're not going to find them easily.

I made the mistake of trusting Google Maps with driving directions in Sicily, and it always sent me down tiny single lane (but two way) roads because they were "better" by the algorithm. That taught me to trust my gut and follow the highways/main roads rather than use any shortcuts that an algorithm can conjure up. (I'm sure this has relevance in the age of LLMs).

A surprising number of systems break down if you pause time by passing a 0 time delta, hence why slowing down time is usually the thing that gets done. The alternative (which you imply with your suggestion) is to pass the many paused states down to every system which further complicates their implementation and is a major source of bugs.

The added fact is that many systems still need to continue running, such as audio, video, and input otherwise the program doesn't appear to respond to input and so isn't in a useable state any more.

A paused game is not like a paused video where there is no processing going on. A paused game still has all the rendering usually going on (unless the developers got time to implement something custom), audio still needs to continue, the only thing actually paused in the game logic and gameplay elements.

Given this the game needs to slow down and lock its frame rate while paused and in menus otherwise it will run at full speed and burn a lot of CPU & GPU time. Though I would say this is not usually an issue because it gets fixed pretty quickly during development.

Now more work can be done by the developers to make the paused state this efficient, but it is all a matter of priorities, and in all cases the developers would rather spend their time making the gameplay better and fixing crash bugs. If the player wants their game to run more efficiently then they should reduce the processing demands by limiting the frame rate and lowering quality settings.

Yes, I already understood all that.

> unless the developers got time to implement something custom

As I said: the point nevertheless ought to stand.

I too am in a similar situation, where I am building a niche product - partly for my own benefit, partly for learning, but mostly with the idea of selling it as a commercial product.

I have plenty of worries about it - will the product sell at all, is the product too niche so I'll have sales but not enough to make it full time, am I barking up the wrong tree and there is already an open source free alternative that I've somehow missed, what if nobody likes it? All sorts of stuff, some warranted, and some just the usual fear of making something and putting it out there.

With that being said I do consider a big portion of success being luck, as any one lucky event could catapult you to riches, and any unlucky event could ruin any chance of that happening, but in the end you have to take a risk and put yourself out there for the lucky events to happen.

But as with all risky things you have to be prepared for it all to go to shit, and then have enough of a support network which will help you get back onto your feet.

I genuinely hope that other people have some more concrete advice here or even war stories to tell.

Maybe it is the case that if phones hadn't kept getting bigger then tablets as a category would be more popular as a computing device?

Realistically though a tablet kind of feels like a small TV these days, which is a screen with some apps on it for media consumption. Most people have a TV already for big media consumption, and then their phone will suffice for small scale media consumption, so tablets are a very niche thing for people that have the money and don't feel like using their phone for whatever reason.

Should probably make it explicit in this case, something like: if (const auto& [is_successful, error_message] = foo(n); is_successful)

In a more normal scenario you'd expect to use std::expected here rather than a custom struct with an operator bool.

I like: hand crafted.

I like: rawdogged.

I'm still using Win32 (via WTL) to write a developer focused application, but I know that someday I will need to switch to Qt, dear ImGui, or develop my own UI abstraction layer.

The biggest disappointment has been that all new OS features require a new runtime and are not accessible from just pure Win32 any more. Heck the pipeline for developing UWP/WinUI3 apps requires extra steps to register and install the application just to run it inside a debugger.