Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
69
I can’t stop telling my friends about Forward: Escape the Fold and now I’m telling you. I bought it more than two years ago and it’s my favorite mobile game by a mile. Forward describes itself as the “perfect bitesized roguelike dungeon crawler”. You control a character trying to escape a dungeon, and there’s just one way out: keep going forward. It’s a game about making lots of small decisions as your character gets repeatedly pummeled on the path to freedom. Do I attack this monster and hope it gives me treasure, or do I walk through a poison cloud to get a better position? Do I take the weaker powerup that will help me now, or the one that might later turn me unstoppable if I’m lucky? Over time, you develop an intuition for the best moves to make, but every run is still a challenge. The game is easy to pick up, the sessions are the perfect duration, and the controls are satisfying on a touchscreen. All of that adds up to a perfect mobile game. The game’s vibe is another standout....
4 months ago

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from Evan Hahn's blog

Things I wish I knew about Ring Fit Adventure

I’ve played a lot of Ring Fit Adventure, the fitness game for Nintendo Switch. Here are some things I wish I knew when I got started. Jump over battles to skip them You can jump over enemies to avoid fighting them! I first discovered this when watching a speedrun of the game. If you see some enemies in a level, you can use your (double) jump to avoid the battle completely. This is useful if you want to get to the end of a level faster, or if you don’t want to stop running. Sometimes this is a little tricky and I miss, and I believe some fights can’t be skipped. And skipping too many fights seems to defeat the purpose of the game! Jiggle the Ring-Con to delay an exercise Ring Fit typically waits for you to be in position for about three seconds before it starts an exercise, but sometimes it guesses wrong and starts before you’re ready! To avoid this, I jiggle the Ring-Con. That way, the game doesn’t think I’m standing still ready for the excercise. Remove the leg strap during static stretching Ring Fit will usually complain if you remove the leg strap, but it won’t during some moments, such as the final stretch. I like doing this because (1) it’s a bit more comfortable (2) it lets me put it away sooner, saving me a little bit of time. Use “double money” and “double EXP” smoothies effectively There are smoothies that double your EXP or double your money from a battle. I save these for fights with rare or gold Hoplins, because those give you a boatload of rewards which you can double. Don’t try learning a new language I’ve been trying to improve my Spanish. I tried changing the game’s voice language to Spanish for practice, and didn’t like it. First, the game is not designed to teach you a second language. Most of the words are uncommon. You’re probably not going to be saying “overhead hip shake” very often in real life. Second, it’s bad if you miss something! You could miss some important advice and injure yourself. I kept the voice language as English. “Uno, dos”? Speaking of Spanish, I want to clear up confusion I had. Some exercises have you alternate between two positions: 1-2, 1-2, 1-2. Sometimes the English voice will say—in Spanish—"uno, dos, uno, dos". It took me a long time to understand what they were saying! I thought they were spouting nonsense words for a long time. Maybe this is obvious to everyone else, but it wasn’t to me. New Game Plus The last thing I’ll say without spoiling anything: there is a “New Game Plus”. You’ll have to beat the game to see what it entails! Overall, I like Ring Fit Adventure, and I’m glad it’s reasonably compatible with the Nintendo Switch 2 coming out later this year. I hope to keep playing it for a long time!

2 months ago 10 votes
Notes from April 2025

A roundup of my notes from April. I’ve done this for the last few months: March February January Things I published I published a small UI tip about rounding percentages. In short, I don’t think you should show “100%” to the user unless it’s truly done, or “0%” unless it truly hasn’t started. Though this is a bit of a lie, I think it’s clearer to users. I posted clippings from Life in Code: A Personal History of Technology, a book of essays by Ellen Ullman. The book criticizes Silicon Valley (where I was born and raised!) and the modern tech scene. Yet Ullman seems to retain hope that these tools can be part of a better world. Perhaps I’m projecting, because that’s basically how I feel. I read the Economist’s style guide book and published my main takeaways. I think my writing is better after reading! Not something I published, but I was featured on DWeb’s social media and they chose a truly dreadful photo of me. Also, an old post of mine was featured on Remember The Milk’s blog. Things I wrote for Zelda Dungeon This was my first full month writing for Zelda Dungeon, and I published four articles. The month was defined by the announcement of the Switch 2, which is most of what I wrote about: “Improved Pro Controller Announced for Switch 2” “Echoes of Wisdom, Link’s Awakening, & Other Select Switch Games to Receive Free Updates to ‘Improve Playability’ on Switch 2” “Daily Debate: What Did You Think of Today’s Nintendo Switch 2 Direct?” I also published some thoughts about subtle references between Zelda games, which is one of my favorite parts of the series. Tech news I read It’s still bleak out there! Last month, I wrote about small players getting hurt by AI scraping bots. Big organizations like Wikimedia are affected, too. American tech companies build software that kills innocent civilians. Microsoft fired an employee who protested this. Relatedly, an indie dev pulled their game from Microsoft’s Xbox in protest. In case you didn’t know whether the US Immigration and Customs Enforcement agency (ICE) was evil, its director wants it to function “like [Amazon] Prime, but with human beings”. That’s something a cartoon villain would say. Seems like Google Chrome is keeping third-party cookies after all. Third-party cookies are bad for privacy, so I was sad to see this. “If Bitcoin were—as true believers often say—a government-free currency, Donald Trump’s idiot tariffs should have strengthened it.” That’s not what happened. Aftermath posted their “official Editorial Values”. Cool to see these spelled out explicitly, and I wish more publications did this. Links, links, and more links A roundup of links from April: I think ads are poisonous to society, so I loved “What If We Made Advertising Illegal?”. I think the author’s goal is to shift the Overton window, rather than realistically propose a ban. (A near-ban is proposed in Digital Degrowth, a pretty radical book I read this month, which further fueled my fire.) “AI ambivalence” and “Why I stopped using AI code editors” buck against the trend of loving AI for coding. My favorite quote: “I acknowledge that these tools are incredibly powerful, I’ve even started incorporating them into my work in certain limited ways […], but I absolutely hate them.” “Good Intentions Don’t Pave Roads: The Need For a New Strategy in Free-Software” argues that the free software movement needs to change its approach, because it’s losing. Soft Skills episode 454 had a great quote about measuring developer productivity: “many teams have killed the ability to do capacity planning by using story points as a performance metric.” “Is ’ethical AI’ an oxymoron?” asks some ethical questions about generative AI. Refreshingly, it also gives some answers. “It hurts me to know that the tools I share such a deep connection with are made by corporations that exploit workers in developing countries, greenwash their products while generating tons of electronic waste, fight against the rights of people to repair their possessions, engage in malicious compliance when governments try to regulate them, spy on their users, hold their users’ data hostage, and commit a long list of other crimes that would take too long to recount here.” Quotes like this and more in “The tools I love are made by awful people”. SELF is a platformer game. It’s short—maybe only 15 minutes—but left me wanting more. I think it’s the best-feeling 2D platformer I’ve ever played! I found it on Itch.io’s “randomizer”, a feature that shuffles you through different games to try. “Two Years of Rust” was good enough for me to personally email a thank-you to the author. I want more high-level descriptions of really using a tool. I want to know what it feels like to be proficient, and know what the pain points are. This post did exactly that! I learned about asarotos oikos, an ancient Roman mosaic style that looks like there’s a bunch of garbage on the floor. Hope you had a good April.

2 months ago 9 votes
UI tip: maybe don't round percentages to 0% or 100%

In short: maybe don’t round to 0% or 100% in your UI. I am not a UI expert. But I sometimes build user interfaces, and I sometimes want to render a percentage to the user. For example, something like “you’ve downloaded 45% of this file”. In my experience, it’s often better to round this number but avoid rounding to 0% or 100%. Rounding to 0% is bad because the user may think there’s been no progress. Even the smallest nonzero ratio, like 0.00001%, should render as 1%. Rounding to 100% is bad because the user may think things are done when they aren’t, and it’s better to show 99%. Ratios like 99.9% should still render as 99%, even if they technically round to 100%. For example, in your UI: Ratio (out of 1) Rendered 0 0% 0.00001 1% 0.01 1% 0.02 2% 0.99 99% 0.99999 99% 1 100% Here’s some Python code that demonstrates the algorithm I like to use: def render_ratio(ratio): if ratio <= 0: return "0%" if ratio >= 1: return "100%" if ratio <= 0.01: return "1%" if ratio >= 0.99: return "99%" return f"{round(ratio * 100)}%" This isn’t right for all apps, of course. Sometimes you want to show the exact percentage to the user, and sometimes you don’t want the app to appear “stuck” at 1% or 99%. But I’ve found this little trick to be useful.

2 months ago 23 votes
Takeaways from The Economist's style guide book

I’ve been trying to improve my writing so I read Writing with Style, the Economist’s style guide book. Here were my main takeaways: Use short sentences. They’re more memorable. They’re easier to read. They’re generally easier to write. Colons are for setup and delivery. They describe them as “dramatic”. One thought per paragraph. The paragraph is a “unit of thought”, according to this book and to H.W. Fowler. Sometimes, you have a one-sentence paragraph because the thought fits into a single sentence. Prefer simpler terms. Use “get” instead of “obtain”, “make” instead of “manufacture”, or “give up” instead of “relinquish”. Ask if you ever use the word when talking to friends. And don’t soften difficult topics: “a poor person has no more money, opportunity or dignity when described as ‘deprived’, ‘disadvantaged’ or ‘underprivileged’.” The right word can eliminate others. More specific words let you “dispense with adjectives and adverbs entirely. Consider the difference between ‘walk’ and ‘strut’, or ‘say’ and ‘murmur’.” Find big-picture issues with a “reverse outline”. When editing, they recommend extracting the main point from each paragraph. This can catch structural issues. Watch out for differences between English dialects. I knew about a lot of these, like how I’d spell it “color” and a Brit would spell it “colour”. But I didn’t know about “quite”: in American English, it’s a synonym for “very”; in British English, it can mean “fairly”. (The book failed to mention other dialects of English, to my disappointment.) There were things I didn’t like about the book. It seemed allergic to whimsy. A lot of its rules felt arbitrary. The Economist writes for a different audience than I do. But these disagreements helped me clarify my own writing style, so they were still helpful. I think my writing is better as a result of this book. I recommend checking it out!

2 months ago 15 votes
Notes from "Life in Code: A Personal History of Technology"

Life in Code: A Personal History of Technology is a book of essays by Ellen Ullman. In the book, Ullman laments the bad parts of computers and the internet. These systems eroded privacy, deepened income inequality, and enabled the rise of modern fascism. And they were built by a tiny subset of people—young men, mostly white and Asian, mostly wealthy—to the exclusion of almost everyone else. Despite all this, she maintains a hopeful fascination with technology. Perhaps humanity can use these tools as part of a better world. I share this sentiment, I think. Many of the stories are old by Silicon Valley standards, but they feel prescient. The book is filled with ideas that could be written today, if you modernized a few incidental details. These are my notes and quotes from the book. “Outside of Time” (1994) Ullman on the idea that low-level development is more respected: “If you want money and prestige, you need to write code that only machines or other programmers understand.” Oh, and these prestigious and lucrative jobs are primarily held by young men. And these boys impart their ideas into the systems they build: As the computer’s pretty, helpfully waiting face […] penetrates deeply into daily life, the cult of the boy engineer comes with it. The engineer’s assumptions and presumptions are in the code. “Come in, CQ” (1996) Learned about The WELL, an online community that’s been around since 1985. I also learned that the elm email client was succeed by Pine, another tree name. Pine was then succeeded by Alpine, another piece of wordplay. Quips like this resonate with me: I do believe that the operational definition of a thing—how it works—is its most eloquent self-expression. A lot of user interfaces seem to encourage immediate action: Although we seemed to be delaying, prolonging the time of imagination, the email was only rushing us. I read a message. The prompt then sat there, the cursor blinking. It was waiting for me to type “r” for “reply.” The whole system is designed for it, is pressing me, is pulsing, insisting: Reply. Reply right now. Even though I meant to hold the message awhile, even though I wanted to treat it as if it were indeed a “letter”—something to hold in my hand, read again, mull over—I cannot resist the voice of the software, which was murmuring, murmuring: Go ahead. You know you want to. Reply right now. A poignant paragraph about the demise of Morse code: The [Morse] code had a personality to it, a signature in the touch and rhythm on the key. For Turner, the signature’s origin was no mystery: “It’s coming from a person’s hand.” Makes me think about the things you trade for convenience, and the information that’s lost when you measure. “The Dumbing Down of Programming” (1998) This essay was originally published in Salon. I learned what “BIOS” stands for: Basic Input/Output System. Never thought about it before! To anyone who laments the messy design of modern terminals: […] we build our computers the way we build our cities—over time, without a plan, on top of ruins. This was written in 1998 and sounds similar to modern opinions about LLMs: My programming tools were full of wizards. Little dialogue boxes waiting for me to click “Next” and “Next” and “Finish.” Click and drag, and—shazzam—thousands of lines of working code. No need to get into the “hassle” of remembering the language. No need even to learn it. It is a powerful siren-song lure: You can make your program do all these wonderful and complicated things, and you don’t really need to understand. […] This not-knowing is a seduction. I feel myself drifting up, away from the core of what I’ve known programming to be: text that talks to the system and its other software, talk that depends upon knowing the system as deeply as possible. What a sweet temptation it is to succumb: Wizard, dazzle me. Ullman explains the risks of these systems. When something inevitably goes wrong, you may be powerless to debug it. I liked this bit which acknowledged the tradeoffs engineers have to make: We were reminded that software engineering was not about right and wrong but only better and worse, solutions that solved some problems while ignoring or exacerbating others. “What We Were Afraid of As We Feared Y2K” (1999—2000) This essay was heavily adapted from a 1999 Wired article. This essay made me think I should read an entire book about the history of Y2K. (If you know of a good one, let me know.) “The Museum of Me” (1998) Related to an earlier point about the developers encoding their worldview into the software they build: I have long believed that the ideas embedded in technology have a way of percolating up and outward into the nontechnical world at large, and that technology is made by people with intentions and, as such, is not neutral. The author talks about how the Internet glorified self-service, and only the very rich could afford human help. Here’s one of those prescient passages. Remember that this was written 27 years ago: But now, without leaving home, from the comfort of your easy chair, you can divorce yourself from the consensus on what constitutes “truth.” Each person can live in a private thought bubble, reading only those websites that reinforce his or her desired beliefs, joining only those online groups that give sustenance when the believer’s courage flags. “Fiber Optic Nights” (1999) You might be skeptical of the tech world. But when you’re surrounded by the techno-optimism of Silicon Valley, it’s hard to resist: At this stage of inebriation, I can’t resist the atmosphere of wild optimism. I let myself fall under the delicious cloud of dreams: the great global internet that will change human life—indeed, change humans themselves. Ullman laments how San Francisco’s diversity made way for tech startups, a “colonization” I noticed myself when I lived there. She expands on this much more in the final essay. And another sentence talking about how engineers only value “hard” engineering: Any serious software engineer would scoff at my dragging in philosophy, the fuzz of the humanities. “Off the High” (2000) Sad that this is still true 25 years later: Maybe what has put the damper on this year’s conference is that, after the Canadians pass their law, the United States will be the sole nation in the highly industrialized world without legal data-protections. Or maybe it’s the fact of being in Canada, where everyone who is an American knows that, on crossing back into the United States, they will lose their constitutional right not to be subjected to unreasonable searches. “Programming the Post-Human” (2002) This essay originally appeared in Harper’s Magazine in a slightly different form. Comparing Moore’s Law to software development: […] there is no Moore’s Law for software. On the contrary, as systems increase in complexity, it becomes harder—very much harder—to write reliable code. This essay is mostly about AI, and what it means to be alive and conscious. I think this quote succinctly sums up the whole thing: The more I thought about it, the more I decided that huge swaths of existence would be impenetrable—indescribable, un-programmable, utterly unable to be represented—to a creature that did not eat or shit. “Dining with Robots” (2004) Ullman rejects the often-used comparison that programming is like a recipe. Could a computer understand many of the subtle, and perhaps ancillary, parts of cooking? (To be fair, I’m a bad cook, so I probably can’t either.) The world resists the rigidity of software: The world, the actual world we inhabit, showed itself to be too marvelously varied, too ragged, too linked and interconnected, to be sorted into any set of frames or classes or problem spaces. Reminds me of a point repeatedly made in Beyond Measure, another book I took notes on. Computers are described as “fast, efficient, untiring, correct, standardized, organized”. “Close to the Mainframe” (2014) Ullman describes the intoxicating feeling of being sucked in by a tricky bug. This is one of the sweetest parts of computer programming! The Party Line (2015) Ullman talks about a small farm being affected by technological “efficiency”. This farm needed to start putting their milk in something called a bulk tank, or be left behind. Technology promises efficiency, but it also messes things up: Bulk-tank collection was surely more efficient [than] picking up individual cans. Consumers might benefit from the lower costs of production. It was technology at what it does best: standardize and homogenize and monetize, create efficiencies in sales and markets and distribution chains. It was also technology at its worst. The coming of the bulk tank was another of those ruptures in society. Yet this one did not widen the scope of individual freedoms. The tank would effectively drive the small family dairy farm out of existence. Programming for the Millions (2016) Ullman describes a programmer’s job as that of a “translator”. That’s sometimes how it feels! It reminds me of “meeting the computer halfway”. I liked this bit about breaking down the divide between humanities and software: I dare to imagine the general public learning how to write code. I do not mean that knowledge of programming should be elevated to the ranks of the other subjects that form basic literacy: languages, literature, history, psychology, sociology, economics, the basics of science and mathematics. I mean it the other way around. What I hope is that those with knowledge of the humanities will break into the closed society where code gets written: invade it. Boom Two: A Farewell (January 2017) The final essay really laments how San Francisco has changed. This quote sums it up best: The startup culture has overtaken San Francisco. It was once a place for kids running away from home, where people in their teens and early twenties came to get away from the lives they were supposed to lead but didn’t want to, to be gay or bisexual or other combinations of sexuality, all looking for some version of the old, wild, open San Francisco: the Beats, hippies, free love, the gay revolution. Yet nothing abides forever, and now we live in a city whose former identities, however mythical, have been swept away. A new wave of youthful seekers has come a-searching for yet another mythical San Francisco: a place where dreams of founding a successful internet startup are born, and fulfilled. There’s also a short passage about someone pitching their tech as being easy-to-use, using a phrase like “Even Grandma can use it.” Ullman (rightly) calls this out as sexist and ageist. I used to say stuff like this and am embarrassed by that! I’ll end with a quote about tech saviorism: How far away was and is the true work of creating a more egalitarian world, the slow, hard job of organizing, the hours of contentious community meetings: the clash of need against need. Only those who work close to that ground, and take the code into their own hands, can tell us what technology is good for.

2 months ago 16 votes

More in technology

This automatic emergency braking system protects RC cars

It is a story as old as time (or at least the 1960s): kid gets an RC car for Christmas and excitedly takes it for spin, but crashes it into a wall within five minutes and tears ensue. The automotive industry has cut down on accidents by implementing automatic emergency braking safety features, so why […] The post This automatic emergency braking system protects RC cars appeared first on Arduino Blog.

18 hours ago 2 votes
Comics from Winter 1980 Issue of Electronics Today International

AI and everything in between.

2 hours ago 1 votes
This unique electronic toy helps children learn their shapes

It isn’t a secret that many kids find math to be boring and it is easy for them to develop an attitude of “when am I ever going to use this?” But math is incredibly useful in the real world, from blue-collar machinists using trigonometry to quantum physicists unveiling the secrets of our universe through […] The post This unique electronic toy helps children learn their shapes appeared first on Arduino Blog.

3 days ago 5 votes
From building ships to shipping builds: how to succeed in making a career switch to software development

I have worked with a few software developers who made the switch to this industry in the middle of their careers. A major change like that can be scary and raise a lot of fears and doubts, but I can attest that this can work out well with the right personality traits and a supporting environment. Here’s what I’ve observed. To keep the writing concise, I’ll be using the phrase “senior junior”1 to describe those that have made such a career switch. Overcoming the fear Fear is a natural reaction to any major change in life, especially when there’s risk of taking a financial hit while you have a family to support and a home loan to pay. The best mitigation that I’ve heard is believing that you can make the change, successfully. It sounds like an oversimplification, sure, as all it does is that it removes a mental blocker and throws out the self-doubt. And yet it works unreasonably well. It also helps if you have at least some savings to help mitigate the financial risk. A years’ worth of expenses saved up can go a long way in providing a solid safety net. What makes them succeed A great software developer is not someone that simply slings some code over the wall and spends all of their day working only on the technical stuff, there are quite a few critical skills that one needs to succeed. This is not an exhaustive list, but I’ve personally observed that the following ones are the most critical: ability to work in a team great communication skills conflict resolution ability to make decisions in the context of product development and business goals maintaining an environment of psychological safety Those with more than a decade of experience in another role or industry will most likely have a lot of these skills covered already, and they can bring that skill set into a software development team while working with the team to build their technical skill set. Software development is not special, at the end of they day, you’re still interacting with humans and everything that comes with that, good or bad. After working with juniors that are fresh out of school and “senior juniors” who have more career experience than I do, I have concluded that the ones that end up being great software developers have one thing in common: the passion and drive to learn everything about the role and the work we do. One highlight that I often like to share in discussions is one software developer who used to work in manufacturing. At some point they got interested in learning how they can use software to make work more efficient. They started with an MVP solution involving a big TV and Google Sheets, then they started learning about web development for a solution in a different area of the business, and ended up building a basic inventory system for the warehouse. After 2-3 years of self-learning outside of work hours and deploying to production in the most literal sense, they ended up joining my team. They got up to speed very quickly and ended up being a very valuable contributor in the team. In another example, I have worked with someone who previously held a position as a technical draftsman and 3D designer in a ship building factory (professionals call it a shipyard), but after some twists and turns ended up at a course for those interested in making a career switch, which led to them eventually working in the same company I do. Now they ship builds with confidence while making sure that the critical system we are working on stays stable. That developer also kicks my ass in foosball about 99% of the time. The domain knowledge advantage The combination of industry experience and software development skills is an incredibly powerful one. When a software developer starts work in a project, they learn the business domain piece by piece, eventually reaching a state where they have a slight idea about how the business operates, but never the full picture. Speaking with their end users will help come a long way, but there are always some details that get lost in that process. Someone coming from the industry will have in-depth knowledge about the business, how it operates, where the money comes from, what are the main pain points and where are the opportunities for automation. They will know what problems need solving, and the basic technical know-how on how to try solving them. Like a product owner, but on steroids. Software developers often fall into the trap of creating a startup to scratch that itch they have for building new things, or trying out technologies that have for a very long time been on their to-do list. The technical problems are fun to solve, sure, but the focus should be on the actual problem that needs fixing. If I wanted to start a new startup with someone, I’d look for someone working in an industry that I’m interested in and who understands the software development basics. Or maybe I’m just looking for an excellent product owner. How to help them succeed If you have a “senior junior” software developer on your team, then there really isn’t anything special you’d need to do compared to any other new joiner. Do your best to foster a culture of psychological safety, have regular 1-1s with them, and make sure to pair them up with more experienced team members as often as possible. A little bit of encouragement in challenging environments or periods of self-doubt can also go a long way. Temporary setbacks are temporary, after all. What about “AI”? Don’t worry about all that “AI”2 hype, if it was as successful in replacing all software development jobs as a lof of people like to shout from the rooftops, then it would have already done so. At best, it’s a slight productivity boost3 at the cost of a huge negative impact on the environment. Closing thoughts If you’re someone that has thought about working as a software developer or who is simply excited about all the ways that software can be used to solve actual business problems and build something from nothing, then I definitely recommend giving it a go, assuming that you have the safety net and risk appetite to do so. For reference, my journey towards software development looked like this, plus a few stints of working as a newspaper seller or a grocery store worker. who do you call a “senior senior” developer, a senile developer? ↩︎ spicy autocomplete engines (also known as LLM-s) do not count as actual artificial intelligence. ↩︎ what fascinates me about all the arguments around “AI” (LLM-s) is the feeling of being more productive. But how do you actually measure developer productivity, and do you account for possible reduced velocity later on when you’ve mistaken code generation speed as velocity and introduced hard to catch bugs into the code base that need to be resolved when they inevitably become an issue? ↩︎

3 days ago 8 votes
A slept on upscaling tool for macOS

I uploaded YouTube videos from time to time, and a fun comment I often get is “Whoa, this is in 8K!”. Even better, I’ve had comments from the like, seven people with 8K TVs that the video looks awesome on their TV. And you guessed it, I don’t record my videos in 8K! I record them in 4K and upscale them to 8K after the fact. There’s no shortage of AI video upscaling tools today, but they’re of varying quality, and some are great but quite expensive. The legendary Finn Voorhees created a really cool too though, called fx-upscale, that smartly leverages Apple’s built-in MetalFX framework. For the unfamiliar, this library is an extensive of Apple’s Metal graphics library, and adds functionality similar to NVIDIA’s DLSS where it intelligently upscales video using machine learning (AI), so rather than just stretching an image, it uses a model to try to infer what the frame would look like at a higher resolution. It’s primarily geared toward video game use, but Finn’s library shows it does an excellent job for video too. I think this is a really killer utility, and use it for all my videos. I even have a license for Topaz Video AI, which arguably works better, but takes an order of magnitude longer. For instance my recent 38 minute, 4K video took about an hour to render to 8K via fx-upscale on my M1 Pro MacBook Pro, but would take over 24 hours with Topaz Video AI. # Install with homebrew brew install finnvoor/tools/fx-upscale # Outputs a file named my-video Upscaled.mov fx-upscale my-video.mov --width 7680 --codec h265 Anyway, just wanted to give a tip toward a really cool tool! Finn’s even got a [version in the Mac App Store called Unsqueeze](https://apps.apple.com/ca/app/unsqueeze/id6475134617 Unsqueeze) with an actual GUI that’s even easier to use, but I really like the command line version because you get a bit more control over the output. 8K is kinda overkill for most use cases, so to be clear you can go from like, 1080p to 4K as well if you’re so inclined. I just really like 8K for the future proofing of it all, in however many years when 8K TVs are more common I’ll be able to have some of my videos already able to take advantage of that. And it takes long enough to upscale that I’d be surprised to see TVs or YouTube offering that upscaling natively in a way that looks as good given the amount of compute required currently. Obviously very zoomed in to show the difference easier If you ask me, for indie creators, even when 8K displays are more common, the future of recording still probably won’t be in native 8K. 4K recording gives so much detail still that have more than enough details to allow AI to do a compelling upscale to 8K. I think for my next camera I’m going to aim for recording in 6K (so I can still reframe in post), and then continue to output the final result in 4K to be AI upscaled. I’m coming for you, Lumix S1ii.

4 days ago 9 votes