Name | Modified | Size | Downloads / Week |
---|---|---|---|
readme.md | 2019-02-17 | 2.9 kB | |
fbgrad_0.9.tar.xz | 2019-02-17 | 104.6 kB | |
Totals: 2 Items | 107.5 kB | 0 |
This doesn't do anything useful but it is a good example of additive colors. I was researching and practicing using framebuffers under Linux for a different project, and it was fun so I went off on this tangent.
Alan Corey 2/16/2019
Basic BSD copyright applies: do anything you want with it, just acknowledge that I wrote it, not you.
If you lose the makefile, compile like: gcc -Wall -g ss1.c -o ss1 -lm -lncurses -ljpeg It does need ncurses and libjpeg-dev. Ncurses makes it respond to a keypress, libjpeg is so it makes convenient screendumps.
It will run without X just fine. In fact on my Dell laptop it won't do
anything useful when run from X, if I ctrl-alt-fn to another virtual console
it will work from that. (ctrl-alt-f1 to return) It was written on a Raspberry
Pi 3B, it just opens and mmaps /dev/fb0 which most machines seem to have.
Runs at about 1.8 seconds/screen on that, 0.18 seconds on my 10 year old laptop.
I ran it on a 1920x1080 screen, the program mostly expects 32 bit per pixel
(RGBA) mode. I've run it on a 1024x768 32 BPP screen but not tested
extensively. It is written to test the screen size and depth, it should
adjust itself.
How it works: 3 random points on the screen edges are picked for each frame. The RGB colors for every pixel on the screen are a function of the pixel's distance from those 3 points. It was fairly boring until I divided the distance figure by 2, so I made the divisor a random. The dist() function outputs 8-bit number, also the pixel's color needs to be expressed as 3 8-bit values. So it goes over 256 and wraps around to 0, usually a few times, which is sort of interesting. You can look at what happens when you mix colors. If you stare at a picture it made you can figure out where the circle centers were, there are red, green, blue stepped gradients radiating out from that.
To stop press any key except s which will do a screendump to a file in /tmp and keep going. It takes a little practice but usually you want to make the decision to save and push s about 4/5 of the way through drawing. Filenames are like ss1550348403.jpg where the number is a standard unix time_t.
If it goes too fast uncomment the sleep() call in main(). Fun for a while but it gets old like looking at fractal pictures. Might make a good babysitter. :)
Freshly-written clutter on your screen (clocks, CPU usage monitor, price tickers, etc.) will get picked up in screenshots so run from the console if you're serious about it. There's an LXDE CPU usage graph showing in one of my examples here. It had updated since the last time the framebuffer was filled. That doesn't happen from the console.
In the included example ss1550328904_1024.jpg the point responsible for red is at lower left, green is top center, blue is lower right. The distance and divisor were such that there are 4-7 gradient cycles. The crossing of the gradients gives a wide range of colors.