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

101–110 of 182 posts

Re: FizzleFade

#101

Post by throwaway2016a »

onion2k wrote: post #92
throwaway2016a wrote: post #52

Earlier quoted context omitted.

Just the other day I showed one of our junior devs how they could turn their 10 lines of somewhat slow and obfuscated code into a 3 arguably more readable lines using a bitwise operations. And this was a front-end webapp. Then again, more readable is subjective and some devs might see "<<" and get thrown off.

A reasonable 'compromise' of 3 lines of code with 7 lines of comment to explain what it's doing would be my preference.

Or... and just throwing this out there... developers can take responsibility to know what bitwise operators do the same as they know what "+" does.

The three lines of code were:

for ( ... ) { x = x The developer was essential using an array of booleans to simulate a bitwise operator.

It is very sad that devs these days need a comment to know what that does. Would we expect 7 lines of comments if it was:

for ( ... ) { x = x + y; }

Re: FizzleFade

#102

Post by WillKirkby »

simias wrote: post #61

The original GameBoy had a hardware LFSR that could be used to generate white-noise-like sounds. It was often used for "whooshing" effects and also cymbal sounds, such as in the famous Super Mario Land theme: https://www.youtube.com/watch?v=Gb33Qnbw520

For more technical details on the exact LFSR used, there's this: http://belogic.com/gba/channel4.shtml

Re: FizzleFade

#103

Post by dre85 »

I didn't quite understand why this is guaranteed to reach every pixel coordinate? Is there something inherent about LFSR that generates complete sequences within the cycle? So elements are never repeated or omitted?

Re: FizzleFade

#104

Post by ctw »

maffydub wrote: post #66
thesimon wrote: post #59

Earlier quoted context omitted.

>Now, when FPGAs become more and more popular, people will be forced to learn VHDL languages and then different lesser-known techniques will surface. Isn't that already part of a normal CS degree? We needed to learn VHDL to program a Atmel ATTiny for class.

Are you sure you learnt VHDL? As I understood it, the ATTiny isn't an FPGA but an 8-bit microcontroller. Learning some form of assembly language at university is (probably) reasonably common. Learning VHDL (for programming FPGAs) is less common - I did for my Computer Science degree, but this was about 15 years ago, so I don't know if it's still common.

Just one data point, but I'm currently at school for Computer Engineering and we learn and use VHDL and Verilog for several courses. We use it to program Altera FPGA's.

Re: FizzleFade

#106

Post by jstapels »

dre85 wrote: post #103

I didn't quite understand why this is guaranteed to reach every pixel coordinate? Is there something inherent about LFSR that generates complete sequences within the cycle? So elements are never repeated or omitted?

I was wondering the same thing myself. I'm guessing they tested it and found that it hit every coordinate at least once and said "good enough". Meaning, I don't think it's guaranteed, they just picked one that did.

The interesting thing is that you're guaranteed to always have a different number because otherwise the cycle would restart. So you just need to find a sequence that's long enough.

Re: FizzleFade

#107

Post by i_cant_speel »

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.

I think that working with bits is still a standard part of a Computer Science program. I took a class last year dealing with logic gates and bits. I also have a couple of friends that went to other schools that also took the same kind of class.

While the information is nice to know and helps every once in a while (like understanding these articles better), I just don't think it's nearly as necessary to know as it used to be.

Re: FizzleFade

#108

Post by ticklemyelmo »

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 remember seeing it in a variety of mid-80's Commodore 64 games, where it ran at full speed and looked fantastic. I always wondered how it worked.

Re: FizzleFade

#109

Post by onion2k »

throwaway2016a wrote: post #101
onion2k wrote: post #92

Earlier quoted context omitted.

A reasonable 'compromise' of 3 lines of code with 7 lines of comment to explain what it's doing would be my preference.

Or... and just throwing this out there... developers can take responsibility to know what bitwise operators do the same as they know what "+" does. The three lines of code were: for ( ... ) { x = x The developer was essential using an array of booleans to simulate a bitwise operator. It is very sad that devs these days need a comment to know what that does. Would we expect 7 lines of comments if it was: for ( ... ) {…

developers can take responsibility to know what bitwise operators do the same as they know what "+" does

Yes but they won't. Pragmatically speaking adding a comment to explain a concept the next developer won't use very often means you won't need to answer their questions about it when they next need to modify that piece of code. That's a big win for you, and it means the other developer can carry on being productive.

Post reply on HN