Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FizzleFade

fabiensanglard.net

Post reply on HN
Print view View original

31–40 of 182 posts

Re: FizzleFade

#31

Post by Illniyar »

pasta wrote: post #5

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.

Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits.

In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages.

The fact is that in these products (frontend/backend web development and apps) the performance profile is dominated by bad algorithms, wrong data structures, slow libraries, missing db indexes etc... which knowledge about bits help absolutely zero with.

Large binaries are also not dominated by code you write but rather by using too broad libraries or simply from huge assets.

The only thing I'd consider knowledge of bits to be of any help to a run of the mill developer these days is the knowledge that floating point numbers don't multiply/divide well - but that kind of knowledge can be imparted without really diving into how bits work.

Re: FizzleFade

#32

Post by Illniyar »

afpx wrote: post #19
pasta wrote: post #5

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.

Recently, I started helping out data engineering teams improve performance of their big data processing pipelines. Man, was I shocked. Very smart, highly educated, mid-level and even senior software engineers seem to know very little about bits these days. When they'd run into a memory issue, their natural response was to just spin up a few more servers and throw another terabyte of memory at the problem. Makes sense…

And did knowledge of bits help solve the memory issue?

Re: FizzleFade

#33

Post by barrkel »

dmichulke wrote: post #10

Related: https://en.wikipedia.org/wiki/Linear_congruential_generator A pseudo-RNG that cycles through a all elements of a modulo-ring. Example for a 2^32 bit cycle: X(n+1) = (a * X(n) + c) mod m a = 134775813 c = 1 m = 2^32

Indeed; and careful selection of parameters for the LCG can truncate the ring to most arbitrary powers of two. And if you're willing to live with slight inefficiency (no more than twice as much work), an arbitrary modulo ring (shuffled sequence) can be produced by creating slightly larger range and skipping values that are outside the range.

This is a question I asked on SO some years ago relating to this problem - producing a shuffled range of numbers without allocating an array:

https://stackoverflow.com/questions/464476/generating-shuffl...

Re: FizzleFade

#34

Post by oblio »

oh_sigh wrote: post #18
maccard wrote: post #12

Earlier quoted context omitted.

I dont particularly care for your generalisation about younger coders, as a younger coder. There are many of us who do care about the low level details of our code, and take extra care to write good performant code. To make a generalisation about "older" programmers - I have the feelings that older coders are stuck in their ways and aren't willing to change their behaviours, and when a younger coder tries to suggest…

OP said "a lot of", not all. Which is probably true, because you needed to know it in the past, and now you don't. Chill out.

> You needed to know it in the past, and now you don't

Well, that's not a very interesting statement by itself, though?

We used to need to know how to use clubs back when we lived in caves, but I don't see myself practicing with one any time in the near future :)

Re: FizzleFade

#35

Post by zimpenfish »

ishi wrote: post #4

Cool, I knew that LFSRs were used in ciphers. I was not aware that they were also useful for implementing old-school graphical effects. https://en.wikipedia.org/wiki/Linear-feedback_shift_register...

I'm not sure I'd call Wolfenstein 3D "old-school".

But then I did start with computers in 1980.

Re: FizzleFade

#36

Post by zimpenfish »

buzzybee wrote: post #27

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 us…

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.

Re: FizzleFade

#37

Post by afpx »

Illniyar wrote: post #32
afpx wrote: post #19

Earlier quoted context omitted.

Recently, I started helping out data engineering teams improve performance of their big data processing pipelines. Man, was I shocked. Very smart, highly educated, mid-level and even senior software engineers seem to know very little about bits these days. When they'd run into a memory issue, their natural response was to just spin up a few more servers and throw another terabyte of memory at the problem. Makes sense…

And did knowledge of bits help solve the memory issue?

That was implicit. Of course it did! :-) And, cut server costs in half, too.

Re: FizzleFade

#38

Post by leni536 »

schindlabua wrote: post #15
leni536 wrote: post #14

Earlier quoted context omitted.

My approach would be something like this, but with a very "poor" generator with the parameters a=81007, c=0 and m=2^17. This approximates a low discrepancy sequence (additive recurrence with alpha=1/golden ratio). Then I would calculate x and y values using the hilbert curve and the calculated pseudorandom number as the index (more precisely two Hilbert curves next to each other, so it covers a 512x256 rectangle). On…

Cool! I was just looking up hilbert implementations yesterday, so that's super useful. Thanks! (quick note: in your source the function is called hilebert instead of hilbert)

Fixed, I also added a Wolfram Mathematica module that can be used with LibraryFunctionLoad.

Re: FizzleFade

#39

Post by peteretep »

xorcist wrote: post #22
peteretep wrote: post #17

Earlier quoted context omitted.

> I have the feeling that knowledge > about bits is lacking by a lot of > younger coders. And I also think > this is what causes bloatware From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for deve…

> I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, I regularly see the exact opposite: People throwing money and hardware at problems instead of doing the simple and obvious thing. I guess that makes me officially old.

    > People throwing money and hardware at
    > problems instead of doing the simple
    > and obvious thing
There are (almost) no technical problems, just business decisions. Programmer time for development and maintenance is expensive. Hardware is decreasingly so (also it's CapEx, so nobody cares if you literally light it on fire).

Re: FizzleFade

#40

Post by trollopTheJope »

i am interested to know the particulars of any routines people have for reading and reviewing a codebase, as the author talks about doing in his spare time. do you take notes? add comments? step through with a debugger?
Post reply on HN