I have a stupid question: Are you sure you're not confusing "line out" and "headphone out"? They're different, and pretty much every desktop supports both these days. But standard PC speakers usually connect to the "headphone" socket.

Mitchell and Webb.

"Have you noticed that our caps have actually got little pictures of skulls on them?"

When I was in my teens and twenties, I used to believe that if I thought of something that I'd never heard of before, I must have been the first person ever to come up with it.

Now that I'm older and the Internet is ubiquitous, when I have those moments I go straight to a search engine. And even if I'm not the first, I still feel pretty good about discovering whatever it is for myself.

Yeah, but Third Strike has the best version of her character design IMO.

Yeah, Zero Tolerance is amazing from a technical standpoint, and a solid gaming experience as it goes, but I personally felt it dragged on for too long without enough variation. Then again I felt about the same regarding the original Doom and Doom 2, so it's probably more my tastes than the game itself.

This is another good point. I'd try turning off Fast Startup first, and if that alone doesn't clear the issue, try this (leaving Fast Startup off).

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?

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.

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.

Maybe we could treat the appearances of recognizable, non-living entities in games (cars, buildings, airplanes, etc.) the same way we treat musical scores; the producer would be legally obligated to pay some reasonable, small, fixed fee per use to the original creator, and that creator wouldn't be allowed to object. And this wouldn't entitle the producer to use any trademarked brand or model name, just the form.

Child's play compared to what you'd need to do on a modern chip.

I don't think it's the chips, but the operating environments. Modern CPUs offer dozens of multipurpose registers and many more instructions and addressing modes compared to those old, low-cost CPUs, which should make things easier, not harder. But no-one's building old-style dedicated systems around modern CPUs; our code now has to play nice with firmware, OS, libraries, and other processes, including resource management and preempting.

Compare a single-gear go-kart to an automatic sedan. Getting top performance out of the go-kart on a closed track is difficult and requires nuance. If we could drive the automatic sedan around the same closed track, we could easily demolish the go-kart, and not just with raw engine power. The improved acceleration, braking assist, and power steering are enough. But when we drive the sedan we're usually doing it on public roads with traffic signals, intersections, speed limits, and other road users. That's what's more difficult.