Here's a quick run-down on subjects Jim mentioned in a 97Jan22 email:
src/slisp/xgt/c/dist/gplotlib/gtplot.h src/slisp/xgt/c/dist/term/iris4d.trm src/slisp/xgt/c/dist/term/iris4d.tri src/slisp/xgt/c/dist/term/iris4d.segwhere the latter three are my Skandha4 driver for GL, and the former defines the datastructures passed to the driver by the various calls. I would strongly recommend that the first stage of doing a port be moving the above four files into the
src/slisp/xgt/c/directory, then nuking the entire
src/slisp/xgt/c/dist/directory, and rehacking until Skandha4 passes selftest again. After that, I would clone the GL driver and rehack it to be an OpenGL driver: SGI has a GL -> OpenGL portability guide that should ease this. This should almost all be a straightforward matter of renaming function calls in minor ways to their OpenGL equivalents. The major exception, I believe, will be the lack of mouse input support in OpenGL: OpenGL leaves all mouse I/O issues to the host window system. This means that you'll need to explicitly link Skandha4 against the X Windows libraries, and then rewrite the driver to use X calls for mouse input rather than the old GL calls. This may go quite easily or prove a bit of a pain, depending what unexpected and inconvenient differences between the GL and X I/O models pop up -- in particular, how one interleaves/intermixes keyboard and mouse I/O. I'd not expect major problems here, however, just annoyances. It would be good to set up Imake as part of the Skandha4 build process when switching to explicitly linking to X -- this will greatly ease later ports to other X Window systems such as Linux, if done. After the above is working, I'd try linking against the Mesa implementation of OpenGL instead of the native SGI graphics libraries: If one got this passing selftest ok, one should have a really unix-portable Skandha4 capable of running on just about any unix system, in particular including Linux. If one then wanted to run on Windows NT, one should just write a new driver. Since Microsoft is officially supporting OpenGL on Windows, the initial port could consist mostly of rewriting the mouse and keyboard I/O yet again, to use the Windows model instead of the X model. If this is done by the person who did the port from GL to X I/O, it should be very familiar work that will go quite quickly. If the above port works and gets used heavily, you may then wind up wanting to port from OpenGL under Windows to Microsoft's Active3D (I think it is called) interface. Active3D is officially a less-ambitious interface than OpenGL, but it looks like it is becoming the interface of choice for PC 3D graphics accelleration hardware, and I wouldn't be surprised if it is also free vs Microsoft charging a fee for OpenGL, or some such: In any event, Active3D is likely to wind up more common, faster and cheaper than OpenGL on the Windows platform, I think, and to do all we really need in Skandha4 for most purposes. That should be mostly it for porting Skandha4, in a strict sense. Other useful general maintainance stuff on Skandha4 would include switching to proper ANSI C prototype declarations everywhere (instead of the current K&R C ones) and upgrading to a more recent version of the xlisp interpreter. If the latter is attempted, be wary of changes in the garbage collector, which may break Skandha4 in all sorts of hard-to-track-down ways. In particular, I believe recent versions of xlisp offer a garbage collector which shuffles objects to compact ram. If the old non-shuffling garbage collector is still available as a compile option (was last I checked), one should probably select it instead, at least as a first cut, and quite likely permanently. For general portability between unix systems, an autoconfig script which figures out what local libraries are available &tc and updates the Makefiles appropriately would be a welcome alternative to the current "systems" file approach. The GNU 'autoconfig' package can be used to generate a bourne shell script which will do this, or if one prefers something similar can probably be written more clearly and easily in Perl, at a slight loss in portability (since Bourne shell is on every Unix system, but Perl is not yet quite so universal).
Some other Skandha4 projects which might make sense;
src/slisp/xvol/c/xvol.c:xvolh2_Read_AVS_Field_From_File_Fn, in particular the SHORT_FIELD case. This entire function started out as a quick hack for a specific project, and is being gradually generalized over time to handle a wider variety of AVS fields: Lots more work could be done on this front.
(send transform :setf newval row col)call can be used to stuff any desired values into the viewing and perspective matrices, it is just a matter of deciding what values to use. The perspective transform doesn't actually have to use perspective, of course, and almost certainly should not in this case, since the photo is effectively from optical infinity and attempting to deduce and match the small degree of perspective present in the photo is very likely to do more harm than good. I believe the SGI hardware always clips to a (-1,1)^3 cube, after the viewing transform and before the perspective transform, so I think the basic task is to transform the viewing frustrum into this cube in the viewing transform, then transform this cube to screen coordinates in the perspective transform, possibly ignoring the window position and/or camera position within the window, which may be independently added in later by separate hardware.