Oh, that's something I also did in QBasic ages ago. I since lost the source code, but it basically worked by querying the screen from bottom to top, finding snow pixels (white) and moving them down, unless there was an obstacle. The initial snow on the ground (and the snowman) were using a different color that was almost white so it wouldn't detect as snow. It worked fairly well in 320×200 at the time.
I've tried the same approach in Turbo Pascal with BGI in the hopes of having a faster language and higher resolution available. It turned out to be quite a bit slower, likely because drawing and querying pixels was a bit more involved when using an adapter layer like BGI.
A few weeks ago I tried rewriting all that in TypeScript for fun and also trying to integrate it as an easter-egg with our graph drawing library (which renders with SVG) and first had to figure out how to efficiently support arbitrary obstacles that are initially SVG as well as a potentially changing viewport of the whole scene. I got sidetracked and didn't finish it, but proper collision handling was so easy back then (just look at the pixel color), but now with vector graphics and reading pixels being a very slow operation in many cases, it was surprisingly complicated.
At least from Rostock to somewhat closer destinations you have both options. There's a bi-hourly IC to Hamburg or Berlin and another bi-hourly RE towards the same destinations. They're not terribly different in terms of travel time, but one is a regional train and one is an inter-city train.
Sure, long distances (I had to travel from Rostock to Tübingen last weekend) are typically not taken with regional trains (although you technically can; I did that as a poor student a few times, it just takes 16 hours instead of 10), but over medium distances (around 2–3 hours) you often have both options.
Rebrickable is awesome. One of my children loves building with instructions and will do relatively little free building with Lego, and Rebrickable makes it very easy to find alternative models (often with questionable stability, though) that can be built from the same set. It also features a search of alternative models you can build with all the sets (and bricks) you have.
The way the array is constructed at least leads to holey arrays in V8. Perhaps similar in other implementations. The performance characteristics between different array types may vary significantly as well. Still, the traditional for loop, counting upwards seems to be fastest for me across Chrome and Firefox on Linux. For-of is slowest by a wide margin.
In fact, part of the implementation (or at least ideas) were borrowed from TypeScript. Nullability in C# changes depending on the checks around the code (similar to how the type of expressions in ThpeScript can change depending on prior code).
The use cases are different. While MSBuild tasks run during build (and partially when loading a project), typically the IDE is oblivious what happens there. The source generator runs directly inside the compiler infrastructure and thus you didn't get error highlights for code that would otherwise be only generated during build but not as you type. This makes it much more friendly than pure build-time generation of code.
You don't have to write the method twice. Source generators can only add new code, they cannot take away a method you declared, so it will still be there at runtime when called with non-constant arguments.
Even with MSBuild 4. From the days when .NET Framework was an OS component and also the build tools (until Roslyn) were part of the Framework.
reply