| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
They're custom anyway so very unlikely to be reused in other projects.
TinyGLTF.cmake changes here just to minimise diff, the include
directory setting does not have any effect (just like in TinyEXR.cmake).
|
|
Now you can pass -DCMAKE_OSX_ARCHITECTURES:STRING=`uname -m` or
-DCMAKE_OSX_ARCHITECTURES:STRING="arm64;x86_64" and it will build
as intended.
|
|
|
|
Except for SLPlugin since there's already a custom command for it.
|
|
for when autobuild's not installed.
|
|
|
|
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
|
|
roxie/webrtc-voice
|
|
|
|
* #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
|
|
Also, start/stop recording depending on whether WebRTC has negotiated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
