c254fea83d
The client shipped with a PE icon Explorer showed and a window that did not:
launched from the launcher it still drew the stock Windows application icon.
Silk's Window.Create only builds the managed object. IWindow.Initialize is
what, in Silk's own words, "creates the window on the underlying platform".
Applying an icon before that throws:
after Window.Create : IsInitialized = False
SetWindowIcon BEFORE Initialize : THREW InvalidOperationException:
Window should be initialized.
after Initialize : IsInitialized = True
SetWindowIcon AFTER Initialize : returned without throwing
What made this quiet rather than obvious is the fallback. GLFW registers its
window class against a resource named GLFW_ICON and, not finding one, uses
IDI_APPLICATION - the generic Windows icon - rather than the executable's own.
So the PE icon kept showing on the file while the live window lost it, which
reads as a packaging problem and is nothing of the kind. The launcher was
unaffected because Avalonia takes a different path entirely, and that
asymmetry was the tell.
Apply now happens in OnLoad, beside the other window-dependent startup work,
and refuses with a message naming the ordering requirement if it is ever
called on an uninitialized window - the previous generic catch reported
"Window should be initialized" to a stderr nobody reads, which said nothing
about icons.
The regression guard reads the compiled call graph, because this is an
ordering edge with no observable return value: OnLoad must call Apply, and no
method that calls Window.Create may. Verified by reintroducing the bug and
watching it fail, then restoring the fix and watching it pass.
Solution builds clean; 14,408 tests pass on the standard hermetic lane filter,
0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
# acdream application icons
|
|
|
|
Two marks, one family.
|
|
|
|
| Mark | Files | Used by |
|
|
|---|---|---|
|
|
| **Client** — the mosswart head | `acdream-client-*.png`, `acdream-client.ico` | `AcDream.App` (PE icon + runtime window icon) |
|
|
| **Launcher** — the ring and crescent | `acdream-launcher-*.png`, `acdream-launcher.ico` | `AcDream.Launcher` (PE icon + Avalonia `Window.Icon`) |
|
|
|
|
Each ships PNGs at 16/24/32/48/64/128/256/512/1024 plus a multi-size `.ico`
|
|
carrying 16 through 256.
|
|
|
|
## Where the art comes from
|
|
|
|
**The client mark is the retail mosswart**, not a drawing of one. It is the
|
|
actual creature head — `Setup 0x02000B4F` part 14, skin atlas `0x05001E11`,
|
|
`ClothingBase 0x10000344` — pulled from `client_portal.dat`, smoothed, lit and
|
|
graded. Palette values throughout both marks are sampled from that texture:
|
|
|
|
| | |
|
|
|---|---|
|
|
| `#ACB820` | chartreuse upper skin |
|
|
| `#A09800` | mustard belly — the "foul yellow" the lore names |
|
|
| `#485010` | deep olive shadow |
|
|
| `#F2ECD2` | tusk bone |
|
|
| `#AC7438` | ear membrane / hide |
|
|
|
|
**The launcher mark is inspired by the Asheron's Call sigil** — a forged ring
|
|
enclosing a hooked crescent — rebuilt from measurements of the retail wordmark
|
|
and the `acclient.exe` icon resource. It is an original construction in the
|
|
same visual language, not a copy of the logo. Its warm field matches the retail
|
|
client icon's dark-to-gold interior.
|
|
|
|
> **Note on rights.** "Asheron's Call" and its logo are trademarks of their
|
|
> owners, and the client mark is rendered from copyrighted game art. Unlike DAT
|
|
> content — which stays on the user's own disk — these icons are compiled into
|
|
> the shipped binaries. If acdream is ever distributed broadly, both marks
|
|
> should be reviewed, and the client mark is the one most likely to want an
|
|
> original redraw using these renders as reference.
|
|
|
|
## Regenerating
|
|
|
|
The launcher mark is fully procedural and rebuilds anywhere:
|
|
|
|
```bash
|
|
py tools/IconForge/forge.py launcher
|
|
```
|
|
|
|
That is byte-for-byte deterministic — it reproduces the committed PNGs exactly,
|
|
so an accidental edit is visible as a diff.
|
|
|
|
The client mark renders real game geometry, so it needs the installed DATs.
|
|
One command extracts both halves — the posed geometry and the surfaces it
|
|
references — into `tools/IconForge/work/`:
|
|
|
|
```bash
|
|
dotnet run --project tools/MosswartArt -- 0x02000B4F 0x10000344 tools/IconForge/work/mosswart_mesh.json 0x09000009
|
|
```
|
|
|
|
The trailing MotionTable id is required. Creatures do not define an upright pose
|
|
in `Setup.PlacementFrames`; without it every part stacks on the origin.
|
|
|
|
Then:
|
|
|
|
```bash
|
|
py tools/IconForge/forge.py client
|
|
```
|
|
|
|
This is deterministic too — given the same DATs it reproduces the committed
|
|
PNGs byte-for-byte.
|
|
|
|
Requires Python with `numpy`, `pillow` and `scipy`.
|
|
|
|
## How they are wired in
|
|
|
|
Neither icon is loaded from disk at runtime.
|
|
|
|
- **PE icon** — `<ApplicationIcon>` in each `.csproj`, pointing at the `.ico`
|
|
here. This is what Explorer and the taskbar shortcut show.
|
|
- **Client window icon** — `AcDream.App.Rendering.WindowIconLoader` hands GLFW
|
|
four sizes **from the `Load` callback**. That timing is load-bearing: Silk's
|
|
`Window.Create` only builds the managed object, and `IWindow.Initialize` is
|
|
what creates the native window, so applying an icon any earlier throws
|
|
"Window should be initialized". The failure is quiet and misleading — GLFW
|
|
falls back to the stock Windows application icon rather than the
|
|
executable's, so Explorer shows the mark and the running window does not.
|
|
The PNGs are *embedded resources* linked from this directory, so there is one
|
|
source of truth for the art and no missing-file case at runtime.
|
|
`WindowIconLoaderTests` guards both the resource names, which are otherwise
|
|
coupled to `LogicalName` in the csproj by string only, and the call-site
|
|
ordering.
|
|
- **Launcher window icon** — `AvaloniaResource` linked from here, referenced as
|
|
`avares://acdream-launcher/Assets/acdream-launcher.png`.
|