This is the README for ScreenMunger.2.0.N.bs.tar.gz [Download] [Browse] [Up]
ScreenMunger Low level video display hacks INTRODUCTION: ScreenMunger is a small collection of *very* low level programs that play with screen memory directly. It may prove useful for understanding how to implement signal trapping, write ioctl calls, and/or use screen memory directly for really fast drawing. It also does some pretty cool graphic effects :-). LEGAL: Copyright (C) 1992 by William Bumgarner and Charles Swiger This code is provided for free; you may modify and/or redistribute it under the terms of the GNU General Public License as published by the Free Software Foundation. This program is distributed WITHOUT ANY WARRANTY and without any guaruntee of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. A copy of the GNU Public License is included in the file "LICENSE". You might be able to reach the authors at wb1j+@andrew.cmu.edu and cs4w+@andrew.cmu.edu. Your comments, suggestions, and criticisms are most welcome. CREDITS: Bill Bumgarner - primary author of version 1.0 Adam Swift - random chunks of code, testing Chuck Swiger - primary author of version 2.0 Pete Wickerscham - some code, and color support hopefully RSN Julie Zelenski - a suggestion to use the evs driver VERSION HISTORY Version 2.0: The examples here have been modified to use signal trapping. They are much friendlier now, in that they restore the screen memory to its original state when the program stops or is paused. Much of the code has been rewritten for clarity. It has also been rewritten to avoid core dumps. The following programs use the evs driver (/dev/evs0) to control the screen brightness: br, bright, bright2, and flash. They should work on any type of display. The other programs need to have direct access to /dev/vid0. To do this, type "chmod 666 /private/dev/vid0" while logged in as root. Note that this could represent a security hole. If security is an issue, be sure to change the permissions back to their original state when you are through. At the moment, the programs that write directly to screen memory assume a monochrome display. They break in interesting ways on a color machine. This may be fixed soon. (Come on, Pete!) You can run more than one screen munger at a time; just be sure that you kill the first process last, or you'll end up with a fairly mangled video buffer. No harm can come of this, but it is visually annoying. Either reboot your machine or move the windows, menus, and icons around to redraw the screen. -cws Version 1.0: (Annotated from the original README to include changes made by v2.0.) An example of using an ioctl call to control video. This is not documented or supported and will probably break in some future release of the software. The original thought came from elsewhere. But, hey, its only a hack... Notes (about brightness control): - Under 2.0, there is a proper way to do this... this is NOT that way. [Fixed, uses evs. -cws] - Under 2.0, /dev/vid has access rights of crw-------. Either this code must be run as root or root must change the access rights to /dev/vid. Under 1.0, /dev/vid was apparently set to crw-rw-rw-; leaving open all sorts of interesting potential destruction via networks. - This is an undocumented sort of thing; I haven't played long enough to figure out how to READ a value from /dev/vid0... At this point in time, this code only controls the brightness of the monitor but can't tell you what it was set to in the first place. [Try "man evs." -cws] - br.c is the only documented piece of code-- the rest is just as straightforward. How much documentation can one have for something so few lines long? [The code is now documented. Well, somewhat. -cws] --- Notes (about memory munging): - This code only works correctly on a mono system. To get it to work on a NeXTstation Color would not be that difficult; just change some of the constants (VIDEO_MW, NPPB, VIDEO_H, and the like-- see /usr/include/nextdev/video for more information) to deal w/the colorstation's memory layout: 12 bit color: 4 bits/sample, 3 samples/pixel, 1.5(!) bytes/pixel [ pixel1 ][ pixel2 ][ pixel1 ]... [samp1][samp2][samp3][samp1][samp2][samp3][samp1][samp2][samp3]... [ data[0] ][ data[1] ][ data[2] ][ data[3] ][ data[4] ]... - On NeXTdimension, this code will not work at all. I have heard rumors that it is possible to get the 'base-address' of ND video memory, but have seen no confirmation or information in regards to how to do such a thing (if anyone figures it out, PLEASE mail me). - If you really want to diddle points directly, check out GraphicsWrap-- it is available from the sonata.cc.purdue.edu archive. --- A final warning: This code is a HACK. It is NOT a supported thing to do to your system; it WILL break in the future. But... it is cool, and it could be used to write some really COOL game/animation stuff. Have fun w/it, and send me anything cool you create... I would definitely be interested. b.bum
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.