There’s a whole lot of math in that article, and to be honest I’m not 100% clear on what they’re trying to say. I think they’re talking about how standard quantization isn’t making full or “accurate” use of the number space, although if you read through to the end they note that there’s really nothing terribly wrong with the standard way. But here’s my take.

To simplify, I’ll use an integer range 0-4 instead of 0-255, but the principle’s the same.

So, say that we’re quantizing from a floating-point range of 0.0-1.0 to an integer range of 0-4. Doing things the usual way, that’d be the orange numbers on the bottom of this diagram:

But you can see that this doesn’t line up cleanly with a nice, regular division of the range into 5 equal blocks. If we just multiply by 4 (our integer max) and then round off to the nearest integer, the original value ranges represented by our integer 0 and 4 are half the size of the others. E.g. 0.0 to 0.49 become 0, but 0.5 to 1.49 become 1.

Now, if we want to represent true 0.0 and 1.0 simply with our integer range (0-4), we should use 0 to exactly equal 0.0, and 4 to exactly equal 1.0. And converting from integer to float by calculating [value / 4] (or [value / 255] in reality) will get us exactly that. I wouldn’t change that.

What I would suggest changing–to anyone who cares enough about it–is how the numbers are converted from float to integer. If you look at the diagram again, you can see that there is one orange integer per evenly-divided block, even if they don’t line up with the centers of the blocks. If we take a float (0.0-1.0) representation and multiply it by our integer max plus one, we’ll get the blue numbers at the top of the diagram. Then all we have to do is round down to the nearest integer and cap the result at 4 (or 255, or whatever our integer max is), and we’ll have a nice, even distribution in our conversion.

I could have misunderstood, but it seems like all of the errors and uncertainty discussed in the article come from how the multiplied floats are truncated into integers. I think that this method eliminates that cleanly.

Surely it shouldn’t be surprising that a technology which literally can only regurgitate bits of things which others have already made, when put into the hands of people whose imagination is limited to what already exists (or alternatively, is not meaningfully directed) precisely because they lack an understanding of the underlying principles, results in only slight variations of the things we already have.

I can’t immediately give you a smartphone app concept that completely breaks an existing, arbitrary taxonomy, but there are two good reasons for that. One; anything that can still run on a smartphone can almost certainly be shoehorned into any existing taxonomy by carefully-worded arguments. Two; by the time a break with tradition is clear enough that such arguments become impossibly tenuous, smartphones will be things that our great-grandparents used to use.

To counterpoint the author’s smartphone analogy, think of how people looked at their TVs in the early 1970s. It was a society-changing but by that time relatively established technology with high growth. And people had all sorts of ideas for “new” things to do with it. You could’ve made arguments regarding most of them in the same vein as the arguments in this article. Most of those ideas were half-baked and failed at the time… only to resurface decades later, altered, refined, and successful, on PCs and smartphones. But PCs and smartphones are not, in any real sense, TVs.

Which surprisingly, once I hunkered down and pushed my way through this lengthy essay, is essentially one of the points that I think the author is making (although obliquely): That by the time this technology has evolved beyond its current limits, it will no longer be something that we recognize as “software” in the current sense.

I suggest trying to keep the concepts of “integrated system design” and “algorithmic process definition” separate from “digital computer software” in a similar way. Which, funnily enough, are the parts of all of this at which humans arguably still beat LLMs.

deleted by creator

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.

The Mikado Method, eh?

(All together) Three junior devs at work are we,
Busy and harried as devs can be,
Compiler warnings flowing freely,
Three junior devs at work!

(Alice) Everything is a source of bugs! (Laughter)

(Bob) When they wrote this, were they on drugs? (Laughter)

(Carlos) Don’t touch our “World’s Best Coder” mugs! (Laughter)

(All together) Three junior devs at work!

My apologies; I misunderstood your concept. I thought that you were talking about setting up some kind of central clearing house for funds, but now I see that you’re suggesting more of an automated report which is compiled for each user, locally, for them to act on manually at periodic intervals. That does seem to sidestep most of the legal issues.

Is the main issue really tracking and consolidating microdonations, or is it transferring credit between these donation systems and traditional finance entities like banks and credit card networks?

From what I’ve seen, efforts to develop microtransaction/microdonation systems generally seem to have trouble with regulatory compliance, either through legitimate legal requirements that force them to do things that seem nonsensical to their users (My guess is that the registered servers issue OP mentioned with Flattr came down to this), or due to greedy intermediaries stalling and witholding under false pretences while they hold out for a bigger share of the money, without appreciating the already extremely thin margins involved.

SDL is written in C, but bindings are available for multiple languages, including C++ and C#. As it happens I was actually using it with C++. And there are other libraries you could use instead, like GLFW or Allegro.

I’ve never thought of C as being that much lower-level than C++, but I guess everything’s relative.

• 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 cross platform is a pain.

It doesn’t have to be with libraries like SDL. Years ago I got stuck fighting all-in-one game engines that didn’t fit my design choices, precisely because I thought it would be worth it for platform independence. Then I found out about SDL, which was what I actually wanted.

If someone thinks that not using a pre-rolled engine with a full editing suite included is a waste of time, I can respect that. But there are options if you’d rather make your own but still don’t want to have to learn the ins and outs of multiple hardware architectures and operating systems.

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.

Private members aren’t actively blocked from external access; they’re passively marked “Access prohibited”.

That means that rather than being unable to find the members of a class, C programmers simply can’t pick up on the signals telling them that they’re not wanted.

(Fellow C programmers: I’m joking. :D)

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.

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.

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?

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.

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.

I’m not sure how common they are outside Japan, but I have a little (about 12" I think) Panasonic “Let’s Note” that I use quite a lot as a lightweight coding (and retro/indie gaming :D) device that I can throw in even my smallest bag when there’s a chance I’ll have to kill more than a few minutes. They’re designed to be a little bit rugged. I had Ubuntu on it previously, now Mint, and the only problem I’ve had is that Linux somehow sees two screen brightness systems, and by default it connects the screen brightness keys to the wrong (i.e. nonexistent) one. Once I traced the problem it was a quick and painless fix.

They seem to be sold worldwide, so you may be able to get one cheaply second-hand. One thing to be careful about is the fact that in order to keep the physical size down, the RAM is soldered to the board. Mine is an older model (5th gen iCore), and has 4GB soldered on but also one SODIMM slot, so I was able to upgrade to 12GB total. But I’ve noticed that on most later models they got rid of the RAM slots entirely, so whatever RAM it comes with is what you’re stuck with.

https://knowyourmeme.com/memes/programming-socks