From 4ef04f41ffddf7140178cb9ce8b5a06e6497047b Mon Sep 17 00:00:00 2001 From: Samual Lenks Date: Wed, 19 Feb 2014 00:45:04 -0500 Subject: [PATCH] Add some comments explaining issues/todo's with the implementation --- qcsrc/client/particles.qc | 24 ++++++++++++++++++++++++ qcsrc/common/weapons/w_arc.qc | 24 ++++++++++++++++++++++++ 2 files changed, 48 insertions(+) diff --git a/qcsrc/client/particles.qc b/qcsrc/client/particles.qc index 077a76acb..e4002d2ed 100644 --- a/qcsrc/client/particles.qc +++ b/qcsrc/client/particles.qc @@ -489,6 +489,30 @@ void Draw_ArcBeam() float i; for(i = 1; i <= segments; ++i) { + // WEAPONTODO (server and client): + // Segment blend and distance should probably really be calculated in a better way, + // however I am not sure how to do it properly. There are a few things I have tried, + // but most of them do not work properly due to my lack of understanding regarding + // the mathematics behind them. + + // Ideally, we should calculate the positions along a perfect curve + // between wantdir and self.beam_dir with an option for depth of arc + + // Another issue is that (on the client code) we must separate the + // curve into multiple rendered curves when handling warpzones. + + // I can handle this by detecting it for each segment, however that + // is a fairly inefficient method in comparison to having a curved line + // drawing function similar to Draw_CylindricLine that accepts + // top and bottom origins as input, this way there would be no + // overlapping edges when connecting the curved pieces. + + // WEAPONTODO (client): + // In order to do nice fading and pointing on the starting segment, we must always + // have that drawn as a separate triangle... However, that is difficult to do when + // keeping in mind the above problems and also optimizing the amount of segments + // drawn on screen at any given time. (Automatic beam quality scaling, essentially) + // calculate this on every segment to ensure that we always reach the full length of the attack float segmentblend = bound(0, (i/segments) + self.beam_tightness, 1); float segmentdist = vlen(beam_endpos_estimate - last_origin) * (i/segments); diff --git a/qcsrc/common/weapons/w_arc.qc b/qcsrc/common/weapons/w_arc.qc index 44655f71b..7a9abf572 100644 --- a/qcsrc/common/weapons/w_arc.qc +++ b/qcsrc/common/weapons/w_arc.qc @@ -237,6 +237,30 @@ void W_Arc_Beam_Think(void) vector last_origin = w_shotorg; for(i = 1; i <= segments; ++i) { + // WEAPONTODO (server and client): + // Segment blend and distance should probably really be calculated in a better way, + // however I am not sure how to do it properly. There are a few things I have tried, + // but most of them do not work properly due to my lack of understanding regarding + // the mathematics behind them. + + // Ideally, we should calculate the positions along a perfect curve + // between wantdir and self.beam_dir with an option for depth of arc + + // Another issue is that (on the client code) we must separate the + // curve into multiple rendered curves when handling warpzones. + + // I can handle this by detecting it for each segment, however that + // is a fairly inefficient method in comparison to having a curved line + // drawing function similar to Draw_CylindricLine that accepts + // top and bottom origins as input, this way there would be no + // overlapping edges when connecting the curved pieces. + + // WEAPONTODO (client): + // In order to do nice fading and pointing on the starting segment, we must always + // have that drawn as a separate triangle... However, that is difficult to do when + // keeping in mind the above problems and also optimizing the amount of segments + // drawn on screen at any given time. (Automatic beam quality scaling, essentially) + // calculate this on every segment to ensure that we always reach the full length of the attack float segmentblend = bound(0, (i/segments) + WEP_CVAR(arc, beam_tightness), 1); float segmentdist = vlen(beam_endpos_estimate - last_origin) * (i/segments); -- 2.39.2