Very nice. The minimal permissions are especially welcome for me.

I presume that you have at least some vague idea of what you want your program to do. If not, maybe a good random writing prompt generator can help.

But if you do have something in mind, I usually start by thinking about how I'm going to store my data. That goes hand-in-hand with thinking about how to break up the top-level tasks into individual functions and sub-functions. Those two processes tend to feed into each other, and before I'm aware of it, I've got a basic framework hammered out, at least in my notes.

I would also probably try to plug USB drives in once a year or so if I were being diligent, but in reality I recently found a handful of USB flash drives that I'd stored in a box in my parents' unattached garage, and every one of them could be read completely without any issues. They ran the gamut of build quality from expensive, name-brand drives to no-name dollar-store keychains. They'd been sitting in that box, untouched, for a little over nine years, and I'm pretty sure that some of them hadn't been used for several years even before that.

I wouldn't rely on it for critical data, but USB flash might not be so terrible.

Go for it, if it's to satisfy your own curiosity, but there's virtually no practical use for it these days. I had a personal interest in it at uni, and a project involving coding in assembly for an imaginary processor was a small part of one optional CS course. Over the years I've dabbled with asm for 32-bit Intel PCs and various retro consoles; at the moment I'm writing something for the Atari 2600.

In the past, assembly was useful for squeezing performance out of low-powered and embedded systems, but now that "embedded" includes SoCs with clock speeds in the hundreds of MHz and several megabytes of RAM, and optimizing compilers have improved greatly, the tiny potential performance gain (and you have to be very good at it before you'll be able to match or do better than most optimizing compilers) is almost always outweighed by the overhead of hand-writing and maintaining assembly language.

I'm in a similar boat to you. I ripped almost all of my CDs to 320kbps mp3s for portability, but then I wanted to put all of them (a substantial number) plus a bunch more (my partner's collection) on a physically tiny USB stick (that I already had) to just leave plugged into our car stereo's spare port. I had to shrink the files somehow to make them all fit, so I used ffmpeg and a little bash file logic to keep the files as mp3s, but reduce the bitrate.

128kbps mp3 is passable for most music, which is why the commercial industry focused on it in the early days. However, if your music has much "dirty" sound in it, like loud drums and cymbals or overdriven electric guitars, 128kbps tends to alias them somewhat and make them sound weird. If you stick to mp3 I'd recommend at least 160kbps, or better, 192kbps. If you can use variable bit rate, that can be even better.

Of course, even 320kbps mp3 isn't going to satisfy audiophiles, but it sounds like you just want to have all your music with you at all times as a better alternative to radio, and your storage space is limited, similar to me.

As regards transcoding, you may run into some aliasing issues if you try to switch from one codec to another without also dropping a considerable amount of detail. But unless I've misunderstood how most lossy audio compression works, taking an mp3 from a higher to a lower bitrate isn't transcoding, and should give you the same result as encoding the original lossless source at the lower bitrate. Psychoacoustic models split a sound source into thousands of tiny component sounds, and keep only the top X "most important" components. If you later reduce that to the top Y most important components by reducing the bitrate (while using the same codec), shouldn't that be the same as just taking the top Y most important components from the original, full group?

My main concern is getting games in a form that I can store locally for 20 years and then reasonably expect to boot up and play. A secondary concern (ever since I moved permanently to another country) is going digital whenever possible because shipping stuff long distances is expensive. I had hundreds of physical books that it pained me to give away, but it simply wasn't economical to move them to my new home. I kept my physical games, CDs, and DVDs, because they're mostly thin discs and air-filled plastic cases (often replaceable once paper inserts have been removed) and I was able to bring them over affordably.

Over the last few years I'd say I've slowed down on physical retro collecting and only bought a couple dozen retro console games. More often I sail the high seas looking for them because morally there's no sane argument decades after release that paying $50-100 to a private collector or dealer today has any impact on the developer's or publisher's profits in terms of secondary or tertiary sales. The physical game media and packaging have ceased to be games and have become artifacts, almost independent of their content, like other vintage or antique items. Of course that doesn't apply if the game has been rereleased in more or less its original form, in which case I either buy it (if the price is reasonable) or don't play it at all (if the price is unreasonable). I actually have such a game in digital storage that I've been meaning to play for years, and I learned that it's quite recently been put up in GOG, so now I'm morally obligated to buy it if I still want to play it, heh. Luckily for me the price seems fair.

And speaking of GOG, the majority of my recent game purchases have been split pretty evenly between GOG and itch.io; about 95%. I basically haven't bought anything directly from Steam for more than a decade. I understand that many games there are actually DRM-free, but I'm not interested in trying to research every game before I make a purchase. If each game's store page indicated its true DRM status clearly (not just "third-party DRM"), I'd consider buying through Steam again. As it is, whenever I learn about an interesting game that's on Steam, I try to find it on itch.io or GOG, and if I can't, I generally don't buy it; I'll buy it on Steam only if it looks really interesting and it's dirt cheap.

Whenever I look at buying "leasing with no fixed term" anything with DRM, I assume that it will be taken away from me or otherwise rendered unusable unexpectedly at some point in the future through no fault of my own. It's already happened to me a couple of times, and once bitten, twice shy. I know that everyone loves Gabe Newell, and he seems like a genuinely good guy, and he's said that if Steam ever closed its doors that they'd unlock everything. However the simple fact is that in the majority of situations where that might happen, the call wouldn't be up to Gaben, even for games published by Valve.

So yeah, I may put up with DRM in a completely offline context, but in any situation where my access terms can be changed remotely and unilaterally with a forced update, server shutdown, or removal, that's a hard pass from me.

Gain Ground and Arcus Odyssey both got many hours of play on my Mega Drive back in the day. :)

I'm not too knowledgeable about the detailed workings of the latest hardware and APIs, but I'll outline a bit of history that may make things easier to absorb.

Back In the early 1980s, IBM was still setting the base designs and interfaces for PCs. The last video card they relased which was an accepted standard was VGA. It was a standard because no matter whether the system your software was running on had an original IBM VGA card or a clone, you knew that calling interrupt X with parameters Y and Z would have the same result. You knew that in 320x200 mode (you knew that there would be a 320x200 mode) you could write to the display buffer at memory location ABC, and that what you wrote needed to be bytes that indexed a colour table at another fixed address in the memory space, and that the ordering of pixels in memory was left-to-right, then top-to-bottom. It was all very direct, without any middleware or software APIs.

But IBM dragged their feet over releasing a new video card to replace VGA. They believed that VGA still had plenty of life in it. The clone manufacturers started adding little extras to their VGA clones. More resolutions, extra hardware backbuffers, extended palettes, and the like. Eventually the clone manufacturers got sick of waiting and started releasing what became known as "Super VGA" cards. They were backwards compatible with VGA BIOS interrupts and data structures, but offered even further enhancements over VGA.

The problem for software support was that it was a bit of a wild west in terms of interfaces. The market quickly solidified around a handful of "standard" SVGA resolutions and colour depths, but under the hood every card had quite different programming interfaces, even between different cards from the same manufacturer. For a while, programmers figured out tricky ways to detect which card a user had installed, and/or let the user select their card in an ANSI text-based setup utility.

Eventually, VESA standards were created, and various libraries and drivers were produced that took a lot of this load off the shoulders of application and game programmers. We could make a standardised call to the VESA library, and it would have (virtually) every video card perform the same action (if possible, or return an error code if not). The VESA libraries could also tell us where and in what format the card expected to receive its writes, so we could keep most of the speed of direct access. This was mostly still in MS-DOS, although Windows also had video drivers (for its own use, not exposed to third-party software) at the time.

Fast-forward to the introduction of hardware 3D acceleration into consumer PCs. This was after the release of Windows 95 (sorry, I'm going to be PC-centric here, but 1: it's what I know, and 2: I doubt that Apple was driving much of this as they have always had proprietary systems), and using software drivers to support most hardware had become the norm. Naturally, the 3D accelerators used drivers as well, but we were nearly back to that SVGA wild west again; almost every hardware manufacturer was trying to introduce their own driver API as "the standard" for 3D graphics on PC, naturally favouring their own hardware's design. On the actual cards, data still had to be written to specific addresses in specific formats, but the manufacturers had recognized the need for a software abstraction layer.

OpenGL on PC evolved from an effort to create a unified API for professional graphics workstations. PC hardware manufacturers eventually settled on OpenGL as a standard which their drivers would support. At around the same time, Microsoft had seen the writing on the wall with regards to games in Windows (they sucked), and had started working on the "WinG" graphics API back in Windows.3.1, and after a time that became DirectX. Originally, DirectX only supported 2D video operations, but Microsoft worked with hardware manufacturers to add 3D acceleration support.

So we still had a bunch of different hardware designs, but they still had a lot of fundamental similarities. That allowed for a standard API that could easily translate for all of them. And this is how the hardware and APIs have continued to evolve hand-in-hand. From fixed pipelines in early OpenGL/DirectX, to less-dedicated hardware units in later versions, to the extremely generalized parallel hardware that caused the introduction of Vulkan, Metal, and the latest DirectX versions.

To sum up, all of these graphics APIs represent a standard "language" for software to use when talking to graphics drivers, which then translate those API calls into the correctly-formatted writes and reads that actually make the graphics hardware jump. That's why we sometimes have issues when a manufacturer's drivers don't implement the API correctly, or the API specification turns out to have a point which isn't defined clearly enough and some drivers interpret it one way, while other drivers interpret the same API call slightly differently.

In my (admittedly limited) experience, SDL/SDL2 is more of a general-purpose library for dealing with different operating systems, not for abstracting graphics APIs. While it does include a graphics abstraction layer for doing simple 2D graphics, many people use it to have the OS set up a window, process, and whatever other housekeeping is needed, and instantiate and attach a graphics surface to that window. Then they communicate with that graphics surface directly, using the appropriate graphics API rather than SDL. I've done it with OpenGL, but my impression is that using Vulkan is very similar.

SDL_gui appears to sit on top of SDL/SDL2's 2D graphics abstraction to draw custom interactive UI elements. I presume it also grabs input through SDL and runs the whole show, just outputting a queue of events for your program to process.

I'm a bit confused about this story synopsis, to be honest. How much does the home video game crash of 1983 have to do with video game arcades?

I'll admit that I was still very young at the time, and wasn't living in the USA. I had no idea about the crash until decades later when I read about it as a historical event. Looking back I can recall that console games in my country were a bit thin on the ground for two or three years, but home computers (the 8-bit and 16-bit kinds, not PC/Mac) and arcades kept going strong.

Video game arcades and random video games tucked into corners of takeaway shops and shopping malls were still a common thing for me well into the 1990s. They only really started dying out rapidly in the 2000s due to increasing competition from home systems and computers (this time it was PC/Mac) in terms of power and networking, along with the rise of Internet-connected feature phones and then smartphones, which gave many people an ever-present source of time-killing entertainment in their pocket.

Dedicated arcades with big cabinet games involving custom controllers or displays, or other special features hung on for a while, but those machines rarely appeared anywhere else, and in the end even most of them couldn't keep drawing enough customers to remain profitable.

At the very least, please state which section you made small changes to, even if you are sure it's not worth mentioning what or why.

Maybe they believe that most of their customers don't really know much about computers beyond turning them on and "bigger numbers = better". They might not be wrong.