Hi,

I hit a rendering bug and dug into it a bit with AI's help. Posting because it reproduces cleanly on two very different GL stacks.

Symptom: on the galaxy map, from the zoom level where the system inset appears, each star's inset (the planets + orbits view, composited onto the map) renders as a solid opaque black rectangle. Star names sitting under that region are hidden as collateral.

Where it reproduces:
- Windows 11 ARM guest in VMware Fusion (VMware SVGA GL driver) — clean stock install, release branch and current beta branch.
- macOS via CrossOver/Wine (Apple OpenGL) — only when the GLSL path is forced.

Why I believe it's the Cg→GLSL path: both drivers report arbfp1-class fragment profiles, so init_cg_context takes the prefer_glsl branch (use_glsl=true). On CrossOver, where the engine happens to default to a native Cg profile, the insets composite correctly — and forcing use_glsl=true there reproduces the exact same black rectangles. So the offscreen-composite path appears broken specifically under the Cg→GLSL cross-compile, which NVIDIA users never hit. Possibly related: compose_start_screen was also the first shader to fail compiling when I forced GLSL under CrossOver — the compose family may be the common thread.

Bonus finding: forcing the native-Cg branch in the VMware VM (bypassing prefer_glsl) fails at startup compiling planet_super.cg with -DSIMPLE_SHADERS: warning C7102: unmatched #if at planet_super.cg(623), then error C0000: syntax error, unexpected $end at token <EOF> — looks like an untested preprocessor combination in the SIMPLE_SHADERS variant.

Beta branch note: the new GL-debug reporting shows GL_INVALID_ENUM in glMatrixMode (source 0x8246, type 0x824c, id 1) on the VMware driver at startup; game continues, black rectangles unchanged.

Happy to provide screenshots, logs/shaders.txt, or test a patch.

Thanks for keeping this gem alive!
Ludo

Hi luodal.

I've got your error game upload, and was very curious how, exactly, you'd been getting stars in shadow to run on a mac. My assumption had been linux + Wine, but it sounds like you’ve tried all sorts of other things as well, including VMWare and Crossover.

I believe you're one of the only players who's actively attempting to play SiS on apple hardware. Needless to say, this is not an "officially supported" way of playing the game. But I am impressed by your perseverance

The black rectangles around stars are the sort of thing one expects to see when working with an OpenGL driver situation that's "quirky". And multi-level driver emulations going through various contortions to turn an Nvidia-Cg shader into cross-compiled Metal code is exactly the sort of thing that would lead to strange visual bugs.

On CrossOver, where the engine happens to default to a native Cg profile, the insets composite correctly

So it sounds like, of the various things you’ve tried to get SiS working, CrossOver is the only one that works relatively well? How well is “well”? Is the game playable more generally? (I see a lot of OpenGL errors in your upload logs, so I'm guessing that even in Crossover, the experience is perhaps not so great? Are you forced into "Simplified Graphics" mode? Can the game run on your M2 without "Simplified Graphics"?)

Hi Sven, thanks for taking the time to answer. And yes, I may be the only one stubborn enough to fly this particular route.

To answer your questions directly, here's the honest state of both setups on my M2 Max:

VMware Fusion (Windows 11 ARM guest) is actually the better experience, by far. Apart from the black-rectangle insets (the bug I reported), everything else works perfectly: turn processing displays normally, the tactical/combat screen is clean, icons and text are crisp, performance is effortless. No Simplified Graphics needed, it runs the full graphics path fine. If the inset compositing worked on the GLSL path, this would simply be a working Mac setup.

CrossOver is the quirky one. It happens to default to a native Cg profile, so the insets composite correctly there, but that path has its own casualties: dashed_circles renders nothing (fleet/sensor range circles simply invisible) and star_reticle draws garbage ring artifacts at high zoom. Beyond shaders, the window goes black while turns resolve (the between-turns animation never presents and Simplified Graphics doesn't help), and the combat screen has display bugs too. The flood of ERROR BEFORE GL errors you saw in my logs is from CrossOver, mostly latched glGetError noise from Apple's (deprecated, GL 2.1) driver. The error window itself became un-closable in-game because the noise re-latches every frame.

So the symmetry, which might interest you: on both platforms, whichever shader path the engine picks, the other family breaks. GLSL path (VMware, or forced on CrossOver) → offscreen inset composite comes out opaque black. Native Cg path (CrossOver default) → the procedural ring shaders (dashed_circles, star_reticle) misrender. And forcing the native path on VMware doesn't compile at all: planet_super.cg with -DSIMPLE_SHADERS dies on the unmatched #if at line 623 I mentioned.

Happy to test any patch build or instrumented shader you want to throw at me. The VMware setup gives a clean, reproducible environment (one GLSL-path fix away from a fully playable Mac experience, I suspect).

ludoal wrote: Sun Jul 12, 2026 4:21 am VMware Fusion (Windows 11 ARM guest) is actually the better experience, by far. Apart from the black-rectangle insets (the bug I reported), everything else works perfectly: turn processing displays normally, the tactical/combat screen is clean, icons and text are crisp, performance is effortless. No Simplified Graphics needed, it runs the full graphics path fine. If the inset compositing worked on the GLSL path, this would simply be a working Mac setup.

Interesting indeed. I think you're misdiagnosing the issue though -- if your VMWare setup is working fine almost everywhere, except for these weird black rectangles behind stars, that's probably not a general problem with offscreen render compositing -- it's probably just a glitch connected to the particular shader that's generating the pixels behind the stars. Offscreen render compositing is a thing that SiS is doing all the time and in all sorts of places, if it were broken generally you'd see all sorts of ugly artifacts.

The bug you're describing sounds more like a glitch with orbits_super.cg, which is the thing that draws the orbit lines behind stars on the starmap.

I've seen errors like this before -- they usually happen because some old driver doesn't like some kind of math function, and is erroring out and making black pixels rather than working properly. orbits_super.cg has a history of these kinds of problems -- if you look at the shader source code, you'll see me complaining about AMD's support for isnan specifically.

And it's very plausible a version of this bug is what's hitting you as well -- NaN handling is the kind of rarely-used low-level thing that might well be breaking in an emulated rendering stack.

Fortunately, there's a lot of ways you might rewrite newnantest to get it working on your hardware -- if you have an AI assistant, it can generate more or less endless ideas about how to maybe tweak the details of orbits_super.cg in hopes of making it more compatible.

(Also, if you post a screenshot of the rectangles here, I can confirm that orbits_super.cg is the likely cause.)

All that said, my own *first* attempt would be to just simplify newnantest to only use the AMD-compatbile check, namely, comment out line 59, so you just have:
If your Metal/GL context is choking on isnan, just removing isnan from the source might be enough to fix the issue by itself.

If that doesn't work, you can also try the *opposite* approach, and just drop the AMD compatibility pattern:

Sven, good news: the black rectangles are gone, both behind stars and under the selection reticle. You were right about the root cause (NaN in the ellipse-distance math), but interestingly, neither of your two newnantest variants worked on my setup. What fixed it was a third approach my AI assistant came up with: don't detect the NaN — never produce it in the first place.

Its reasoning: on an emulated rendering stack (VMware's GL driver on an Apple Silicon host), NaN semantics seem to be broken deeper than just isnan — the compiler likely optimizes NaN comparisons away entirely (fast-math style), so any after-the-fact detection is unreliable. Both your variants died on that. So instead it guards approx_t before the sqrt and raises a flag:

In dists_ellipse.cg:
The trick is !(u >= 0): it catches u negative and u already-NaN without relying on isnan or IEEE comparison semantics. Then in orbits_super.cg, line 84 becomes:
The selection reticle had the same disease (black quad outside the ellipse) — same cure in star_reticle.cg's local copy of approx_t, this time with a sentinel value instead of a global:
with the check becoming if (t > 1e29 || newnantest(t) || ...).

For what it's worth, the same source-side guard also fixed these shaders under CrossOver/Wine on macOS — so this pattern seems to travel well across every non-native GL stack. If you ever fold something like it into the official source, Mac players in VMs (and probably some AMD users) would benefit.

Thanks for pointing at the right file, it saved us a lot of guessing.