Gavin Hird

Why do you think OpenGL is going to be updated. Apple has explicitly deprecated OpenGL and will NOT update it ever again. It will be removed from system service the minute they stop supporting Intel based Macs (which might even happen this fall, but more likely in 2025)

The Mac viewer has never been of any priority for LL. It has merely been a tick off item to attract a certain group of creative users that can contribute to the SecondLife economy; users who will not switch to Windows. Granted, Apple's systems has historically had weak graphics performance with a lot of Apple specific idiosyncrasies, so that has not encouraged LL to do much more than minimum effort to make something running. – Which is why the codebase is at it is. 😐

OpenGL support will be removed once the OS support for the last Intel based Mac Pro is over. I'll give it 1 1/2 more years toppers. I really don't see much point in rewriting the ObjC code that exist in the current viewer in Swift. If you look at my repository I have used bridging code to get rid of autorelease pools (did this many years ago) and a few other changes. I have also converted in the order of 12500 BOOL (still ongoing). That alone makes portions of the code faster as the compiler can optimize on native bools and not on random ints.

I am sorry, no From my standpoint rewriting in Swift is pointless as it is both a (very) major undertaking, but also makes the codebase for Apple platforms totally incompatible with the Windows, Xbox or whatever other platforms LL wants to pursue. I don't see Apple dropping C++ and ObjectiveC support anytime soon. The very first objective is to clean up the C++ code base to the point you can start using Apple libraries everywhere; being getting rid of all the BOOL so the codebase effectively becomes a ObjectiveC++ base (other cleanup needed). Boost also has to go. The above means you can use a good portion of the C++ code as is, and start replacing functionality with Apple libraries for audio, video, get rid of the monstrosity that is the embedded browser and replace it with WKWebview, use native system threading and scheduling, network stack, preference management, add iCloud support, Apple SIMD, Apple compression libraries etc, etc. Separate the OpenGL view to purely render in-world, overlaid by a 2D view for the UI. Move all menus to standard Apple menus, all UI widgets to be based on standard Apple UI widgets (with necessary modifications), essentially stopping to render any UI in OpenGL. Finally rewrite the world rendering in Metal. Vulkan is a dead end on Apple platforms. If you want to be in business in Apple platforms, you cannot make your product dependent on a 3rd party for the very core functionality that will and can break at any time. Apple is never going to design for or test that Vulkan will work. I know it is a tall charge, but the reward is a viewer that can run on all Apple platforms with a, depending on how you count, 1-2 billion user base.

What? Do you mean macOS 10 in the documentation. If that is what you mean, LSMinimumSystemVersion is supported from macOS 10 till this day. I run systems from macOS Catalina through to Sonoma to test my viewer builds, so not sure what you mean. Minimum system requirement for my viewer is 10.15 (Catalina)

Info.plist in "Second Life Viewer.app/Contents/" says otherwise. The minimum system version is marked as <key>LSMinimumSystemVersion</key> <string>10.13</string> The info in the Info.plist is what tells macOS what the minimum system requirement is. If the macOS version is lower than the minimum requirement, Finder will show a special icon across the app icon that it is incompatible, and will not even attempt to launch the app. https://developer.apple.com/documentation/bundleresources/information_property_list/lsminimumsystemversion?language=objc

Try take the settings.xml file in ~/Library/Application\ Support/SecondLife/user_settings and move it to the Desktop and see if the viewer will start.

I think you are reading too much into it. RLV was used as the general understood term and not a specific implementation. Besides, isn't Marine Kelly the original creator of RLV, so one would assume she implements the reference version? Another thing is how much functionality do you need if you are going to sit locked down in one spot gagged out (no sound and speech) staring at a black screen? 🤣

RLV support in the SL Viewer anyone?

I also got the messages about not having minimum requirements on an M2, and it set all graphics to minimum. I suspect it might have to do with using SL viewer settings (I upgraded it to version 7 today) and there is also the settings.xml file in user_settings that might interfere with this viewer.

I see why it did not run because it use the SecondLife folder in ~Library/Application Support, which is an exceptional bad idea for a viewer. There was tons on log spew and crashdumps where it tried to use SL Viewer Settings files in addition to the SL Viewer caches. So my initial suggestion to you is to get that sorted, so you don't overwrite SL viewer settings and make sure you have full control of your own including the caches.

No, I did not run it on Big Sur? – Do you really think I build the viewer on that? 😉 Sorry about the confusion, but that is not what we call cross compile. It is called (in Apple speak) building for an architecture.

I'd be curious how you did this? If you look in the folder Megapahit.app/Contents/Resources you have a large number of dylibs that must be linked into the Megapahit binary in Megapahit.app/Contents/MacOS for it even have a hope of working

The problem guys, with building a native Mac and iOS viewer, is the renderer. Since the renderer is very specific to the needs of the dynamic environment in SL, you can't just stick a different (game) renderer into the viewer and think it will work. It will have to be a purpose built renderer for the dynamic content that exist in SL. Since Apple in the future only will support Metal, the renderer for a Mac viewer will have to be made for Metal, and the cost of building and maintaining it can only be offset on Mac and potentially iOS (paying) users. We are talking 10-20 man years of effort. Add to that, many of Apple's libraries for use with Metal only works with Swift, and not a single line of the viewer code is written in Swift. It might be possible to take the C++ code and make the changes to it for it to compile properly as Objective-C++ that also can be used with Metal, but you might have to write bridging code for Metal functionality that is only available via Swift. Sure it can be done, but it takes more than two week-ends on the backroom tweaking some code.

The viewer does not run on M-series machines. It is does not manage to initialize the application start. If I understood you correct, you took the Kokua Intel version and cross compiled it, but did not build it in Xcode on a machine with M-series processor? If that was the way you did it (I may have completely misunderstood), it will never work as the library references that it needs to link with to run on native arm64 will be wrong and it will miss the references to the arm64e libraries needed to initialize and run OpenGL on those machines in addition to a bunch of other system libraries. You will need to do a full build including linking with arm64 versions of all the libraries needed for the viewer in an Xcode project (xcode_build or full Xcode). The Dayturn viewer preview is a fork of Kokua (originally from 2014), but there are lots of changes and removals in it for it to run better on macOS.