pouët.net

Go to bottom

bfdemo by SirDayBat

bfdemo is a short demo containing a few simple demo effects written in 
brainfuck. For those who don't know: brainfuck is an esoteric programming 
language that has only 8 commands, and many rather simple calculations are 
ridiculously complicated to program in it. It uses a pointer to operate on a 
one-dimensional array. For more detailed information, see, for example, 
http://esolangs.org/wiki/Brainfuck .

And no, the code isn't generated from any other code, it's written 
directly in brainfuck, except for two parts of the text screen, which 
were so mechanical to code that I decided to make a script to generate 
them with.


How to run bfdemo
-----------------


Short version
-------------

	On Windows, I don't recommend using the DOS terminal, it's so slow and
laggy. You should get for example cygwin and rxvt. Set rxvt's window size to
100*51. bfdemo.exe is a compiled version of bfdemo.b. Start bfdemo.exe, and
enter a character that's 'A' or greater. The bigger the character's value is,
the slower the demo will run. If the demo's frames don't appear correctly, try
"bfdemo.exe|buffer.exe", enter the character again and hope for the best.
	On Linux, start a terminal of size 100*51. Start bfdemo (compiled version
of bfdemo.b), enter a character ('A' or bigger) and see if the frames appear
correctly just like that. If not, pipe bfdemo's output to the program called
"buffer". Again, hope for the best.
	(In both cases, of course you can get an interpreter and use it instead
of the compiled version.)
	In other cases, you need to get a brainfuck interpreter or 
compiler and interpret/compile bfdemo.b. Other things (terminal window 
size, input character etc.) are of course the same.


Long version
------------

It's recommended to compile this demo instead of using an interpreter, that way 
it'll run faster. It should run well enough in an interpreter on a somewhat 
fast computer, though, if a good interpreter (bff (http://swapped.cc/bf/) for 
example) is used.
	I've included compiled versions for both Linux (bfdemo) and Windows
(bfdemo.exe).

The demo uses memory cells capable of holding values from 0 to 255. It needs 
20221 cells. The number is that big because the tunnel effect needs to 
calculate and store into memory some values beforehand; calculating them in 
realtime would be just too slow. 

Don't be confused by the considerably long loading times before the tunnel and 
plasma effects; a lot of values is calculated during those. It shouldn't take
more than a couple of seconds though. There's the loading bar, so you'll know
that there's something wrong if it doesn't make any progress.

When the program is started, before it outputs anything, it expects a frame
interval to be input as one byte. For convenience, its numbering starts from 65
(the value of the ascii character 'A'), so that when you input the byte, 65 is
subtracted from it. So just enter a character that's 'A' or greater.
	The value doesn't determine the frame interval in any constant unit of time
really, because it just tells how many times the program should do some
calculations - that are meaningless besides the time consumption - and the speed
of brainfuck interpreters and other things can vary quite a bit. That's why it
asks for the frame interval in the first place, so that the user can adjust it
to a value that looks nice on his particular computer-interpreter-etc-
combination.

The demo uses the brainfuck command '.' to print out its frames. A frame's size 
is 102*50 characters: 50 rows and 100 columns, plus two characters (\r\n) for a
newline after every row.
	There might be a bit of difficulty in making the frames show properly, so 
that the print buffer doesn't e.g. cut every frame at the middle or so of every
frame. It probably won't look right on the windows cmd terminal, it prints too
slow. On windows you should probably use something like cygwin with rxvt.
	One might want to somehow make sure that the buffer is quickly printed after
and only after every 50th line. For example, the accompanying buffer.exe can be
used for this by doing something like "bfdemo.exe | buffer.exe", so that
bfdemo's output is forwarded to buffer.exe's input. This buffer thing waits
until it has been given 50 lines of input, then it outputs them and uses
fflush(stdout); to make sure that the frame actually appears on the screen.

The last byte the demo outputs is a zero, so that if the output is forwarded to
some other program it'll know when the demo ends.


bfdemo made by SirDayBat (ircnet, quakenet, nuutti.holtta@luukku.com).
Thanks to sooda for help with cygwin and rxvt stuff.
Go to top