Glen Martin's Unofficial POV-Ray Page: Status of OpenVMS Port The latest version of POV-Ray currently available for OpenVMS is v2.0 (available on the OpenVMS Freeware CD as well as all web sites offering FTP mirrors of the CD. Due to the wealth of new features available in v3.0, including improved halo and luminosity support, as well as TrueType font manipulation, I took it upon myself to attempt to port v3.0 to OpenVMS. I successfully ported the LIBPNG and ZLIB portions of the UNIX distribution. These libraries build without modification under OpenVMS, although the ZLIB test utility MINIGZIP.EXE will not build without the presence of the XVSUTILS library, which I have not installed. This failure is of no consequence to the overall build. However, when it came time to tackle the meat of the program itself, I ran into several brick walls, resulting in the port being placed on the back burner while I took care of more pressing duties. To kick off the New Year, I decided to revisit this porting effort. Luck was with me, for while searching the web with AltaVista, I came across a set of instructions for building POV-Ray v3.0x under OpenVMS/Alpha written by Carl D. Perkins of Texas A&M University. Following the instructions, I was able to build v3.02 with nary a problem (see errata below). The instructions are worthwhile reading even for those not needing POV-Ray, for they contain many excellent insights into the challenges of building supposedly "portable" code under OpenVMS. Mr. Perkins' instructions apply to the Unix source code obtainable from the POV-Ray web site: * Unix Source Code (povuni_s.tgz - 731kB) * Documentation and Sample Scene Files (povuni_d.tgz - 1.3 MB) I have also been contacted by a Mr. Magnus Toneby, who has also managed to port POV-Ray v3.x to OpenVMS, VAX and Alpha. It seems that the code changes needed to get around the VAX's lack of IEEE floating point support are not that major. Furthermore, the "#while" bug described below by Mr. Perkins was not evident in Mr. Toneby's build of v3.02, although Mr. Toneby is not certain whether this is due to bug fixes made in the v3.02 incremental release or whether it is due to modification made during the porting process. (I have not yet verified whether or not my build of v3.02 exhibits this bug.) Mr. Toneby has set up a web page on his porting efforts with a link to a zip file containing various MMS config files and diffs of modified files. (Of interest to me on another front, it seems that a friend of his has successfully ported the GIMP (GNU Image Manipulation Program) to OpenVMS, something which I have been trying to accomplish for the last few weeks.) Also, Fred Kleinsorge, the DIGITAL employee who did the v2.0 port which appears on the OpenVMS Freeware CD, has contacted me for more info on these efforts. He has expressed an interest in seeing to it that the next Freeware CD includes the latest version of everyone's favorite ray-tracer... ------------------------------------------------------------------------ Errata to Mr. Perkins' Instructions I encountered two minor errors in the instructions, which may be due to the fact that two incremental maintenance releases of POV-Ray have been issued since the instructions were written. * Instructions for fixing a typo in GIFDECOD.C (incorrectly referred to in the instructions as GIFDECODE.C) may be ignored, as the typo has been corrected in the current distribution. * The CC statement for what Mr. Perkins refers to as "Group 4, object types and whatnot" omits BCYL.C in the list of modules to be compiled. I emailed Mr. Perkins to thank him for producing the build instructions, as well as to point out the errors noted above. He replied with the following message, confirming the noted errata, as well as a few addional problems, particularly a potentially serious problem related to file formats. Read on: ------------------------------------------------------------------------ Additional Errata from Carl Perkins I have looked at this. You are correct - both of the things you mention are due to the newer version (except the mistake of saying GIFDECODE.C when it is really GIFDECOD.C). There was no BCYL.C file in 3.00a - I assume this is a new feature that has some objects' bounding object be a cylinder in addition to the box and sphere that used to be used. I also have some additional information that may prove useful, including a bit of errata to my instructions and some things I didn't notice until after I sent in my porting notes (I told Andreas Dilger I'd update them, but that was about a year and a half ago and I havn't sent him an update yet). I will append my file of additional info to the end of this message. --- Carl In sections 1B and 2B I say you can delete more than you really can. Andreas Dilger pointed out this problem: "Actually, you still need to keep zconf.h and pngconf.h in addition to the zlib.h and png.h files." There is a bit of a problem that is not addressed in the current version of the instructions on building POV for OpenVMS. Specifically, in two cases the input file type has to be one of the stream record formats rather than the default variable length record format. These cases are for POV files, and include files, that use the "#while" loop statement and for any TrueType font files. There are various ways to get this to work, but I think this is the easiest way to do the conversion of existing files. You can put the following in a file, say STREAM_LF.FDL. SYSTEM SOURCE "OpenVMS" FILE ORGANIZATION sequential RECORD BLOCK_SPAN yes CARRIAGE_CONTROL carriage_return FORMAT stream_LF SIZE 0 Then you do a $ CONVERT/FDL=STREAM_LF.FDL INPUT.FILE OUTPUT.FILE (I'd just use the same output file name as the input file and the PURGE the old version away.) I believe you can change the "stream_LF" on the FORMAT line to be "stream" or "stream_CR" if you have a need to do so - this changes the record delimiter from a line feed (LF) to a CR LF pair (CR = carriage return) or just a CR. This may be necessary if you transport your POV files to other platforms that want a record delimiter other than an LF. If you are wondering, the source of this problem is that the while looping uses an fseek() function to get back to the line in the file with the #while on it when the #end at the end of the loop is hit. Yes, the lines in the file are actually read back in every time the loop is processed. This fseek() wants to use the actual byte offset in the file at which the #while is located. Unfortunately this function only has byte-level access when using the various stream record formats, the default variable length record format only gives it the ability to position to the start of each record. To prevent needing to convert the record format in the future, I'd suggest making a template file with any things in it that you usually put in your POV files, then run the convert on it. In the future, when you create new files start by copying the template file rather than starting each from nothing. This will make them all be in the proper format so that you don't get hit by the while loop problem. All of the editors on VMS will preserve the record format (well, all of the ones I've used - EDT, EVE, and LSE) so editing the files isn't a problem once they are in the right format. Also, there was a bug in version 3.00a. I don't know if this is corrected in any of the newer versions. The bug turns of the ability to use #declare statements after it encounters some types of statements including a color map, which is where ran into it. The parsing of some statements turns off the the parsing of #declare type statements. This is supposed to be turned back on after such a statement is done being parsed, but in one or more cases it fails to do so, causing all #declare statements fail to work until it encounters a statement type that turns off such processing and then correctly turns it back on when that statement is done being parsed. I had a while loop in a union which used a #declare to increment the counter controlling the loop. If you hit the bug, the declare is not allowed. The bug is in the PARSE.C file. If you check that file for the section starting with "CASE (COLOUR_MAP_TOKEN)" and that CASE has an "Ok_To_Declare = FALSE" at the start of it but has no corresponding "Ok_To_Declare = TRUE" at the end of that CASE then you have a version with the bug. The fix is to put an "Ok_To_Declare = TRUE" at the end of the "CASE (COLOUR_MAP_TOKEN)" section. Likewise this should be done at the end of any other section that sets it to FALSE. ------------------------------------------------------------------------ Return to Glen Martin's Unofficial POV-Ray Page ------------------------------------------------------------------------ This page was last updated on 22-JAN-1998. Send e-mail to glenmark@utxvms.cc.utexas.edu.