I have been working on devising a message passing system using shared memory(it would also work with files or networks) to communacate between the multiple parts of CGUL. I settled on a system to takes a chunk of shared memory and divides it up into lines each of which represent a single command. I thought about trying to move entire chunks of data back and forth via some kind of packet structure but I don’t know how well that will work in what is going to be a real time application. Each unique line will contain a semi-unique transaction ID number(roll over will be permitted over the life of the program but all numbers of pending and open commands will be unique). The memory region set aside for communication will be accessed by 2 pointers for each application.
For example DEACCON will contain a write pointer that starts at the begining of the file and inserts commands. This pointer will advance over the allocated memory until it reaches the end of allocated memory at which point it will roll back to the start of the assigned memory. At no point will the write pointer move into or past the reading pointer. The reading pointer will start at the begining of the assigned memory and wait on each command until the command has been executed and replaced with an “ack” signal from the visualalizer program at which point this pointer will advance. At no point will the read pointer move into or past the write pointer. Commands will be processed in the order that they are recieved by the visualizer program. The amount of allocated memory lines cannot exceed the size of integer else I would potentially run out of unique command ID’s.
Commands will be of the following form:
CommandID(int), Command(string or char[]),Command Parameters
The following commands are planned(assume each would have an ID int in front of them):
Lock –Locks the display causing it to throw up a loading screen.
Unlock — Causes the display to render again
AObject, OID — Adds object
DObject, OID — Deletes object
CObject, OID — Clears the Vertexs of an object
AVert, OID, TypeV, Vertex info — Adds a Vertex
AVertL, OID, TypeV, Number of Verts, Vertex Info –Adds a list of verts
AFace, OID, TypeV, Number of Verts, Vertex Info — Adds a face to the specified object
Trans, OID, X,Y,Z — Transforms object
Scale, OID, X,Y,Z –Scales Object
Rot, OID, W, X, Y, Z — Rotates object using Quaternion
Load, FileName –Loads the specified file. File loader will be determined by the visualizer based on the extension of the file. Geometry will automatically be rendered. –This will need to return something more than a simple “ack”.
Vtype = The types of Vertex Format defined in the red book(Position, PositionColored, ect)(int)
OID – Object ID Number(double)
Right now everything is in asci for the ease of debugging but a parrallel binary format should be trivial to debug since each component of a command can be defined to be a specific size and then encoded into a binary format.