ftp.nice.ch/pub/next/developer/objc/screen/ScreenMunger.README

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.