HD rendering previously required JOGL, whose macOS support was broken two
ways: the bundled natives are x86_64-only (UnsatisfiedLinkError on Apple
Silicon), and its AWT/CALayer presentation path never composites the GL
output (black window), on top of requesting a GL3bc profile macOS does not
offer. This replaces the whole windowing/GL layer:
* rlawt (RuneLite's AWT-GL bridge, BSD-2) vendored under rlawt/ with two
macOS patches: request the Legacy (2.1 compatibility) profile instead of
GL4 core, since this renderer is fixed-function + ARB assembly programs,
and attach a GL_DEPTH_COMPONENT24 renderbuffer to the IOSurface-backed
framebuffers (RuneLite renders depth-free; this client needs a Z-buffer).
Universal arm64+x86_64 dylib built by rlawt/build-macos.sh; Windows/Linux
ship unmodified upstream rlawt natives, whose contexts are already
compatibility-profile.
* New rt4.GL2 shim exposes JOGL's GL2 instance API over LWJGL 3 statics, so
the ~950 existing gl.glXxx call sites across 26 renderer files stay
untouched (they only lose their com.jogamp import). The shim bridges the
API differences: array+offset overloads, heap-buffer uploads copied to a
scratch direct buffer, glTexStorage2D emulation on pre-4.2 contexts,
glGenerateMipmap EXT fallback, extension queries, and vsync control.
* GlRenderer context lifecycle rewritten on AWTContext: synchronous init,
and the rotated IOSurface back-FBO is re-bound after every swap on macOS.
The old createAndDestroyContext JOGL surface-reset hack is now a no-op.
* The CS2 detail-mode auto-revert ("The change of detail mode has been
cancelled") no longer triggers: it raced JOGL's slow retry-looped init,
and rlawt's init completes synchronously before the script's readback.
Verified in-game on Apple Silicon with a native arm64 JVM (no Rosetta):
SD unchanged, HD switches and renders with no black screen and no revert.
Windows/Linux are compile-checked; runtime behavior should match JOGL's
(same GL calls on a compatibility context) but has not been re-tested.
Also lifts the old "Java 15 or lower" JOGL/WGL restriction on Windows.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PDSjdSB4Hwa53cmLg47pq3
In Windows, on first launch into HD-Mode or at launch going from SD-Mods to HD-Mode, the CPU maxes out and music issues, and is unable to enter into HD-Mode without lag or multiple crashes.
This is because when the code that is supposed to execute GLProfile.initSingleton() waits for its turn on syncronized function queue and then a while loop keeps sleeping the thread until a status code of 1 is returned. Additionally, starting with jogl version 2.0 GLProfile.initSingleton() is not even necessary as its automatically done.
The code commented out has no purpose other than just to execute GLProfile.initSingleton().
Commented out the code and made comments to preserve the original code.
We don't actually need to capture the OpenGL buffer itself, this is fine. Also it simplifies the code a fair bit too, and as an added benefit we can also capture the entire window including the border/decorations etc.
This allows for much greater flexibility of screenshotting, we can now pass in any number of levels of subfolders for our preferred directory depth for storing images.
