| Age | Commit message (Collapse) | Author |
|---|
|
Except for SLPlugin since there's already a custom command for it.
|
|
Our SDL2-based code is kept Darwin-ready. This move was triggered
by the merge with SLv's release/maint-b branch causing the viewer
to show only a black screen, even though everything else seemed to
be working (logging in, streaming, quitting the app). This decision
also has caused numerous MPv specific window-related macOS bugs to
be fixed. I wanted to commit this on the main branch, but somehow
it failed to build. This move was bound to happen at the arrival of
Maintenance B after all.
|
|
Just put the FMOD api/core files to their corresponding places somewhere
like /usr/local, and enclose the headers in a folder named "fmodstudio".
|
|
source for viewer 7.1.8.9375512768
|
|
|
|
|
|
Cause 2.5.2 on MacPorts and FBSD ports are safe, while 2.5.0 on
Debian/Ubuntu would cause a crash that we stick to LL's 2.5.0.
|
|
This reverts commit 0797257992ee7f88456d3083ebf214485b75c139.
|
|
|
|
Compiling would fail otherwise at least on Fedora 40 and Ubuntu 24.04
with their GCC 13 or newer.
|
|
source for viewer 7.1.7.8974243247
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llfloaterimagepreview.cpp
|
|
|
|
|
|
LF, and trim trailing whitespaces as needed
|
|
|
|
fallback fonts.
With the emojis support, a new font was added, which not only provides emojis
but also fancy colorful replacements for UTF-8 characters that used to be
supported by our fallback (monochrome) fonts: this causes discrepancies and
unwanted/undesired changes in scripted objects menus (e.g. an empty circle or
square may render as a black, full one, a heart may render red instead of white),
not to mention the larger font size used by the emoji characters...
This patch restores the aspect of such menus/dialogs/UI elements with UTF-8
characters that *are* supported by the usual fallback fonts (fonts which may
also vary from one viewer to another, and from one OS to another), so that
everything keeps working/rendering as it always did so far, while not impairing
the use of new colorful emojis.
This second proposal ensures that:
- "genuine" emojis (in the 0x1f000-0x1ffff range), will *always* be rendered
using the new emojis font (this solves, for example, the monochrome "yellow
faces" issue seen with some characters in my first proposal).
- Special UTF-8 characters (in the 0x2000-0x32FF range) which have been used by
scripters so far, will render as they used to, using the monochrome fallback
fonts (this repairs scripted dialogs menus).
- Remaining special characters, that do not have a corresponding glyph in the
monochrome font, but do have one in the emojis font, will use the latter font
to render.
It also got the nice side-effect of removing the dependency on the ICU4C library.
Note however that the recent commit:
https://github.com/secondlife/viewer/commit/326055ba82c22fedde186c6a56bafd4fe87e613a
will need to be reverted to allow this patch to actually fix scripted dialogs.
Also, some cleanup might be needed in skins/default/xui/*/emoji_characters.xml to
remove from it the special UTF-8 characters that will no longer be rendered with
fanciful colors, but instead with the monochrome font glyphs.
|
|
static libs
|
|
* #926 WIP - HDRI import prototype v0
* #926 WIP -- add OpenEXR to autobuild.xml
* #926 WIP -- Add OpenEXR cmake
* #926 WIP -- Attempt at using OpenEXR autobuild package and don't hard code .exr file to load
* #926 Unmangle autobuild.xml and get dll's in the right place (thanks, Caladbolg!)
* implement mac shared libs plumbing for OpenEXR for secondlife/viewer#926
* Fix Xcode/clang compile error regarding new[]/delete[] mismatch
* #926 HDRI Preview finishing touches.
- Full ACES when HDRI is enabled
- Fix for probes getting stuck paused
- Add exposure and rotation controls
---------
Co-authored-by: Brad Linden <brad@lindenlab.com>
|
|
source for viewer 7.1.3.7878383867
|
|
The lllibs need to be built as static libs now, otherwise SLPlugin
would lose reference to gSavedSettings. The media plugins still need to
be built as dynamic libs however, so they can't rely on the condition in
LibraryInstall.cmake any more.
Since the Megapahit viewer, when built using GCC, is using the default
value for _GLIBCXX_USE_CXX11_ABI (which is 1 for the newer C++11 ABI as
opposed to 0 for the older C++03 ABI), the Dullahan dependency needs to
be built with the very same _GLIBCXX_USE_CXX11_ABI setting too, otherwise
apr_dso would fail at loading libmedia_plugin_cef.so because of the failure
to refer to the setOnConsoleMessageCallback function with strictly the same
(not differing between std::__cxx11::basic_string vs. std::basic_string)
parameter types.
The CEF build is Spotify's, so no live streaming support, while the
Dullahan package used by the viewer was built using Kokua's dullahan
fork. After rebuilding it with _GLIBCXX_USE_CXX11_ABI kept at default
by not overriding it in variables (from the build-variables repo), the
order of the target link libraries in CEFPlugin.cmake doesn't seem to
matter any more (it did before!).
Now EXTERNAL_TOS can be safely omitted from GNU/Linux added compile
definitions (but still used on FreeBSD).
|
|
so we follow its encapsulating directory naming.
Looks like we're still going to be using LL's 3p-openjpeg for a while
more.
|
|
because (at least) the vlc/plugins dirs are inside it in the same way
it's been inside llplugin. This is so the app can find system VLC
plugins. And for this, BUILD_SHARED_LIBS set on must work first on Linux
(has already been working on FreeBSD), since libmedia_plugin_libvlc is a
shared library (which now gets installed to system library dir too, on
both OSes).
|
|
This reverts commit 33691f2fa52e3b9c2146391413234472769b13ed.
|
|
source for viewer 7.1.1.7039128750
|
|
# Conflicts:
# indra/newview/fonts/DejaVu-license.txt
# indra/newview/fonts/DejaVuSans-Bold.ttf
# indra/newview/fonts/DejaVuSans-BoldOblique.ttf
# indra/newview/fonts/DejaVuSans-Oblique.ttf
# indra/newview/fonts/DejaVuSans.ttf
# indra/newview/fonts/DejaVuSansMono.ttf
|
|
Just untar Dullahan package manually in prebuilt libs dir.
|
|
|
|
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
|
|
since we don't have any web browser there either.
|
|
This reverts commit 9d49edbc48d81f820870d43edb2c975beffa5485.
|
|
|
|
|
|
source for viewer 6.6.16.6566955269
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/viewer_manifest.py
|
|
Add python 3.12 to FindPython search path
|
|
Look for python 3.12 in the registry along with all the other versions.
|
|
|
|
Vulkan glTF doesn't seem to be used yet.
TINYGLTF_INCLUDE_DIR doesn't seem to be used yet either.
Tiny GLTF can be headers only, easy to install to system.
|
|
|
|
until we figure out what's causing crashes with vanilla OpenJPEG.
|
|
|
|
|
|
Elsewhere in CMake land, we reference PYTHONINTERP_FOUND and
PYTHON_EXECUTABLE, both of which are explicitly set by Python.cmake. We don't
seem to need the find_package(Python3 COMPONENTS Interpreter) call. Given that
we take some pains to be careful about which Windows Python interpreter we
find, this eliminates a wildcard.
|
|
|
|
Otherwise it would fail to link SLPlugin.
|
