FizzleFade is also found in Microprose games from the era (e.g. Railroad Tycoon, Civilization), sometimes in full-screen transitions and other times to fade in single sprites. But more relevantly to "id software history", you can find it in Origin's Space Rogue, which John Romero contributed to. A likely possibility is that he picked up the trick on this or a previous project while at Origin.
It's also possible to use a slower "arbitrary PRNG and bump" scheme that tests the VRAM for the desired values(e.g. if it were a sprite, by running the blit at that pixel address and testing) and walks forwards or backwards until an unset value is found. If the walk can be done fast enough, it'll execute at the same framerate as an LFSR cycle-length fade. It can be further supplemented with an estimation heuristic or a low-resolution map to generate unique patterns. It's just less speedy and mathematically interesting to do that.
I'm 95% sure I've seen this effect on a Spectrum which would likely predate even Space Rogue - I'd guess that would be an LSFR fade because "arbitrary PRNG and bump" would be hella clunky given the Spectrum's screen layout.
It enables the coder to engage in some late binding without engaging in a lot of casts or more elaborate metaprogramming: the enum index used for assignment is itself an assignable value and therefore can be passed around and manipulated if the algorithm needs it. It's a very intentional tradeoff of structure and long-term clarity for a faster turnaround to make design changes.
I haven't even checked to see if the final program uses it. It's the kind of thing, though, that you might go in thinking, "maybe I will need that", and it doesn't add too much overhead to your prototype.
My strategy for personal coding recently has shifted towards a sincere exploitation of automatic programming(in a manner similar to model-driven development or language-oriented programming, or the research of VPRI). The overall feedback loop looks like this:
* Write an initial mockup that exercises APIs and data paths in an imperative, mostly-straightline coding style
* Write a source code generator that reproduces part of the mockup by starting with the original code as a string and gradually reworking it into a smaller specification.
* Now maintain and extend the code generator, and write new mockup elements to develop features.
The mockup doesn't have to be 100% correct or clean, nor does the code generator have to be 100% clean itself, nor does 100% of the code have to be automated(as long as clear separation between hand-written modules and automatic ones exists), but the mockup is necessary as a skeleton to guide the initial development, and similar, comprehensible output one layer down is a design goal. Language-level macro systems are not typically sufficient for this task since they tend to obscure their resulting output, and thus become harder to debug. Languages that can deal well with strings and sum types, on the other hand, are golden as generator sources since they'll add another layer of checks.
I'm still only using this for personal code, but it's gradually becoming more "real" in my head as I pursue it: the thing that stopped me before was developing the right feedback loop, and I'm convinced that the way to go is with a pretty lean base implementation(Go is an example of how much language power I'd want to be using in the target output) and an assumption that you're building a bespoke generator for the application, that won't be used anywhere else.
Source code generation gets a bad rap because the immediate payoffs are rare, and it's easy to take an undisciplined approach that just emits unreadable boilerplate without gaining anything, but the potential benefits are huge and make me not really care about design patterns or frameworks or traditional "paradigms" anymore. Those don't achieve anywhere near the same amount of empowerment.
This is an approach I've been exploring myself. Do you have any suggestions or recommendations as to languages that lend them selves well to this approach?
I do microwave the sponge after use, for about 2 minutes so that it's bone dry. The reasoning is simple: most of the bacteria are going to hang out in the water. It's still going to be infected, but it doesn't have to be disinfected. It just has to remain close enough to the ambient load of the kitchen that it doesn't obviously inflame my hands when I pick it up. After all, my hands are germy too, most of the time. The soap, water, and pressure applied during cleaning are supposed to do most of the work.
IME real users don't care about the app being aesthetically different, but they do care if the common idioms have changed(e.g. position of OK/Cancel). That shouldn't depend on your toolkit, though.
Some time ago someone recommended SpeedCrunch to me for calculator stuff and I use it all the time now. It's a little bit less intuitive since it takes a syntax instead of presenting buttons, but it does a ton more.
Regarding smart contracts and other inventions of cryptocurrency: I think, most of all, the crypto market is absolutely vicious, in a way that both capital markets and technology companies haven't seen(in the public eye) for many, many years. As of right now there's still some faith left that Ethereum is going to go places because firms keep trying to use the technology on the basis of hype. Unlike with most overhyped and half-baked tech, though, the failures do not get shoved in the back room for some hapless dev or ops team to deal with. This is like if Apple and Google had daily columns on the front page showing every bug or support issue that they experienced in the past 24 hours.
And that's been true right from the beginning with Bitcoin: scams, schemes, heists, data loss - the headlines scream blood all the time. We've never had that kind of "mean time to disaster" in technology before. The status quo was that something would fail, but the failure would never quite get back to the individual or company that produced it. They would spin it away, and no careers would be harmed. But the likes of Solidity produces a meat-grinder, a blind destroyer of any who dare enter calling themselves rockstar.
I think it's kind of awesome and beautiful, in that sense. It will induce a maturation throughout the economy to adapt to this new pressure. But like adolescence, it can be an ugly work in progress, and I don't expect Ethereum itself to be a survivor at this rate.
This is like if Apple and Google had daily columns on the front page showing every bug or support issue that they experienced in the past 24 hours.
Things is, with Apple and Google there is a rather low ratio of spectacular failures to output of products that are in many cases, rather effing amazing. Whereas with the cryptocurrencies unfortunately, the spectacular failures be they in the form of scams, schemes, or heists, more or less are the story.
It's not like these recurrent tales of avarice, greed, or just plain seediness are crowding out the print space for the tales of all the amazing things cryptocurrencies are bringing about, there's room to tell that story to, but where is it.
At this point it's getting harder and harder to locate where there is that glint of hidden potential in cryptos in the face of all the malice and fuckups.
Because it is unfettered completely innovative ruthlessly competitive free market. Boom and bust cycles from the era of industrial revolution tied to a capped deflationary currency (gold) that saw some of the fastest and most astounding speed of technological advancement in recorded human history. It's creative chaos is, personally, liberating.
