GUI to POV communications

GUI<-->POV Communications, or what to do if you hate MUI.

Read the 'amiga.h' file from the main POV-Ray sourcecode.

When the POV-Ray binary is called with the single argument "GUI", it runs in a GUI-specific mode. It opens a messageport "POV-Render", initializes message structures, and finally searches for a messageport "POV-GUI", sending it a RENDERREADY message. The POVMessage->Data field is filled in with the name of the messageport set up by POV-Ray. This does little now ("POV-Render") but will allow for multiple renderers in the future.

From this point it works normally, with two exceptions:

-All output streams to console are redirected and sent as messages to "POV-GUI".
-POV-Ray responds apppropriately to PAUSERENDER, STOPDISPLAY, and STOPRENDER messages sent from the GUI.
When rendering is complete, POV-Ray sends RENDERDONE message, waits for reply, then exits.

Handshaking on these messages is fairly loose, replies to line-by-line status updates is not expected. The only reply that POV-Ray will wait for is the acknowledgement of RENDERDONE, and the onyl reply that the GUI can expect to receive from POV-Ray is a RENDERREADY when POV-Ray is begun. POV-Ray WILL send other messages in direct response ot messages from the GUI, such as PAUSE and UNPAUSE, and STOPDISPLAY, but these come in the form of STATUSMSG messages to allow the GUI to give a visual feedbakc to the user as to when PAUSE and UNPAUSE actually occur. (since it is very possible that POV-Ray will not act on them immediately after being sent)

I've fixed the +X setting (# pixels between message checks) at 10 in the .ini file generated by the GUI. This can be overridden by a .ini file parsed later.

I've now added a display mode, "+DM" ('M' for 'message') that will send the display information through to the GUI as message packets. When POV-Ray wants the display initialized, POVMessage->Command is set to DISPLAYDATA, and POVMessage->Data is set to "S {width}|{height}|{palette}". If the user selects a palette option then the character specified is placed as the last character in the POVMessage->data string. For each pixel to display, Command is DISPLAYDATA, and Data is "P {red} {green} {blue} {x} {y}". Rectangle (mosaic preview) and Box (show vistabuffer) are the same, except Data is "R..." or "B...", and x1,x2,y1,y2 values are sent. My GUI currently does not support this (I see no reason, but it was so simple to implement) but the capability is there. Theoretically, the GUI mode could be used by ANY front-end, including an AREXX script.

Message Handling:

Messages are created with "newmsg=(POVMessage *) AllocVec(sizeof(POVMessage),MEMF_CLEAR|MEMF_PUBLIC);" and the memory allocated for them must be free'ed by the receiver of the message. If you write a GUI, your GUI must FreeVec() any messages it receives, and must NOT access the memory of a message once that message has been sent to POV-Ray itself. This approach is necessary in order to allow POV-Ray to process messages as it is able to read them in, and to prevent POV-Ray from needing to wait() for replies from the GUI before proceeding. This would be eslecially devastating to the render speed if the GUI display option is in use...

If you intend to write a custom GUI interface of some sort, contact Joel NewKirk at newkirk@snip.net and I will assist in any way I can with your efforts.