| 1 |
That would be nice, and I thought about that myself, but I also don't currently have the time to set that up, since I expect that would involve a lot of work to do the hit tests/stat array search at a reasonable speed.
|
1 |
That would be nice, and I thought about that myself, but I also don't currently have the time to set that up, since I expect that would involve a lot of work to do the hit tests/stat array search at a reasonable speed.
|
| 2 |
\n
|
2 |
\n
|
| 3 |
EDIT:
on
second
thought,
there
is
an
O(
1)
way
to
do
this,
at
least
for
the
selected
player
(
O(
n)
for
any
player)
:
Since
the
values
are
stored
in
an
array
that
gets
entries
with
a
fixed
time
interval
between
them,
you
could
take
the
mouse
x
coordinate
relative
to
the
graph,
divide
by
width
(
to
get
a
value
between
0
and
1)
,
multiply
by
the
number
of
entries
in
the
array
used
to
populate
the
graph
to
get
an
index
and
a
fractional
part.
Use
the
index
and
the
index
+
1
to
get
the
two
bounds
of
the
desired
point,
and
interpolate
between
them
with
the
fractional
part.
|
3 |
EDIT:
on
second
thought,
there
is
an
O(
1)
way
to
do
this,
at
least
for
the
selected
player
(
O(
n)
for
any
player)
:
Since
the
values
are
stored
in
an
array
that
gets
entries
with
a
fixed
time
interval
between
them,
you
could
take
the
mouse
x
coordinate
relative
to
the
graph,
divide
by
width
(
to
get
a
value
between
0
and
1)
,
multiply
by
the
number
of
entries
in
the
array
used
to
populate
the
graph
to
get
an
index
and
a
fractional
part.
Use
the
index
and
the
index
+
1
to
get
the
two
bounds
of
the
desired
point,
and
interpolate
between
them
with
the
fractional
part
to
get
the
value
of
the
graph
at
the
given
time/mouse
x
coord.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
It's a bit involved, but it should scale optimally with graph length/game time.
|
5 |
It's a bit involved, but it should scale optimally with graph length/game time.
|
| 6 |
\n
|
6 |
\n
|
| 7 |
If it isn't limited to the selected player, then you'd have to do this for every line, and compare the resulting values with the mouse y coordinate to find the nearest one, which becomes a possible dev time sink if we want it to scale better than linearly with number of players, but it would only be doing at most 30 or 40 comparisons every time the user moves the mouse (average case would be 2 or 3 if we order the lines by y value and do the same trick as the x-axis thing above and ditch early once y values get further away from the mouse than what we've currently found, though ordering the lines by y value would be the tricky part optimization-wise), so that's not the worst performance loss
|
7 |
If it isn't limited to the selected player, then you'd have to do this for every line, and compare the resulting values with the mouse y coordinate to find the nearest one, which becomes a possible dev time sink if we want it to scale better than linearly with number of players, but it would only be doing at most 30 or 40 comparisons every time the user moves the mouse (average case would be 2 or 3 if we order the lines by y value and do the same trick as the x-axis thing above and ditch early once y values get further away from the mouse than what we've currently found, though ordering the lines by y value would be the tricky part optimization-wise), so that's not the worst performance loss
|
Suggestion- highlight your line in the end-of-game graphs