The implementation on Windows was gross. The only user was CLogger,
which no longer uses it.
Also fix vswprintf_s to handle truncated output correctly (by returning
"") on Linux, now that CLogger is no longer relying on the buggy
behaviour.
This was SVN commit r16190.
Everything is char* now, so we don't need to mess around with different
string types.
Done with:
ag -ls 'LOG(MESSAGE|MESSAGERENDER|WARNING|ERROR)' source | xargs perl
-pi -e'1 while
s/(LOG(MESSAGE|MESSAGERENDER|WARNING|ERROR).*)%[hl]s/$1%s/g'
This was SVN commit r16187.
This saves the hassle of writing utf8_from_wstring(path.string()) in
places like log messages, and can be extended to better handle
non-ISO-8859-1 paths on Linux.
This was SVN commit r16185.
Done with:
ag -ls 'LOG(MESSAGE|MESSAGERENDER|WARNING|ERROR)' source | xargs sed
-i 's/LOG\(MESSAGE\|MESSAGERENDER\|WARNING\|ERROR\)(L/LOG\1(/g'
This was SVN commit r16183.
sys_vswprintf relies on platform-specific printf implementations, which
vary widely between platforms (in handling of truncation, return values,
use of %s/%S/%hs/%ls for mixing char and wchar_t strings, etc) and are
therefore a pain.
Use cppformat's fmt::sprintf instead, which has very similar syntax to
sprintf but is more C++ish and is portable.
Also, wchar_t is stupid, so use char* strings (which are expected to be
UTF-8) in CLogger. This creates a bit of a pain with changing all
callers to convert to char* strings, but that's their fault for not
using UTF-8 already.
Refs #3011.
This was SVN commit r16182.
Throwing exception on NULL is a bit extreme, and unhelpful when it
happens in rarely-tested error paths. Printing "(null)" is safer and
provides compatibility with glibc sprintf.
This was SVN commit r16180.
These cause a lot of type-safety trouble - unsupported types passed into
fmt::sprintf (like CStr or enums) will be accepted at compile time, but
trigger an exception at runtime. Remove them, so we'll get either an
implicit conversion to a supported type, or a compile-time error.
This was SVN commit r16179.
This needs to use the model-view matrix, not model-view-projection (the
transform uniform), else the axes won't be unit vectors and the particle
sizes will be wrong. But GLES doesn't have the pre-defined matrices, so
pass it in explicitly.
This was SVN commit r16165.
Local types shall not be used as a template argument. So move it
to a higher scope. This restriction was lifted in C++11, so we
might want to change this back when we switch to that.
This was SVN commit r16101.
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.
Previously we removed all players and created them anew. This caused
issues in Atlas,
as some components were recreated, but did not get informed about
already existing
entities (eg cmpTechnologyManager). By only creating/deleting players
until we obtain
the new number of players we do not have this issue.
This was SVN commit r16080.
historic_bruno