Anaglyph Stereo Quake
Prolonged use of this software may result in some form of visual impairment. I, Graham Bean, will accept no liability for such damage. You use this software at your own risk.
Anaglyph are stereo images designed to be viewed with red-blue glasses. Anaglyph Quake is a stereo version of glQuake designed to be viewed with red-cyan (or alternatively red-blue or red-green) glasses. The whole point of this is to make the images you see in quake truly three dimensional.
Anaglyph's have generally not been popular in 3d games. This is largely due to hardware restrictions resulting in inappropriate stereo imaging techniques and preferences for 256 colour display modes which used for red-blue stereo viewing resulted in effectively 16 colour graphics.
Many home computers used for games have fast processors and 3d acceleration boards. Although LCD stereo viewing in games is starting to become more wide spread, Anaglyph's have shown no signs of a comeback (not that they were popular to begin with). So I decided to see what would happen if I took a popular game (Quake) and added good (IMHO) Anaglyph support to it. The results (although very limited in hardware compatibility) were better than I expected, so I decided to release this to a wider audience.
Windows (95/98/NT, Just as long as you have open-gl)
An Open-Gl Accelerated Video Card
A moderately fast computer (at least fast enough to run ordinary glQuake )
Some Red-Cyan Glasses (red/blue or red/green are ok, but not as good)
A legal copy of Quake.
This version of glQuake only uses a couple more features than standard glQuake. This means, however, that it will not work with the quake-GL type mini drivers. I can almost guarantee that it will not work with any GL->Direct X mapper in existence.
In fact, the gl function used to separate the colour channels not frequently used, and as a result is probably not supported by most consumer graphics boards that claim open-gl compatibility.
[See tested hardware for boards that are known to work]
Once your system is set up for open-gl acceleration (if it isn't already, I can't tell you exactly what to do.). Just copy it into your quake directory, and presto, you are ready to go.
Run it, any you will ether get instant gratification, or just a plain image, or your computer will crash. Its just that simple.
If it works, then all is well and you should proceeded to the configuration section, in which tuning this to your system is expanded.
If it doesn't work, your probably pretty much stuffed, however this is a troubleshooting section in this document which might (and that's a tentative might) suggest a solution.
For incompatible graphics boards, which will probably be a lot of them, I might devises a software workaround (IFF enough people ask real nice)
All configuration is performed though console variables. None of them are save out, so if you loose it, just quit and start again. Once your happy with your selections, write them down and add them to autoexec.cfg in your id1 directory.
st_separation specify the distance between the two cameras. This value is actually half the actual separation (each camera is moved this distance away from canter).
The larger this number is, the greater the depth will seem. The default is 2.5, which is the value I use when playing.
0 disables the separation and gives you ordinary glQuake, all be it a bit slower; And negative values are stereo reverse.
If you are having trouble seeing the image, reduce this to one or less, until you brain figures out that there is meant to be depth within the image, then start increasing it.
A stereo effect will be noticeable with as little as 0.1 separation (although the image will still be some what flat). Values of 5 an greater will cause your head to explode.
At zero pallerax, the image will appear level with the screen. This option specifies how far in front (in quake world) this is. Things further away than this appear to be within the monitor, things closer appear in front of the monitor (sometimes:)
The default is 20, which is approximately where the end of the gun barrel is. Object Closer than this should appear to come out of the monitor, but for this to happen your brain has to believe that this is actually happening (if you brain is like my brain it probably won't).
The min is 4 which is where the camera is (this dose not look good). The Maximum is what ever you like (theoretically it is 4096), however I have found that above 20, my brain doesn't buy in to the effect.
Although the views are parallel, the fustrums are adjusted so that the projection surface is aligned. This is because we are looking at a single display surface.
The default is 1. Which means one times st_separation, which is the correct value.
Great than one over adjusts, less than one under adjusts, 0 results in no adjustment (strangely enough) which is just ordinary parallel views superimposed on each other (this is the viewing set up which should be used in vr helmets with separate displays centred over each eye)
This adjustment is not practically useful. Small adjustments can be used to enhance or simulate close up viewing, I.E. you are much closer to the image than normal.
Especially useful for red-blue glasses or red-green glasses. These allow you to add colour to the image on a per channel basses. Generally you should add a bit of colour to each channel and more to the colour not included by your glasses.
Cyan glasses, allow green and blue light through in approx equal portions.
Blue glasses, allow mostly blue, but a reasonable amount of green though.
Green glasses, allow mostly green and very little blue through. It is probably not possible to get good colour viewing with these.
Good colour adjustment will counter act ghosting/cosstalk.
This colour adjustment uses a similar method as the poly blend feature in glquake. You have to turn poly blend off, then you will probable want to avoid this.
This modification to glquake is exclusively done in open-gl, there for it should be just as portable as glQuake. However most consumer 3d hardware dose not appear to correctly support glColorMask to separate the channels. I believe that I have employed this function correctly. It works as expected on my TNT2 with detonator 353 and on software only mesa. It would be possible to re implement the image combining using separate buffers and then mixed using a less open-gl demanding technique.
The number of machines tested is small, but this might give you some ideas about the compatibility of the is software
CPU |
Video |
Software |
Performance1 |
Functionality/Notes |
---|---|---|---|---|
Pentium II - 233 Mhz |
TNT2 (32meg agp) |
Win NT 4. TNT2 Detonators (vers 3.53 ) |
Excellent ( less than 25% hit)2 |
All features. (Development Machine) |
Pentium II - 266 Mhz |
Voodoo 2 |
Win98SE Mini gl -> glide driver |
Good |
Doesn't work - no rgb masking3 |
Pentium II - 266 |
Matrox G200 |
MGA200 ICD (ver 5.21?) WIN98SE |
Bad/Crashed |
RgbMasking is defective and un-accelerated. Graphics only semireconisable, alternating green blue stripes through image, newer revs crash4 |
AMD K6 300 |
Matrox |
WIN98SE GL Direct - D3d |
~2 fps |
No rgb mask |
> 1fps |
All features |
|||
WIN 98 SE GL Direct - Mesa Software only |
If
this version of this document has graphics in it then above this line
is a picture of what you should get when everything works properly.
Unfortunately there is not a lot you can do if this program doesn't work for you. Here is a list of things I suggest you try:
try changing gl_finish, gl_clear, gl_ztrick
Try updating or replacing your gl-driver
Ask me for a work around (but be aware that like politicians, I am not really listening :-)
None of these are high priority for me, however if there is enough intrest I might see what I can do.
Improve compatibility
Improve colour adjustment.
Fix crosshair (probably just one eye only )
For Questions about this modified version of glQuake e-mail:
The website, which is the prinaple release point for this version of quake
http://members.xoom.com/grbm3D/
Licence
This program and the work from which it was derived are subject to the GNU GENERAL PUBLIC LICENSE, which should be contained in the file GNU.TXT distriburted with this program.
1Performance mesurements are rought estermets only.
2Such good performance, seems unrealisitc, but is probably due to the draw engines cacheing
3Without rgbmasking you will only see one view, even though two are beening drawen.
4This may be due to quake useing 16 bit display mode. Yet to test 24-bit