> 1) 16 and 32bpp color depth at any resolution, either on the console
>    screen or under X when the latter uses a framebuffer server

	Additional notes (after a bit more testing):

1) FWIW I am a perfect newbie at using and programming with
    framebuffer devices  :-)

2) Working on the support for 24bpp (which is in principle the
same as 32bpp w/o alpha), I found a little problem that will cause
the image to display wrong colors in 24/32bpp (due to a missing
cast from signed to unsigned char).  So, as of version 0.1 the patch
is not useful at anything but 16bpp color depth.  Unfortunately
I don't know yet how to run the framebuffer at 32bpp for proper
testing (I only have fb codes up to 1280x1024 at 24bpp).
	The next 0.2 version will try to correctly support all but
the 256 color mode which needs colormap support for working (planed
for version 0.3).

3) The patch temporarly changes some attributes of the terminal
so as to be able to read keyboard input with neither blocking
nor line buffering (i.e. you don't need to press <enter> after 'q'
to stop rendering when using povray +x).  In certain conditions,
for instance when aborting povray with Ctrl+C, the initial tty
settings are not restored correctly and the console gets hardly
usable after povray terminates.  A workaround is to type in e.g.
'stty echo cooked' at the console to get it somewhat working again.
Will be fixed in version 0.2.  As one could guess, I'm also a
newbie at interfacing the tty's  :-)

4) Concerning running this patch under X Window:

- this is possible when the DISPLAY environment variable is unset:
   'unsetenv DISPLAY' (csh) or 'unset DISPLAY' (sh).

- the intend of the patch is to run povray on the console so as to
   save the great memory burden of running X, i.e. it's similar to
   using the SVGAlib display BUT w/o the need to run as root or to
   make povray suid root (therefore this patch is also targetted at
   making the program usage more secured under Linux).  Hence, it
   is a side-effect that the patch may work under X.  The next
   point explains why it's not a good idea to run it under X.

- the second screenshot I posted in p.b.images shows the patch
   running "under X Window (using framebuffer server)".  The text
   in parenthesis is actually meaningless, as the patch can also
   do something when the X server is not using a framebuffer module.
   I write "do something" instead of "is working" since it might
   work or not depending on your settings.  The image was obtained
   running the framebuffer console and the X server both at 16bpp.
   If the X server runs at a different color depth than the frame-
   buffer console (e.g. 16 and 24bpp respectively), this patch will
   display a crappy image.  I don't know (for now) of any way to
   fix that, nor if it is desirable at all.  Thus, you should not
   use this patch under X when a framebuffer device is also working
   at the console, which perfectly meets its goal anyway  :-)


	- NC

Post a reply to this message