Bug 5076 - range markers
Status: NEW
Alias: None
Product: Tremulous
Classification: Unclassified
Component: Misc
Version: SVN HEAD
Hardware: All All
: P3 enhancement
Assignee: Tim Angus
QA Contact: Tremulous Bugs
URL:
Depends on: 3736 5010 5074
Blocks:
 
Reported: 2011-07-13 11:13 EDT by /dev/humancontroller
Modified: 2011-08-02 01:15:34 EDT
1 user (show)

See Also:


Attachments
range marker functionality, buildable range markers (33.24 KB, patch)
2011-07-13 11:25 EDT, /dev/humancontroller
assets required for rendering (41.29 KB, application/zip)
2011-07-13 11:32 EDT, /dev/humancontroller
menu options to set range marker cvars (5.56 KB, patch)
2011-07-13 11:39 EDT, /dev/humancontroller
a simple compatibility hack for the gpp branch (1.46 KB, patch)
2011-07-13 11:44 EDT, /dev/humancontroller
64-bit clientmask hack, for compatibility (2.90 KB, patch)
2011-07-13 11:50 EDT, /dev/humancontroller
range marker compatibility hack (2.44 KB, patch)
2011-07-13 11:55 EDT, /dev/humancontroller
all-in-one patch for the current state of the GPP branch (42.04 KB, patch)
2011-07-13 12:10 EDT, /dev/humancontroller
64-bit clientmask hack, for compatibility (2.90 KB, patch)
2011-07-13 13:28 EDT, /dev/humancontroller
all-in-one patch for the current state of the GPP branch (43.81 KB, patch)
2011-07-13 13:49 EDT, /dev/humancontroller
range marker functionality, buildable range markers (8.81 KB, patch)
2011-07-13 15:38 EDT, /dev/humancontroller
range marker functionality, buildable range markers (33.22 KB, patch)
2011-07-13 16:19 EDT, /dev/humancontroller
all-in-one patch for the current state of the GPP branch (43.80 KB, patch)
2011-07-13 16:22 EDT, /dev/humancontroller
range marker functionality, buildable range markers (33.11 KB, patch)
2011-07-13 20:48 EDT, /dev/humancontroller
all-in-one patch for the current state of the GPP branch (43.68 KB, patch)
2011-07-13 20:48 EDT, /dev/humancontroller
request 1 alpha bit (495 bytes, patch)
2011-07-17 14:33 EDT, /dev/humancontroller

Description /dev/humancontroller 2011-07-13 11:13:21 EDT
the feature is about displaying range indicators, primarily for buildables.
Comment 1 /dev/humancontroller 2011-07-13 11:25:55 EDT
Created attachment 2820 [details]
range marker functionality, buildable range markers

the code is not well documented with comments, i will add them S00N(TM). the added code is somewhat redundant and modular to allow easier future expansion (ie., new range marker shapes, and range markers for other things, like map-specific areas).

this change depends on the change in bug 3736, which breaks server compatibility (do not merge into the GPP branch in its current state).
Comment 2 /dev/humancontroller 2011-07-13 11:32:18 EDT
Created attachment 2821 [details]
assets required for rendering

credits go to Uniq PhoeniX for creating the models, and devising a method (which we call "binary shaders") to draw lines on the map geometry and outlines of shapes.
Comment 3 /dev/humancontroller 2011-07-13 11:39:58 EDT
Created attachment 2822 [details]
menu options to set range marker cvars

new settings in: Options -> System -> Range Markers.
this may not be the best location where to put range marker settings.
Comment 4 /dev/humancontroller 2011-07-13 11:44:31 EDT
Created attachment 2823 [details]
a simple compatibility hack for the gpp branch

however, i recommend a better method (shortly!), so i provide this patch only for show, and i'm obsoleting it immediately.
Comment 5 /dev/humancontroller 2011-07-13 11:50:35 EDT
Created attachment 2824 [details]
64-bit clientmask hack, for compatibility

first, apply the patch in bug 5010 (in the master branch), then (after merging), in the gpp branch, apply this patch.
Comment 6 /dev/humancontroller 2011-07-13 11:55:38 EDT
Created attachment 2825 [details]
range marker compatibility hack

(the "advanced" hack.)
this patch is to be applied to the gpp branch, after applying the patch above.
Comment 7 /dev/humancontroller 2011-07-13 12:10:30 EDT
Created attachment 2826 [details]
all-in-one patch for the current state of the GPP branch

only for testing. provided for the impatient.
Comment 8 /dev/humancontroller 2011-07-13 12:51:20 EDT
i almost forgot: the patch in bug 5074 should also be applied along with this change.
Comment 9 /dev/humancontroller 2011-07-13 13:28:06 EDT
Created attachment 2828 [details]
64-bit clientmask hack, for compatibility

(whitespace...)
Comment 10 /dev/humancontroller 2011-07-13 13:49:30 EDT
Created attachment 2829 [details]
all-in-one patch for the current state of the GPP branch

with minor updates.
Comment 11 /dev/humancontroller 2011-07-13 15:38:26 EDT
Created attachment 2830 [details]
range marker functionality, buildable range markers

(whitespace...)
Comment 12 /dev/humancontroller 2011-07-13 16:19:47 EDT
Created attachment 2831 [details]
range marker functionality, buildable range markers

(whitespace...)
Comment 13 /dev/humancontroller 2011-07-13 16:22:29 EDT
Created attachment 2832 [details]
all-in-one patch for the current state of the GPP branch

(updated with whitespace changes...)
Comment 14 /dev/humancontroller 2011-07-13 16:42:46 EDT
Comment on attachment 2830 [details]
range marker functionality, buildable range markers

>sp4m
Comment 15 /dev/humancontroller 2011-07-13 20:48:00 EDT
Created attachment 2834 [details]
range marker functionality, buildable range markers

oops, it turns out that VectorCopy() isn't defined as a series of assignments in QVMs, causing bugs in QVMs when VectorCopy()ing float[3]s to byte[3]s. the VectorCopy() usage is now fixed.
Comment 16 /dev/humancontroller 2011-07-13 20:48:40 EDT
Created attachment 2835 [details]
all-in-one patch for the current state of the GPP branch

updated with the VectorCopy() usage fix.
Comment 17 /dev/humancontroller 2011-07-17 14:31:59 EDT
binary shaders are not guaranteed to work with the ioq3 engine by default. a video mode with an alpha channel must be requested (which is not done by ioquake3 generally). thx to gimhael for pointing this out.
Comment 18 /dev/humancontroller 2011-07-17 14:33:29 EDT
Created attachment 2849 [details]
request 1 alpha bit

a quick proof-of-concept hack, which makes binary shaders work on at least 1 machine.
Comment 19 Chris "Lakitu7" Schwarz 2011-08-02 01:15:34 EDT
I'm sorry but this binary shaders thing is far too messy for trunk. Even besides that it seems to not work for some people, binary.shader is just a mega-hack on a level we cannot do. The proper way to do this is by adding that functionality to the shader/renderer code, not such grotesque work-arounds for its absence. This feature is good in theory, but not with this implementation.