On Mon, 4 Oct 1999, Andreas Beck wrote:
> BTW: When designing new 3D ioctls, could you check with Jon and me ?
> We probably have manuals for other designs at hand and it might be helpful
> for finding a really generic interface.
I sure can. But this means that we're gonna try to create a chipset
independent 3D ioctl set after all ? IIRC this mailinglist once said that
this was not done, for chipsets differ too much. I think the 3D basics can
be done by generic ioctl.
First thing to get anything working is that I must be able to pass 3D
points, lines and triangles through the ioctl interface, so I think I'll
start with proposing some definitions in kgicon/include/kgi/kgi_commands.h:
struct kgi_3dpnt {int x,y,z; };
struct kgi_3dline {int x,y,z,w,h,d};
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
Problem I got with these is that 3dline uses width heigth depth (relative
endpoint) while 3dtriangle uses absolute coordinates. Question: Is it OK
that the Z value is an integer ?
Second thing I have been thinking about is that the current interface
doesn't work with ping pong buffers: Colours are not modified by an IOCTL,
but by reading the colours from the struct kgi_graphic, that is passed to
the kgim_accel_command procedure. If ping pong buffers are used, there may
be a huge delay between the moment the command is loaded into the PP
buffer, and the moment the kgim_accel_command is called. (For the PP
buffer is filled completely first). The value of gr->gc->fg_color is
rather undefined when kgim_accel_command is called, for it may have been
modified by other commands.
My conclusion here is that there must come something like ACCEL_SETCOLOR.
Maybe not only foreground and background colours, but also fogging, light
colours ?
----
Next I've been thinking about is that there are missing
"ACCEL_SETCLIPPINGRECT" and "ACCEL_RESETCLIPPINGRECT", for the
accellerator engine must know the clipping region too.
----
I was also thinking that it is a pity that there is a KGICOMMAND for
standard 2D lines and 2D boxes, but that we need another KGICOMMAND for
the same 2D lines and 2D boxes with ROP (those logical operations) or
bit/pixmaps. I think it is okay that the bit/pixmaps drawing remains
separated, but a normal line is nothing but a line with the correct ROP
I saw some logical operation definitions somewhere in a GGI header file (I
forgot where). I think it is a pity that the defined numbers don't match
the ROP numbers.
----
Phew... it seems it is time to stop thinking...
Comments please !
Jos
