glean-dev — Glean development discussions

[glean-dev] new test: logicOp

[Brian P. <br...@va...>]

I've just checked in a new RGBA-mode glLogicOp() test.  It's based
on Allen's blendFunc test.

The OpenGL conformance tests only test glLogicOp() in CI mode, not
RGBA mode, so this fills in a hole.

I added tlogicop.obj to the Windows makefile but have only tested
the code on Linux w/ gcc.  Hopefully it'll compile/run alright on
Windows.

-Brian

Re: [glean-dev] New polygon-offset test

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> On Mon, May 07, 2001 at 10:39:45AM -0600, Brian Paul wrote:
> | I fixed the failure with a one-line change to Mesa.
> 
> Great!
> 
> I'm running the DRI trunk (Mesa 3.4.1?)

Yes, the trunk has 3.4.1.

> here, so I can't do much
> debugging for 3.5 at the moment.  Are you getting 1- or 2-bit MRDs
> now?

polygonOffset:  PASS rgb8, db, z16, s8, accrgba16, win+pmap+pbuf, id 2
        Ideal  MRD at near plane is 1.52583e-05 (nominally 1 bit)
        Actual MRD at near plane is 1.5259e-05 (nominally 1 bit)
        Ideal  MRD at infinity is 1.52441e-05 (nominally 1 bit)
        Actual MRD at infinity is 1.52588e-05 (nominally 1 bit)


-Brian

Re: [glean-dev] New polygon-offset test

[Allen A. <ak...@po...>]

On Mon, May 07, 2001 at 10:39:45AM -0600, Brian Paul wrote:
| I fixed the failure with a one-line change to Mesa.

Great!

I'm running the DRI trunk (Mesa 3.4.1?) here, so I can't do much
debugging for 3.5 at the moment.  Are you getting 1- or 2-bit MRDs
now?

Allen

Re: [glean-dev] New polygon-offset test

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> On Sat, May 05, 2001 at 12:57:36PM -0600, Brian Paul wrote:
> | A quick test with Mesa 3.4 checked out OK but it failed with Mesa 3.5.
> | I'll try to fix that before the 3.5 release (hopefully next week).
> 
> It could be a bug in the test -- there were several numerical
> stability problems that I had to solve, and it's possible I didn't
> nail them all.  Let me know if the test behaves oddly.

I fixed the failure with a one-line change to Mesa.

-Brian

Re: [glean-dev] New polygon-offset test

[Allen A. <ak...@po...>]

On Sat, May 05, 2001 at 12:57:36PM -0600, Brian Paul wrote:
| A quick test with Mesa 3.4 checked out OK but it failed with Mesa 3.5.
| I'll try to fix that before the 3.5 release (hopefully next week).

It could be a bug in the test -- there were several numerical
stability problems that I had to solve, and it's possible I didn't
nail them all.  Let me know if the test behaves oddly.

Thanks,
Allen

Re: [glean-dev] New polygon-offset test

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> I've just committed a new version of the polygon offset test.  I wrote
> it for two reasons:
> 
>         The old test was extremely demanding.  While this is not
>         necessarily a bad thing, in this case all the implementations
>         I've tried failed the test.  It seemed like the right thing to
>         do was to start by loosening the test so it didn't go so far
>         beyond the requirements of the spec.

For those wondering, one of the problems was that the original test
was drawing _really_ small triangles, often less than 1 pixel in area.
It didn't seem to be a realistic test.


>         At least in the early days, a common point of failure was
>         incorrect computation of the Minimum Resolvable Difference.
>         I've incorporated code to measure the implementation's ideal
>         MRD, so that driver developers can get a clearer picture of
>         what it should be.  (In a simple unsigned-integer depth
>         buffer, it's pretty easy -- just one LSB in window
>         coordinates.  But some implementations use compressed or
>         floating-point depth buffers, and some implementations attempt
>         to fold the MRD offset into earlier stages of the pipeline, so
>         they need the additional information.)
> 
> Please give it a try and let me know if it produces unreasonable
> results.  There are a few subtle points that may need tweaking.

A quick test with Mesa 3.4 checked out OK but it failed with Mesa 3.5.
I'll try to fix that before the 3.5 release (hopefully next week).

-Brian

[glean-dev] New polygon-offset test

[Allen A. <ak...@po...>]

I've just committed a new version of the polygon offset test.  I wrote
it for two reasons:

	The old test was extremely demanding.  While this is not
	necessarily a bad thing, in this case all the implementations
	I've tried failed the test.  It seemed like the right thing to
	do was to start by loosening the test so it didn't go so far
	beyond the requirements of the spec.

	At least in the early days, a common point of failure was
	incorrect computation of the Minimum Resolvable Difference. 
	I've incorporated code to measure the implementation's ideal
	MRD, so that driver developers can get a clearer picture of
	what it should be.  (In a simple unsigned-integer depth
	buffer, it's pretty easy -- just one LSB in window
	coordinates.  But some implementations use compressed or
	floating-point depth buffers, and some implementations attempt
	to fold the MRD offset into earlier stages of the pipeline, so
	they need the additional information.)

Please give it a try and let me know if it produces unreasonable
results.  There are a few subtle points that may need tweaking.

Allen

Re: [glean-dev] Win Build

[Johan S. <joh...@po...>]

Hi,

> | 3.  I don't know why this is done, but in rc.cpp create_context()...at the
> | end it does:
> |
> |       ReleaseDC(hwnd,hDC);
> |       DestroyWindow(hwnd);
> |
> |     This was breaking it with our driver...this seems like very odd behavior
> | to send a
> | WM_DESTROY message to the window you're about to render to.  I just
> | commented
> | them out and things seemed OK, but I don't know what the intent was here.

hwnd is not the handle of the window that is rendered to. The window is
created
at the start of create_context() just to be able to create the rendering
context.
In glx the parameters of the rendering context are passed to
glXCreateContext(), but
on Windows wglCreateContext fetches them from a device context (DC). In
glean the
RenderingContext is created independently of the rendering window so a
DC of
the rendering window can't be used. Since SetPixelFormat can only be
called once
for a window, a temporary window is created and destroyed for each
RenderingContext
that is created. 
My comment above create_context() indicates that the DC passed to
wglCreateContext()
doesn't have to be the same as the one that's passed to
wglMakeCurrent().
I don't remember the exact details (It's been a while since I've done
any non-Delphi 
Windows programming) but I'm pretty confident that I read this somewhere
in the wgl* docs.

I hope this made any sense,

Johan.

Re: [glean-dev] Win Build

[Allen A. <ak...@po...>]

On Fri, Apr 20, 2001 at 10:02:35AM -0600, Brian Paul wrote:
| > I just did a cvs update and I noticed that ttexenv.cpp doesn't compile
| > for other reasons (an uninitialized constant "tex").  My guess is that
| > Brian Paul is modifying the test and it was accidentally checked-in in
| > a non-working state.
| 
| Hmmm, I didn't see that error here.  I am still working on fine-tuning
| this test though, and just checked in my latest change.  Let me know
| if the error persists.

The latest update compiles successfully for me.

Thanks,
Allen

Re: [glean-dev] Win Build

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> Hi, Daniel.
> 
> On Fri, Apr 20, 2001 at 10:10:46AM -0400, Daniel Ginsburg wrote:

> | 3.  I don't know why this is done, but in rc.cpp create_context()...at the
> | end it does:
> |
> |       ReleaseDC(hwnd,hDC);
> |       DestroyWindow(hwnd);
> |
> |     This was breaking it with our driver...this seems like very odd behavior
> | to send a
> | WM_DESTROY message to the window you're about to render to.  I just
> | commented
> | them out and things seemed OK, but I don't know what the intent was here.
> 
> The comment above that function discusses the need for creating a
> temporary window.  I gather that the window created here is not the
> one that's used for rendering; the rendering window is created in the
> constructor for the Window class in dsurf.cpp.  However, one of the
> Windows experts (Johan or Brian) could tell you more about why things
> are done the way they're done.

Brian = Brian Sharp, BTW.



> I just did a cvs update and I noticed that ttexenv.cpp doesn't compile
> for other reasons (an uninitialized constant "tex").  My guess is that
> Brian Paul is modifying the test and it was accidentally checked-in in
> a non-working state.

Hmmm, I didn't see that error here.  I am still working on fine-tuning
this test though, and just checked in my latest change.  Let me know
if the error persists.

-Brian

Re: [glean-dev] Win Build

[Allen A. <ak...@po...>]

Hi, Daniel.

On Fri, Apr 20, 2001 at 10:10:46AM -0400, Daniel Ginsburg wrote:
| 
| 1.  Timer.cpp doesn't compile  - the "#include"'s need to go before "using
| namespace std;"

Done.  (Seems to work OK either way under gcc, but there are known
differences in the way the STL is implemented under Windows and the
GNU environment, so this is no surprise.)

| 2.  ttexenv.obj,ttexcombine.obj (and possibly others, didn't look that
| carefully) are not
|      linked in in Makefile.win

Sorry about that.  The gnumake makefiles detect new source files
automatically, but the Windows makefiles are maintained by hand, and
sometimes things are left out.  We don't catch them if no one is
compiling regularly for Windows.  I've added the two you mentioned,
also tbasicperf.obj, tpaths.obj, tpgos.obj, tscissor.obj,
ttexcube.obj.

| 3.  I don't know why this is done, but in rc.cpp create_context()...at the
| end it does:
| 
| 	ReleaseDC(hwnd,hDC);
| 	DestroyWindow(hwnd);
| 
|     This was breaking it with our driver...this seems like very odd behavior
| to send a 
| WM_DESTROY message to the window you're about to render to.  I just
| commented
| them out and things seemed OK, but I don't know what the intent was here.

The comment above that function discusses the need for creating a
temporary window.  I gather that the window created here is not the
one that's used for rendering; the rendering window is created in the
constructor for the Window class in dsurf.cpp.  However, one of the
Windows experts (Johan or Brian) could tell you more about why things
are done the way they're done.

| 4.  ttexenv.cpp/ttexcombine.cpp don't compile...one reason is
| GL_RGB_DOT3_EXT/GL_RGBA_DOT3_EXT
| were missing from the glExt.h I got from the web page.  ...

Shouldn't those be GL_DOT3_RGB_EXT and GL_DOT3_RGBA_EXT?

I just did a cvs update and I noticed that ttexenv.cpp doesn't compile
for other reasons (an uninitialized constant "tex").  My guess is that
Brian Paul is modifying the test and it was accidentally checked-in in
a non-working state.

|                                                    ...  The other problem is
| that in RunMultitextureTest()
| in ttexcombine.cpp does:
| 
|    for(int u = 0; ...)
| 
| several times in a row.  MSVC++ complaines that "u" is being
| redefined...apparently this is a
| MS compiler-ism, but it should just be changed to declare u only once.

Yeah, this is a known problem with VC++; it doesn't implement the ANSI
local-loop-variable semantics.  I changed the code.  Please let me know
if I missed any cases.

Thanks for the report,
Allen

[glean-dev] Win Build

[Daniel G. <DGi...@at...>]

Hey folks,

I tried building the latest glean code for Windows (so I could run the
texenv test) and
ran into a few problems:

1.  Timer.cpp doesn't compile  - the "#include"'s need to go before "using
namespace std;"

2.  ttexenv.obj,ttexcombine.obj (and possibly others, didn't look that
carefully) are not
     linked in in Makefile.win

3.  I don't know why this is done, but in rc.cpp create_context()...at the
end it does:

	ReleaseDC(hwnd,hDC);
	DestroyWindow(hwnd);

    This was breaking it with our driver...this seems like very odd behavior
to send a 
WM_DESTROY message to the window you're about to render to.  I just
commented
them out and things seemed OK, but I don't know what the intent was here.

4.  ttexenv.cpp/ttexcombine.cpp don't compile...one reason is
GL_RGB_DOT3_EXT/GL_RGBA_DOT3_EXT
were missing from the glExt.h I got from the web page.  The other problem is
that in RunMultitextureTest()
in ttexcombine.cpp does:

   for(int u = 0; ...)

several times in a row.  MSVC++ complaines that "u" is being
redefined...apparently this is a
MS compiler-ism, but it should just be changed to declare u only once.

After changing all this stuff, I got the texenv test to work fine.

-- Dan

Re: [glean-dev] New glean test: texEnv

[Gareth H. <ga...@va...>]

Allen Akin wrote:
> 
> On Thu, Apr 19, 2001 at 11:16:10AM -0600, Brian Paul wrote:
> | I basically got tired of manually running and inspecting the
> | Mesa/demos/texenv program so decided to write an automated test.
> 
> I know the feeling. :-)

Yep, same here :-)

-- Gareth

Re: [glean-dev] New glean test: texEnv

[Allen A. <ak...@po...>]

On Thu, Apr 19, 2001 at 11:16:10AM -0600, Brian Paul wrote:
| I basically got tired of manually running and inspecting the
| Mesa/demos/texenv program so decided to write an automated test.

I know the feeling. :-)

Thanks for the new test!

Allen

Re: [glean-dev] New glean test: texEnv

[Brian P. <br...@va...>]

Brian Paul wrote:

> I basically got tired of manually running and inspecting the
> Mesa/demos/texenv program so decided to write an automated test.

Oh, another motivation was the fact the OpenGL conformance tests
don't exercise some texture formats or env modes at all.

-Brian

[glean-dev] New glean test: texEnv

[Brian P. <br...@va...>]

I've just committed a new Glean test called texEnv (ttexenv.cpp).
It loops over all the texture env modes (REPLACE, MODULATE, BLEND,
DECAL, ADD) and base texture format (ALPHA, LUMINANCE, LUMINANCE_ALPHA,
INTENSITY, RGB and RGBA) and makes sure that texturing produces the
right color.

For each mode and format combination I setup a texture that has
81 columns of unique colors (3 red * 3 green * 3 blue * 3 alpha).
I then draw 81 flat-shaded quads as horizontal bands up the window.
This results in 81 * 81 = 6561 color combinations per mode/format
combination.  For the BLEND tex env mode the test also varies the
texture env color.

Finally, I'm using blending over a gray background to test that
the post-texture alpha value is correct.  In total, 695466
combinations are tested.

I basically got tired of manually running and inspecting the
Mesa/demos/texenv program so decided to write an automated test.

-Brian

Re: [glean-dev] [Fwd: A request with regard to Glean for windows]

[Allen A. <ak...@po...>]

On Thu, Mar 29, 2001 at 10:50:58PM +0200, Johan Smet wrote:
| I took a quick peek at the sourcecode and I think changing the 
| #include "vector.h" to #include <vector> should fix his problems.

Thanks; I've made the same fix in the tree.

Allen

[glean-dev] [Fwd: A request with regard to Glean for windows]

[Johan S. <joh...@po...>]

Hi all,

I just received this e-mail. 
I took a quick peek at the sourcecode and I think changing the 
#include "vector.h" to #include <vector> should fix his problems.
I've already suggested this to the original author of the message.

Johan.

Reza Nezami wrote:
> 
> Hi Johan,
> I'm not sure this question should be addressed to you, but give it a try. I
> am trying to compile
> glean for windows. Needless to say I do my best to follow the guidline given
> on the web page for this
> procedure. The compilation goes ok until at timer directory. Here in
> time.cpp there is an iclude for
> vector.h. Well, the compiler is not able to find this header file. I have
> searched in STLport-4.0 and
> there is only two occurance of vector.h at BC50 and oldHP subdirectories and
> both are diferenet and
> none of them solves the problem anyway. They are not even where they
> supposed to be. I don't know if
> there is something I am missing or ...?
> 
> I appreciate very much your opinion. My email is rn...@ma...
> 
> Thank you very much
> Reza

[glean-dev] [glean-announce] Problem with compiling glean on win32

[Reza N. <Rez...@Ma...>]

Hi guys,
I've been getting compiling error messages related to not finding the header
files. It specifically stops at timer directory not being able to find
vector.h.
Well, there are only a couple of spots in STLport where one can find this
file.
These are BC5 and oldHP directories somewhere down in STLport. I don't think
time.cpp
is looking for any of these two vector.h, since I've tried them both.
I'll be greatful for any suggestion. I'm running win2k and using vc++
version 6.


Thanks.

Reza Nezami, Software Designer, Matrox Graphics Inc.
Tel: (514)822-6000 +2063, Fax: (514)685-7030


_______________________________________________
glean-announce mailing list
gle...@li...
http://lists.sourceforge.net/lists/listinfo/glean-announce

[glean-dev] new test: texCube

[Brian P. <br...@va...>]

I've just checked in two new files, ttexcube.cpp and ttexcube.h, that
test the GL_ARB_texture_cube_map extension.  It's pretty simplistic
at this point but I plan to add more to it in the not too distance future.

-Brian

Re: [glean-dev] Possible Bug Found

[Allen A. <ak...@po...>]

On Mon, Mar 12, 2001 at 02:03:28PM -0600, Jeffrey Mehlhorn wrote:
| 
|                                            ...  You
| response got me curious, so I took a closer look to
| see what was going on.  What I saw, was that the test
| does in fact draw the swirl five times, but only one
| swap buffer call occurs once prior to the initial
| call to glReadPixels().  ...

That's not what I would have expected, so I looked into it again. 
(The code is pretty hard to follow because not all of it is in one
place.) Here's what happens during the core of the test:

    1.  Each test case calls the measure() member function (e.g. 
	coloredLit_imIndTri.measure).  As we'll see below, this member
	is inherited from GLEAN::Timer.

    2.  The measurement class (e.g.  coloredLib_imIndTri) is derived
	from TvtxBaseTimer, and overrides the op() member function. 
	op() performs the actual drawing operation
	(glBegin/glVertex/glEnd, etc.).

    3.  TvtxBaseTimer is derived from GLEAN::Timer.  It overrides some
	member functions in GLEAN::Timer as follows:

	premeasure() clears the back buffer, swaps, and clears the
	new back buffer.

	postmeasure() swaps.

	preop() waits for the system to settle (env->quiesce()) and
	then waits for the graphics pipeline to settle (glFinish()).

	postop() waits for the graphics pipeline to settle
	(glFinish()).

    4.	GLEAN::Timer::measure() boils down to this:

	a.  Calibrate the timer.  This involves invoking preop(), then
	    invoking postop() enough for several clock ticks to pass. 
	    From this we can figure out what postop() costs.

	b.  Invoke premeasure().

	c.  For each trial (5 in our case),

		preop();
		time();
		postop();

		and record the resulting measurements.

	d.  Invoke postmeasure().

	e.  Return summaries of the measurements.

    5.	The GLEAN::Timer::time() member function does this:

    		preop();
		invoke op() many times;
		postop();

	each time increasing the number of times op() is invoked
	until enough runtime is accumulated to get an accurate
	estimate of the cost of a single invocation of op().

So, putting it all together, we should see something like the
following OpenGL calls for each test:

	Lots of glFinish (from invoking postop() during calibration)
	glClear, swap, glClear (from invoking premeasure())
	Five repetitions (one for each trial) of:
		One or more repetitions of:
			glFinish (from preop())
			One or more glBegin/.../glEnd sequences (from op())
			glFinish (from postop())
	swap (from postmeasure()
	glReadPixels

It sounds like that matches what you're seeing.

I was confused in my previous note because I had only skimmed the
comments in timer.h, which say that postmeasure() is invoked after
time().  I misinterpreted that to mean after *each* invocation of
time(), when in fact it's only after *all* invocations of time(). 
Nearly all of us running glean have hardware that swaps by copying, so
we never noticed it.

So, the bottom line is thanks for finding the problem, and pursuing it
all the way to a complete fix!

| As an aside, I noticed something that seemed odd when
| I captured a trace of the OpenGL calls being made by
| glean.  When the test, coloredTexPerf, starts up, there
| are several concurrent calls to glFinish() made with
| apparently no OpenGL calls made between.  By several,
| I mean that there were hundreds of concurrent calls to
| glFinish().

That's probably from the calibration phase (step 4a above).

Allen

RE: [glean-dev] Possible Bug Found

[Jeffrey M. <Jef...@3D...>]

Allen,

Thank you for the timely response to my email.  You
response got me curious, so I took a closer look to
see what was going on.  What I saw, was that the test
does in fact draw the swirl five times, but only one
swap buffer call occurs once prior to the initial
call to glReadPixels().  I see five sets of being/end
pair, followed by a swap buffers, followed by a battery
of glReadPixels().

This may explain better why the image data was incorrect
when the read buffer was set to GL_BACK by default.

As an aside, I noticed something that seemed odd when
I captured a trace of the OpenGL calls being made by
glean.  When the test, coloredTexPerf, starts up, there
are several concurrent calls to glFinish() made with
apparently no OpenGL calls made between.  By several,
I mean that there were hundreds of concurrent calls to
glFinish().

This is not necessarily a problem for the driver, because
when glFinish is called and there is nothing pending,
we simply do some pointer house keeping and return, but
the sheer number of back to back glFinish calls seemed
a bit odd.

Thank you for looking into the glReadBuffer issue for me.

Jeff

-----Original Message-----
From: Allen Akin [mailto:ak...@po...]
Sent: Friday, March 09, 2001 4:12 PM
To: gle...@li...
Subject: Re: [glean-dev] Possible Bug Found


On Fri, Mar 09, 2001 at 02:46:32PM -0600, Jeffrey Mehlhorn wrote:
| 
|     The test appears to draw a blue swirl to the back,
|     swap the buffers, and then read the image using
|     glReadPixels.  By not explicitly setting the read
|     buffer to GL_FRONT, the default mode is used and
|     glReadPixels will be reading undefined data from
|     the back buffer.

It's a little more complicated than that.  Each measurement is made
five times, with a buffer swap each time.  So unless you have
multibuffering with more than four back buffers, the front and back
buffers will contain the same image by the time glReadPixels() is
executed.  If you're seeing a failure because of this, it would be
good to know more about the situation.

You have a good point, though, even if it shouldn't make a difference
in practice.  I've made the one-line change to each test so that they
now read from the front buffer.

|     Please let me know when the glean source tree has
|     been updated to incorporate a fix for this bug.

You know, you're welcome to become a glean developer.  Then you could
make fixes like this without having to wait for someone else.  :-)

Allen

_______________________________________________
glean-dev mailing list
gle...@li...
http://lists.sourceforge.net/lists/listinfo/glean-dev

Re: [glean-dev] Possible Bug Found

[Allen A. <ak...@po...>]

On Fri, Mar 09, 2001 at 02:46:32PM -0600, Jeffrey Mehlhorn wrote:
| 
|     The test appears to draw a blue swirl to the back,
|     swap the buffers, and then read the image using
|     glReadPixels.  By not explicitly setting the read
|     buffer to GL_FRONT, the default mode is used and
|     glReadPixels will be reading undefined data from
|     the back buffer.

It's a little more complicated than that.  Each measurement is made
five times, with a buffer swap each time.  So unless you have
multibuffering with more than four back buffers, the front and back
buffers will contain the same image by the time glReadPixels() is
executed.  If you're seeing a failure because of this, it would be
good to know more about the situation.

You have a good point, though, even if it shouldn't make a difference
in practice.  I've made the one-line change to each test so that they
now read from the front buffer.

|     Please let me know when the glean source tree has
|     been updated to incorporate a fix for this bug.

You know, you're welcome to become a glean developer.  Then you could
make fixes like this without having to wait for someone else.  :-)

Allen

[glean-dev] Possible Bug Found

[Jeffrey M. <Jef...@3D...>]

    Glean Developers,

    I have uncovered what I believe to be a bug in two
    of the Glean test.  The test are coloredLitPerf and
    coloredTexPerf.

    I have not performed an exhaustive review of the
    test code, but it appears that both of these test
    use the defaults for glDrawBuffer and glReadBuffer.

    For glReadBuffer, the default mode is GL_BACK when
    the buffer configuration is double-buffered.

    The test appears to draw a blue swirl to the back,
    swap the buffers, and then read the image using
    glReadPixels.  By not explicitly setting the read
    buffer to GL_FRONT, the default mode is used and
    glReadPixels will be reading undefined data from
    the back buffer.  There in lies the bug.

    Please let me know when the glean source tree has
    been updated to incorporate a fix for this bug.

    Jeff

[glean-dev] Mac port and questions

[Kent M. <kpm...@ap...>]

Hi,

I have succeeded in porting glean to MacOS 9 and have a question about some
modifications I had to make to the sources.  This may actually be a C++
question; I'm not sure.

I can not get the Metrowerks compiler to digest the use of the definition of
the input and output streams in the test.  The only way I have been able to
get it to work is to make the definition of the stream public; ie change
from this:

class OutputStream {
    ofstream* s;
    public:
    OutputStream(Test &t);

Etc

To this:
class OutputStream {
    public:
    ofstream* s;
    OutputStream(Test &t);

Failure to do this results an a compiler error of "illegal access to
protected/private member".

I also have to access the streams like this:

r->put(*os.s);  instead of r->put(os);

Can anyone either tell me what I'm doing wrong or suggest a better
workaround than this?  I'd also like to talk to someone about any interest
of integrating the port into the sources.

Thanks,

Kent

-- 
Kent Miller                             OpenGL
Software Engineer         Apple Computer, Inc.