TPortal root?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

TPortal root?

Howard Stearns
I'd like to get a better understanding of why aTPortal root is nil if  
aTPortal is in a window that is closed.

Suppose I have two TPortals linked to each other, and both appearing  
as contents of TWindows. This is the classic two-way doorway between  
spaces.
If I close the TWindow on one side, then the other TPortal renders  
invisibly. Not as a mirror back to its own space, but invisibly, as  
if the the TPortal just isn't there.

I think this is a consequence of the TPortal in the closed TWindow  
having no root, so its linked-to portal's #render:depth: doesn't know  
what to draw, and just exits from rendering early.  In a way, this  
make sense: it can't render the space if it doesn't know what space  
it's in! But it feels like a bug to me that a TPortal doesn't know  
what space its in, just because, through no fault of its own, it  
happens to be in TWindow that was closed. Closed doesn't mean "not in  
any space."

Another consequence of this is that you can't walk through a portal  
if someone closed the door on the other side.  You could argue that  
this is a feature, but I don't like it.
In fact, that's just what I was trying to do when I ran into this issue.

There's a couple of ways around this:

- A TPortal doesn't have to link to another portal. It can link to  
the TWindow on the other side. In this case, the TPortal on "my" side  
will always work, regardless of whether the TWindow on the other side  
is open or closed. So each TPortal would link to the far TWindow,  
rather than the far window's contents (a TPortal).

- I imagine that I could make TPortal retain it's root information  
regardless of whether it was an open or closed window's contents. I  
think right now, TWindow>>closeContents removes the contents as a  
child, which de-roots it.

But before futzing around, I wonder if someone can make a case for  
whether or not there's a bug here, and if so, where?

-H

Reply | Threaded
Open this post in threaded view
|

Re: TPortal root?

David A. Smith-3
Howard,

This is essentially how I designed it. The portal actually requires both
a target root and a target transform - not much more than that. Any
TFrame will do. You can even link a TPortal to an avatar and have it
follow them around.

I think having a way to "turn off" a portal on the remote side can be
useful. It doesn't have to be using the current method. I did not to
ensure that if a remote target was not found, the local TPortal acted in
an appropriate way, which is why I made them mirrors. This is an obvious
and not uncool way of showing a closed portal.

You can link to a TWindow...but remember that a TPortal has a direction
associated with it. A TPortal linked to a TPortal acts as if you are
seeing "through" one to the other. I flip the matrix for this. Just
adding the TWindow as your link will cause the TPortal to look in the
direction behind the TWindow. To fix this, simply add a TGroup to the
TWindow - offset like the TPortals are, and rotate it around the Y axis
by 180 degrees.

DAS

Howard Stearns wrote:

> I'd like to get a better understanding of why aTPortal root is nil if
> aTPortal is in a window that is closed.
>
> Suppose I have two TPortals linked to each other, and both appearing
> as contents of TWindows. This is the classic two-way doorway between
> spaces.
> If I close the TWindow on one side, then the other TPortal renders
> invisibly. Not as a mirror back to its own space, but invisibly, as if
> the the TPortal just isn't there.
>
> I think this is a consequence of the TPortal in the closed TWindow
> having no root, so its linked-to portal's #render:depth: doesn't know
> what to draw, and just exits from rendering early.  In a way, this
> make sense: it can't render the space if it doesn't know what space
> it's in! But it feels like a bug to me that a TPortal doesn't know
> what space its in, just because, through no fault of its own, it
> happens to be in TWindow that was closed. Closed doesn't mean "not in
> any space."
>
> Another consequence of this is that you can't walk through a portal if
> someone closed the door on the other side.  You could argue that this
> is a feature, but I don't like it.
> In fact, that's just what I was trying to do when I ran into this issue.
>
> There's a couple of ways around this:
>
> - A TPortal doesn't have to link to another portal. It can link to the
> TWindow on the other side. In this case, the TPortal on "my" side will
> always work, regardless of whether the TWindow on the other side is
> open or closed. So each TPortal would link to the far TWindow, rather
> than the far window's contents (a TPortal).
>
> - I imagine that I could make TPortal retain it's root information
> regardless of whether it was an open or closed window's contents. I
> think right now, TWindow>>closeContents removes the contents as a
> child, which de-roots it.
>
> But before futzing around, I wonder if someone can make a case for
> whether or not there's a bug here, and if so, where?
>
> -H
>
>
>