ChainPlacer.js creates a new array that it fills with the -1 value before computing its clumps. This is slow.
By simply storing values differently, we can avoid doing that altogether, leading to faster mapgen.
Hard to say in general but I think this might be about 3-4% faster on a typical map.
The migration to git broke the translation of language names in the
credits, as the translators.json, necessary for extracting the language
strings wasn't present anymore when running update_templates.py. This
commit should fix this.
- Shallow-freezing of objects is never used in our codebase, so remove
that code path.
- Deep-freeze is bugged in recent versions of SpiderMonkey (see bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1930258). Until a fix
and/or a better API is provided, reimplement this feature by
recusively freezing object properties.
- Add tests for the deepfreeze function.
The shell option "set -e" has a tricky, but standard, behaviour:
Anything called on the left side of a || or && token ignores "set -e",
so failure in a command in a subshell called on the left side of "|| die"
does not prevent the execution of the following commands in the subshell.
Adding explicit "|| die" calls after each command that could fail (and
should interrupt the process) works around this behaviour, by emulating
the intuitive "set -e" behaviour.
Unless minimal cflags is set add -Og or equivalent to CXXFLAGS for debug
build configuration.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
FORTIFY_SOURCE relies on optimizations being enabled which is only the
case for the release configuration. Therefore remove it from the debug
configuration as to prevent the compiler issuing a warning on each
invocation.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
DEBUG is unused by pyrogenesis and unconditionally adding it to defines
prevents building against a non debug version of spidermonkey. This will
allow building only one copy of spidermonkey, which can be trivially be
replaced with the other depending on needs independent of pyrogenesis
debug or release build.
This also allows to build either build configuration against system
spidermonkey, which obviously is either one build type or the other.
Requires a compilecheck until the pc file gets fixed upstream.
A comment in the spidermonkey build.sh says on FreeBSD spidermonkey
debug configuration doesn't even build and so pyrogenesis debug build
wasn't possible either.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
During the removal of glooxwrapper the function GetJID was mapped to
getID. This results in NetClient querying for host jid not getting the
right value which prevents hosting a game in the lobby.
Reported-by: Dunedan
Refs: #7203
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This uses ./build/workspaces/default as location for generated build
files as well as build products. Using the name "default" to avoid the
dilemma gcc vs clang vs premake generator. Doesn't impact scripts
already using --outpath and allows running premake5 --help without a
wrapper.
Also update .gitignore to make using arbitrary workspaces cleaner.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This option doesn't handle includes, further we rely on system includes
and pkg-config to locate dependencies.
For systems where installing into local is reasonable this paths should
already be in system/ld paths. So in practice this offers no value.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This option is needed to be able to use more than 2GB on 32bit Windows
builds.
Having to explicitly enable this turns out to be a pitfall. Release
builds are done with this option enabled and when then building from
source and running out of memory it's not immediately obvious what the
reason is.
The documented intent is that this behaviour might be useful to find
memory leaks. The large-address-aware enabled build already perfectly
serves this role this days and the memory pressure is an important
reason for the ongoing Windows 64bit build efforts. Also there are
arguably better tools for this purpose.
Refs: commit a8403bd7e5
Refs: issue #1619
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This wrapper was meant to support multiple C++ ABIs with a single
pre-built gloox library wrap as a C library. A new ABI change was
rejected a few years back, so this will probably take a while for it to
be on the table again. With the bug tracker and mailing list currently
unavailable and known TLS issues we might have replaced gloox by then
anyway.
Supporting multiple ABIs with the current setup isn't an issue either
and is already done for 32bit vs 64bit ABI on Windows.
Therefore use gloox types directly in lobby code instead of wrapper
types and delete the wrapper and build-integration.
Migrate to override where applicable, as it helped avoid subtle
differences in signatures and finding missing inheritance of LogHandler.
Finally use version check instead of os check to work around Windows
using the 1.1 development branch instead of releases.
Fixes: #7198
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Querring the audio device name may fail. The name is only used for the
sake of logging it for debugging. Avoid querry failure to be fatal and
insted just log the issue.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
With version 1.24.0 alcIsExtensionPresent() has dropped case insensitive
string comparison [1], use upper case names.
The internal strings are uppercase since the first git commit importing
openal 17 years ago.
[1] upstream commit 785f794141d62a4c308db26aa4a4819e6a92525e
Report: https://wildfiregames.com/forum/topic/125203-crash-on-start-due-to-soundmanager
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Some return values can be assigned to a `const auto`, somewhere `dir` is
mutated so the whole result has to be assigned to a non `const` variable
and once only dir is used, so structured binding isn't used there.
When building a JS::Value from CParamNode, strings have been "interned"
since the conversion was written in dd501b2a5a. This means that the JS
string object could be used outside a JS realm, and also that those
strings could be compared efficiently instead of char-by-char.
This was unnecessary, and the only place in the code where we used
"interned" strings. The upgrade to SpiderMonkey 45 (64b477625d) changed
the name of related methods, and some of them are removed from the
public API in SM 102, so stop pinning and atomizing those strings.
Additionally, the switch of CParamNode to utf8 in 35ed55cfd6 missed one
of the two utf16 handlings, so fix that as well.
Lancelot de Ferrière