You reminded me of a story I recently read, where the author highlighted just how much awesome programming someone had done by describing how their hands were cramping up.

It's like estimating how well an artist paints by looking at how much paint is on their clothes, or judging how good a cook is by how many cuts and burns they have. The actions that cause those things are incidental to the process, not central, and an excessive amount points to incompetence, not hard and skillful work.

I use Linux on hardware older and less capable than yours, and usually the only real show-stopper I find is a lack of Vulkan support. I don't use any nVidia hardware, but my understanding is that older chips are supported decently by current Linux drivers. So I'd say you'll probably be fine.

As for ten years from now, it's uncommon for Linux software to remove features, and even if it happens, there's virtually always a way for you stay on an old version if you really need to, because there are no forced updates. If you're careful you can sometimes even keep the old versions of things for old software that needs it, while still having the latest version for software that can use it.

I've never had one myself, but a few of my friends have had Crumpler bags for years and they swear by them.

Crumpler is an Australian company started by some bicycle couriers who couldn't find really sturdy bags that suited them. I believe that the story goes that one of them was trying to carry a slab of beer (24 cans packed in one flat layer) to a friend's party when his bag broke apart, and that was when they started making bags for themselves.

They've been around since 1995, and have quite a range of bags and backpacks now.

• You want to make a technically simple game, and want it actually to be able to run on a potato instead of just looking like it should, and you already have the skills or aren't afraid to take the time to learn.

The classic adage of "The first 90% of the work takes 90% of the time, and the last 10% takes the other 90% of the time" comes to mind.

Its always all those "little touches" that eat up so much time, because you know that your audience will expect them, and you yourself feel that they should be there; a smoothly-moving cursor for menu selections, playing little sounds when selecting or cancelling, a puff of dust that jumps up when the player character lands (but keeps animating in place rather than sticking to the player), text sliding or fading in and out instead of just appearing and disappearing... All the individual "little" things that add up to quite a lot of work.

I also sympathize with you on a lot of the points you raised about "family-friendly" games. I'm a teacher, and when I make activities and games for my students, I face a similar set of constraints (must be enjoyable for the weakest students but still engaging for the most advanced students, little to no player elimination, high replayability/reusability, has to actually reinforce the target knowledge/skill and not just be fun with the material tacked on as an afterthought).

Who else remembers seeing images like this -- that would've taken a few seconds to a few minutes to render even on high-end graphics workstations of the time -- presented in gaming rags as examples of what PS1/N64/Saturn and later PS2/GameCube/DreamCast/XBox were "going to be capable of producing"?

These "home pong" consoles were very common at the time. They don't really do much, so their main value is historical interest, and this isn't a particularly famous model. A quick eBay search seems to indicate it might go for GBP 80 at most, but probably more like GBP 20-40. So OP got a good deal, but they didn't find a lost Vermeer. :)

I tried it somehow back in the day (it might've been in a store) and it was absolutely amazing. Noticeably more polygons and higher frame rate than SuperFX games. The price was crazy, though. IIRC in Australia it was close to twice the price of an average Mega Drive game (like 1.7 or 1.8 times). As a kid that was way too much for me, especially for what was (aside from the 3D graphics) a very ordinary racing game (not really my taste even in the best case).

Several years ago I picked up a copy in Japan for just 100 yen. I didn't particularly want the game per se, but knowing some of the history that OP outlined, I couldn't pass it up at that price! However, even with retro game prices shooting up in recent years, the price of Virtua Racing for MD doesn't seem to have ballooned as much as many other games, at least in Japan.

Colour me double-surprised! Not only is it available for purchase in Japan, but also the descriptions for the individual games even have full Japanese translations, right down to the system requirements!

Of course! There's already a proposal for a replacement Temporal object.

I had this and the mouse back in the day. It was an absolute blast, although I never really played it on PC so I can't compare the two. The mouse also works great on Alien Trilogy and Alien Resurrection.

I think a part of it is how we look for information in the first place. If you search/ask "How do I do (task) in (environment)?", you're going to find out about various libraries/frameworks/whatever that abstract everything away for you. But if you instead look for information on "How do I do (task)?", you'll probably get more generalized information that you can take and use to write your own stuff from scratch. Try only to look for help related to your specific environment/language when you have a specific implementation issue, like how to access a file or get user input.

We also need a willingness to learn how things actually work. I see quite a few folks who seem to be so worried that they'll never be able to understand some task that they unwittingly spend almost as much or even more time and effort learning all the ins and outs of someone else's codebase as a way to avoid what they see as the scarier unknown.

Fortunately, I've seen an increase in the last year or two of people deliberately giving answers or writing tutorials that are "no-/low-library", for people who want to know what's actually going on in their programs.

I would never say to avoid all libraries or frameworks, because many of them are well-written (small, modular, stable) and can save us a lot of boilerplate coding. But there are at least as many libraries which suffer from "kitchen-sinkism", where the authors want so much for their library to become the pre-eminent choice that it becomes a bloated tangle, trying to be all things to all people. This can be compounded by less-experienced coders including multiple huge libraries in one program, using only a fraction of each library's features without realizing that there's almost complete overlap. The cherry on top is when the end developer uses one of these libraries to do just one or two small tasks that could've been done in less than a dozen lines of standard code, if only someone had told them how, instead of sending them off to install yet another library.