Thursday, September 23, 2004

Mad Hatter Fixes

There were two bugs that we found. The first was related to the fact
that the openGL texture ids were being copied to the other machine.
This meant that when the TForm - the object that holds the glID
attempted to render, it assumed that it was a valid number, and since
in fact this texture had never been instanced on this new machine, it
would fail. This was fixed (as well as the problems with TPrimitives)
by adding a fixup on the receiving side to nil out these openGL
reference values. So now the textures are properly visible.

David never actually saw this problem because he was either running
multiple versions of Croquet in the same image - hence a guarantee that
it would use the same OpenGL id, or he ran one machine as a headless
Croquet server - that is, it never actually rendered anything, and the
other rendering, hence the openGL texture id was never even set, so
when it was copied from the server to the rendering machine, the id
value was indeed nil.

The other problem has to do with the fact that the TPointer object, the
thing we use to determine what we are pointing at - is not actually
replicated. This causes some nasty issues because the TPointer queries
virtually every object at render time to determine if it is selected
or not. What we decided to do here was move all of the TRay tests out
of the rendering loop, which is actually a good thing, and move the
TPointer into the same TeaParty as the TAvatar. This leads to one other
slight complexity and that is that the TOverlaySpaces also need a
TPointer and it really can't be the same one as the replicated version,
hence every overlayed TSpace will also have it's own TPointer. The job
of the TUserCamera will be to arbitrate which of these pointers gets
the events that are sent. It is actually a bit simpler this way, though
it took a bit of thought to figure out what to do. The problem is
understanding how TeaTime and TeaParties really work.

A funny thing I found was that TWindow had a reference to a instance
value called pointerXY (which is the x,y location of the 2D cursor on
the screen), which it grabbed from the TPointer on a #pointerDown. This
was actually never used anywhere inside the TWindow, and it was the
only place that the pointerXY was ever asked for from the TPointer. I
can't imagine what I was trying to do with that value, but it is
interesting how this kind of cruft can find it's way into a system.

No comments: