Re: Sort of a not really a potential bug report. -ish.
- From: Andre Majorel <amajorel@xxxxxxxxx>
- To: yadex@xxxxxxxxxxxxx
- Date: Wed, 19 Nov 2003 18:23:11 +0100
On 2003-11-19 15:54 +0100, ras2 wrote:
> On 2003-11-19 at 13:24:39 +0100, Andre Majorel <amajorel@xxxxxxxxx> wrote:
> > On 2003-11-19 02:34 +0100, ras2 wrote:
> >
> > > If you look at linedef #1051 in linedef mode, you'll see that it's
> > > drawn as two-sided despite only having one sidedef and if you look
> > > at it in sector mode, it's drawn as if it doesn't belong to sector
> > > #1 (and in blue too where the rest of the sector's linedefs are in
> > > green).
> >
> > That's because it's superimposed with linedef 1184, which is
> > double-sided.
>
> hmm. 1051 and 1184 run parallel to each other and are separated by 24
> units, so I don't see how they can be superimposed?
Sorry, make that 1185.
> Which double-sided linedef?
#1184^H5.
> > a) Change the order in which objects are drawn (or highlighted)
> > so that the highlight matches the display. One bad side-effect
> > of doing this is that it would remove the only hint that you
> > have superimposed linedefs.
>
> That wouldn't be nice.
Attached is a patch against 1.6.0 that does that for vertices,
linedefs and things. Apply it and look at your level. :-)
> There are no doubt situations where it would be most useful to be
> shown the oldest object, but I'd think that the current method is
> the one that is most often appropriate.
Not sure what you mean by "the current method".
> If that's the case, might it be possible, and better, to use some symbol
> on the map to show superimposed objects? Then one would know where they
> are and could just shuffle linedefs in the usual manner to get at them.
Yes, possibly. But I'm afraid it might be even more CPU
-intensive than multiple info boxes. At a zeroth approximation,
the latter is a plain O(n) scan, and the former involves at the
minimum allocating and sorting (O(n log n)) a table of size n.
Doesn't seem like a good idea to put that in draw_map().
> > The code that handles joining sectors rarely does the right thing. I
> > know I nearly always end up having the fix the linedef properties by
> > hand.
>
> yeah. Is it possible that it has gotten worse? I'm seeing some rather
> peculiar choices being made sometimes and I don't remember them being
> quite as odd in the past.
Not that I remember. As I recall, it's always been weird.
> > > The error can be fixed by collapsing the linedef and making a new,
> > > but I thought you should see it (also because it reminds me of an
> > > error I had in 1999 or so which you said wasn't possible. So there).
> >
> > Oh yes, the time when I said something about usage of illegal
> > substances. :->
>
> Watch it, dood. I have a flattened lemur and I'm not afraid to use it.
>
> It was in 2000 and sort of the opposite of this; I had a two-sided linedef
> that was shown as impassable (white) when it wasn't and you just went on
> about how it wasn't possible because of some stuff in the code and whatnot
> and yet I had that great and terrible white linedef right there, staring
> me right into my bloodshot eyes and defying me to deny its existence.
> It was quite traumatic, I tell you.
Looking in my archives, I think the reason we never solved that
issue is that you tried dragging the vertices, but not *changing*
them. Just dragging won't do a thing if the linedefs share the
same vertices. Mmm, I guess I should call those guys in white
coats back.
--
André Majorel <amajorel@xxxxxxxxx>
http://www.teaser.fr/~amajorel/
When the pointer is over more than one object, return the
highest-numbered one, instead of the lowest-numbered one as was done
until now.
This is to help dealing with superimposed objects. The highlight (and
hence the info box) will now match the display (that always shows the
highest-numbered object). An unfortunate side-effect is that this makes
it harder to see that you have superimposed objects.
This patch only affects vertices, linedefs and things. For sectors, the
code hasn't changed.
-- AYM 2003-11-19
diff -ur yadex-1.6.0/src/x_hover.cc yadex-1.6.0-highlight-highest/src/x_hover.cc
--- yadex-1.6.0/src/x_hover.cc 2003-03-28 13:37:32.000000000 +0100
+++ yadex-1.6.0-highlight-highest/src/x_hover.cc 2003-11-19
15:43:04.000000000 +0100
@@ -48,6 +48,14 @@
radius = INT_MAX;
inside = false;
}
+ bool operator== (const Close_obj& other) const
+ {
+ if (inside == other.inside
+ && radius == other.radius
+ && distance == other.distance)
+ return true;
+ return false;
+ }
bool operator< (const Close_obj& other) const
{
if (inside && ! other.inside)
@@ -68,6 +76,10 @@
return radius < other.radius;
}
+ bool operator<= (const Close_obj& other) const
+ {
+ return *this == other || *this < other;
+ }
Objid obj;
double distance;
bool inside;
@@ -218,7 +230,10 @@
else
dist = fabs (x0 + ((double) dx)/dy * (y - y0) - x);
}
- if (dist < object.distance && dist <= mapslack)
+ if (dist <= object.distance /* "<=" because if there are superimposed
+ linedefs, we want to return the
+ highest-numbered one. */
+ && dist <= mapslack)
{
object.obj.type = OBJ_LINEDEFS;
object.obj.num = n;
@@ -230,6 +245,7 @@
return object;
}
+
/*
* get_cur_sector - determine which sector is under the pointer
*/
@@ -351,7 +367,9 @@
&& x < Things[n].xpos + current.radius
&& y > Things[n].ypos - current.radius
&& y < Things[n].ypos + current.radius;
- if (current < closest)
+ if (current <= closest) /* "<=" because if there are superimposed
+ things, we want to return the
+ highest-numbered one. */
closest = current;
}
}
@@ -387,7 +405,10 @@
|| Vertices[n].y > ymax)
continue;
double dist = hypot (x - Vertices[n].x, y - Vertices[n].y);
- if (dist < object.distance && dist <= mapslack)
+ if (dist <= object.distance /* "<=" because if there are superimposed
+ vertices, we want to return the
+ highest-numbered one. */
+ && dist <= mapslack)
{
object.obj.type = OBJ_VERTICES;
object.obj.num = n;
Other related posts:
