There's a lot of "but wait, there's more" in what's happening around AI.

For example, if I have a video game where there's collision against the walls, I can understand this as potentially colliding against "multiple things simultaneously", since I'm likely to describe the scene as a composite of bounding boxes, polygons, etc.

But to get an answer for what to do in response when I contact a wall, I have to come up with an algorithm that tests all the relevant shapes or volumes.

The concurrency bug that appears when doing this in a naive way is that I test one, give an answer to that, then modify the answer when testing the others. That can lead to losing information and "popping through" a wall. And the direction in which I pop through depends on which one is tested first.

The conventional gamedev solution to that is to define down the solution set so that it no longer matters which order I test the walls in: with axis aligned boxes, I can say "move only the X axis first, then move only the Y axis". Now there is a fixed order, and a built-in bias to favor one or the other axis. But this is enough for the gameplay of your average platforming game.

The generalization on that is to describe it as a constraint optimization problem: there are some number of potential solutions, and they can be ranked relative to the "unimpeded movement" heuristic, which is usually desirable when clipping around walls. That solution set is then filtered down through the collision tests, and the top ranked one becomes the answer for that timestep.

Problems of this nature come up with resource allocation, scheduling, etc. Some kind of coordinating mechanism is needed, and OS kernels tend to shoulder a lot of the burden for this.

It's different from real-time in that real-time is a specification of what kind of performance constraint you are solving for, vs allowing any kind of performance outcome that returns acceptable concurrent answers.

Later, we were successfully marketed "Wonder Bread" as a clean(as in sanitary) and convenient product, and that set another standard, one sold to housewives. It was basically applying the same strategy that built McDonald's in its early years. At the time of Wonder Bread's introduction, many adults could still recall when products were being sold "from the cracker barrel", mixed homogenously and exposed to pests. All the early packaged foods, including the canned stuff and the sliced bread, were establishing a new norm of the manufacturer guaranteeing freshness to a sell-by date. It was PB&J on sliced bread for lunch and macaroni and cheese for dinner that got a lot of the US through the Depression years.

Continental Europe was simply less interested in this genre of bread - they had competition from other varieties of grain, and different kinds of bread dishes.

If the LLM gives a solid three-star "fast food" education, that is actually considerably better than letting it all fall on the shoulders of the babysitters that currently serve in many classrooms.

So the workflow I end up using for digital inks is: Open both programs, sketch in Krita, copy-paste the vector data into Inkscape, stroke->path, then use tweak tool to sculpt the lines. This adds line weight in seconds-to-minutes. Alternately, I can apply path effects instead of stroke->path, if I want a more programmatic design. If I want to paint, I can copy-paste the shape back into Krita.

And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.

Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.

The appeal of Forth is mostly in a principled sense of, if you want Forth to be your interface, you have to build your own Forth, because Forth does as little as possible to structure you. And building your own Forth is not impractical; that's the whole point. It's wonderful as an exercise and can be productive in the right context.

But any highly developed or standardized Forth system gradually converges on being "just another platform." And once it's just another platform, it's an annoying dependency, and you end up demanding more structure for it to help tame the complexity, so the Forthiness habitually erodes.

But this article happened back in 2009, too. I remember it. I may have been part of the problem. It's a signal of an economy that is displacing and reallocating workspaces.

But the only worthwhile analysis is basically "too bad, disruption is happening". Total car/truck sales went into a steep dive in 2020, made a marginal recovery the next year, and then declined again in 2022. The back-to-office coercion only had partial success - commercial real estate is still sinking in many markets. Meanwhile, e-bike sales got red-hot and everyone suddenly discovered Youtube urbanism. California governor Gavin Newsom made a trip to visit BYD recently, and their buses are being trialed in a few cities. You can even pin a lot of the global instability on energy changes - Russia was a big oil/gas exporter, and they seem to have driven everyone away from them at this point.

But this structure is also rather unrelated to the real productivity of the economy - the creatively destructive portion of American business always has something to say about it. If those companies want their labor to be cheaper and less frequently disrupted, they have to go cause grief for one of these rentier businesses, socialize some things and cut into some monopoly inaction or low standards. But they only reach that conclusion by letting the economy get into a highly unstable position first.

And this theme of memory basically holds true through the end of the "Fourth" Generation: games on console were assumed to be memory-starved, and advancements within those generations occurred through larger ROM enabling larger and more animated sprites, more graphically distinct "worlds," full soundtracks and scripted cutscenes. In 1988, the year of the great DRAM shortage, more of the games released used smaller ROM space, and it caused a notable regression back to technically simpler productions.

When you get to the Playstation/Saturn/N64 the approaches diverge quite a bit because the bottlenecks shift according to which platform you talk about. Memory is still a major consideration, but data streaming can be either relatively easy(N64) or a considerable engineering problem(everyone else), while the inverse is the case with data storage capacity. It's easier to discuss specific platforms as stable entities from that era onwards, since there's a cleaner separation of computing resources from game content.

Contour drawing is not taught in primary education, and it really should be: it generalizes on how you learned to write by learning some muscle memory and then playing it back to make a mark. Nobody who can write should be going around saying "I'm untalented at art, I can't even draw a straight line".

[0] https://en.m.wikipedia.org/wiki/Blind_contour_drawing

The thing digitalization solved was the paperwork bottleneck(access to raw data), not the information bottleneck(what people need to know to do their jobs). We have a surplus of global firehose information systems, but a scarcity of useful filtering mechanisms, most of them based on traditional indexing(date/time, alphabet, keyword search) or a black box algorithm that usually isn't tuned for your scenario. As well, there are a lot of unaddressed problems with data custody, where access controls tend to be very all-or-nothing and bespoken, and aren't generalized to the whole operating system.

The biggest one is actually animation. Animation gets expensive as you add more detail, and when you add resolution, you discover a need to add more frames of animation to make it still look smooth, so your art costs can explode. The use of 3D here is motivated by having camera-independent animation, and being able to use it for every minor environmental effect: think of every Myst-style game where you pull levers and push buttons and open doors. Character animation in early 3D was bad, but it was also "enough" to look representative, so it ended up beating traditional or live action approaches.

The first is open source and relies all on homebrew content, and most are remakes of existing games as you would expect, with MAME software emulation for the digital games. The software package contains a painful, CAD-like tool to define the playfield - very precise but hard to work with. You can make a new playfield in probably a month of effort, and then tinker with the game's rules for much longer.

The second, Pinball FX(which dropped the numbered titles in its fourth version), has a mix of licenses and originals, and which it's definitely become more accurate, the goal is primarily a visual showcase. It already pressures a modern GPU reasonably well when you crank the settings.

Neither one is doing anything to push the physics simulation further. Visual Pinball's physics rely on analytic methods for each mechanism, and while it has little details like computing the movement of the skirt on the pops as the ball rolls over them, it does not simulate whole-table vibrations, which are actually essential to gameplay because control is achieved through nudging the entire cabinet. And there's a huge realm of details that emerge from that where thousands of physics objects, down to the individual screw, need to wake up and interact in very fine detail, and the force creates a directed wave across the playfield, the wood needs to be able to wobble a bit. Adding a force to the ball is not sufficient. And actually achieving that means you now have to model everything the game has, including the insides, which is far more work than a playfield and magic mechanisms.

Pinball FX is not open source but I already know it isn't trying to be that detailed either.

But when you ask the broader audience about pinball video games, they point at Demon's Tilt. Which is not even trying, as far as the simulation goes - it is a video game, through and through. The problem is that broad demographic isn't really there because people who don't play pinball don't know the difference, and the niche of people who do, go play real pinballs. Which leaves a tiny space for roughly three or four companies that are focused mostly on licenses.

Of those, the pinball video game I play the most is Pinball Deluxe Reloaded, which is all originals, but most importantly, it's intentionally 2D and ideal for phones. And the sim quality is decent. And just by doing those things, it's done something none of the competition achieved, even in their mobile ports, because they put the sim first and have a 3D camera and no way of getting a simple flat projection.