First, do a ray intersection test with the bounding-sphere for all
entities on the map and then check the more detailed selection shape for
the remaining candidates. Do checks that require component lookups after
the ray intersection tests because these are relatively expensive.
The old method for figuring out which entities are below the mouse
cursor was incorrect because it does a 2D check to filter out the first
candidates which can lead to incorrect results with lower camera angles
and high buildings or buildings with a large footprint. Such problems
were avoided with quite a large radius for this 2D test and resulted in
a large number of candiate entities after this first test (200-500).
Also rename PickEntitiesAtPoint to PickEntityAtPoint and make it return
only one (the closest) match.
I've tested performance with the tracelogger by starting a map and then
moving the mouse in circles for one minute. The results were relatively
stable. I've compared the total time percentage of input.js:836, which
spends nearly all of the time in PickEntityAtPoint.
Ardennes Forest - Normal size: Original: 41.46% Patched: 31.6%
Ardennes Forest - Giant size: Original: 40.59% Patched: 51.55%
As we see, it's faster on normal map sizes but slower on giant maps with
a lot of entities.
This approach can be further improved with some kind of spatial
subdivision for the culling (like an octree), which would help the unit
renderer too. This way it should be possible to make it faster (and
still correct) on all map sizes and with a large total numbers of
entities.
This was SVN commit r16098.
Parameters now have to be quoted with ".
Supports " in parameters by escaping them with \.
Tag start characters can be included in normal text by escaping them
with \.
Better error handling and a error messages to help with fixing
invalid/malformed strings.
This was SVN commit r15969.
The runtime is becoming more and more important in the JSAPI. As a
result, we also have more functionality on the runtime level and having
the whole ScriptRuntime class hidden in ScriptInterface.cpp doesn't make
sense anymore. ScriptInterface.cpp also has become quite a large file
and pulling out the runtime part makes it a bit smaller.
Refs #2462
This was SVN commit r15961.
Fix Engine.ReadJSONFile() which did throw a JS exception that was not
caught. Discovered by s0600204.
Expose Engine.ReadJSONFile() to the gui scripts.
This was SVN commit r15959.
The main problem was that GC was only called from the simulation before
this patch. This means when you were waiting in the multiplayer lobby or
just had the GUI open, it only called GC when getting close to the JS
runtime size limit (I assume). Another problem was the Net Server
runtime which didn't GC either. Here the runtime size limit is 16 MB
though, so it's not too terrible. These issues have both been addressed
and GC has been given a bit more time per incremental slice to make sure
it gets done in time. It's still far from perfect, but there are too
many changes in SpiderMonkey related to GC, so I don't want to spend too
much time on this yet.
Refs #2808
This was SVN commit r15787.
Implements SDL2 text editing handler for input fields, this is for IME
support, so users entering CJK text can see what they're composing
before committing it. Should have no effect on SDL1 or normal text
input.
This was SVN commit r15785.
* Adds SDL color cursor implementation
* Adds config option for choosing preferred display in multimonitor
setup
* Uses text input API to better handle CJK input
* Fixes various hotkey and input bugs
SDL 1.2 is still the default and recommended, to test experimental SDL2
support, pass the --sdl2 flag to update-workspaces
This was SVN commit r15767.
The ScriptInterface pointer can be NULL there, so using it without
checking is not safe.
This fixes the problem by continuing with the exact stack rooting
changes, which makes the temporary solution unnecessary.
Fixes#2707
Refs #2415
This was SVN commit r15611.
Changes CallFunction and CallFunctionVoid to use a HandleValue as object
parameter. Also changes some JS serialization/deserialization functions
to only support the JSAPI rooted types (drop support for CScriptVal and
CScriptValRooted there). Some other functions got changed too because
they were closely related.
Refs #2415
Refs #2462
This was SVN commit r15592.
* CGameLoader created a new JS::Value when assigning to m_Metadata.
This means it didn't actually update metadata in SavedGames::Load. The
new approach solves this problem and should work well if
CScriptValRooted gets replaced in the future.
* The cloning in ScriptFunctions.cpp was required. Removing it caused
compartment mismatches.
* Now CGameLoader loads the metadata unconditinally because we didn't
actually use the option to not load load it.
Ref #2415
This was SVN commit r15589.
Changes GetProperty, SetProperty and HasProperty and a few other
functions to take handles. The conversions to CScriptVal or
CScriptValRooted at some places should be removed in the future. I've
done that to avoid an even larger patch.
Refs #2415
Refs #2462
This was SVN commit r15568.
Changes the CallFunction implementation to use macros because otherwise
we'd have to write twice as many functions manually.
Adapts GetSavedGameData to use the new function template. Additional
callers will be changed in future commits.
Refs #2415
Refs #2462
This was SVN commit r15541.
JS::MutableHandleValue is similar to JS::HandleValue, but the whole
JS::Value it points to can be replaced.
This change is needed for support of exact stack rooting and moving GC.
Contains a few other trivial API adjustments and style improvements too.
Refs #2462
Refs #2415
This was SVN commit r15534.
In v24 you called JS_InitClass and passed in a definition of JSNative
functions. Later you could call JS_NewObject with this class and the
object would get a prototype with the specified JSNative functions.
In ESR31 you now have to explicitly store the prototype object returned
by JS_InitClass and pass it as prototype argument to JS_NewObject to
achieve the same.
This change modifies our existing ScriptInterface implementation for
custom object types a bit and uses it at places where the JSAPI was used
directly before.
Refs #2462
This was SVN commit r15524.
JS::HandleValue is basically a wrapper around a JS::Value that is safe
for exact stack rooting and moving GC.
I've tried to keep this changeset rather small and isolated and
therefore create additional JS::Rooted<T> values at some places where
the function should eventually directly take a JS::Handle<T>.
The functions "CallFunction" and "CallFunctionVoid" put their arguments
inside a JS::AutoValueVector because this will be passed directly to
"CallFunction_" with ESR31.
Refs #2462
Refs #2415
This was SVN commit r15517.
This is the new way for working with arguments in JSNative functions.
JS_THIS_VALUE, JS_ARGV, JS_SET_RVAL and direct access to vp or argc are
deprecated and will probably be removed in future versions of
SpiderMonkey.
CallArgs also takes care of proper rooting and you can get the values as
Handles or MutableHandles. The interface changes a little bit for ESR
31, but commiting this now still makes it easier and the changes shout
be straigtforward (search and replace more or less).
Refs #2462
Refs #2415
This was SVN commit r15516.
leper