ci(windows): build the Windows release files on the Linux runner #99

Merged

HumanBean merged 1 commit from HumanBean/Longshot:ci-windows-on-linux into main 2026-11-13 03:00:22 +00:00

Conversation 3 Commits 1 Files changed 10 +398 -86

HumanBean commented 2026-11-13 02:49:35 +00:00

Owner

• Copy link
• Copy Markdown

Why

There is no Windows runner, so every job asking for windows-2022 queues forever: the Windows builder zip, and with it every Longshot release, could never be made. This builds the Windows release files on the Linux runner we have.

What changed

• build (.forgejo/workflows/build-windows.yml): every job on ubuntu-24.04.

  • The setup (builder/setup/setup.c, setup.rc through windres) with llvm-mingw's Linux build of the release tools.lock pins (20261104). It is pinned by version, SHA-256 and size as LINUX_LLVM_MINGW in scripts/builder_package.py, and fetched with builder_package.py llvm-mingw --host linux (through tools.fetch, extracted with tarfile's data filter). --host defaults to the running system. The dav1d job now uses the same pin, not its own copy.
  • The WPF builder: dotnet publish -c Release --runtime win-x64 -p:EnableWindowsTargeting=true. It stays self-contained, a folder (not a single file), as the csproj's Release configuration has it.
  • The Windows Vulkan back end: RX_TARGET=windows (nx2/build.py's existing cross build), $(nproc) in place of $NUMBER_OF_PROCESSORS.
  • Two new steps: Check the Windows files and Start them under Wine (below).

• build (scripts/check_windows_files.py, new): it checks the zip as Windows files, catching what a non-Windows build could drop without a word:

  • the file list (top level, the builder folder, .NET's host/runtime, WPF managed and native parts, tools);
  • the setup: PE32+ x86-64, GUI subsystem, ICON/GROUP_ICON/MANIFEST/VERSIONINFO resources, imports only Windows' own, DependentLoadFlags 0x800;
  • the builder's apphost: GUI, VERSIONINFO and MANIFEST copied from the assembly;
  • the WPF Resource items in LongshotBuilder.dll;
  • runtimeconfig.json (self-contained Microsoft.NETCore.App and Microsoft.WindowsDesktop.App 8.x), and deps.json (.NETCoreApp,Version=v8.0/win-x64).

  --wine starts both under Wine in Xvfb, with no window and nothing downloaded.

• build (.forgejo/workflows/vulkan-dlss.yml): on ubuntu-24.04 with RX_TARGET=windows.

• ci (.forgejo/workflows/ci.yml): the windows-2022 matrix entries are gone. The Builder's compile and its worker-delivery check (tests/builder_workers) now run in Linux part 1 with EnableWindowsTargeting; the worker check passes on Linux's .NET with Linux's Python, 104 assertions. The MSVC step (cl on present_rect_test.cpp, test_invalidate_vcore.py --cxx cl) and the suite on Windows' Python move to RELEASING.md, Needs a Windows tester. Both C++ checks already run on Linux with GCC/Clang.

• tests (tests/test_windows_on_linux.py, new): it fails if any workflow names a Windows runner (runs-on or a matrix os). It also checks that LINUX_LLVM_MINGW is the release tools.lock pins, that the builder job publishes win-x64 with EnableWindowsTargeting and runs both checks, and that the csproj stays self-contained.

• docs: docs/forgejo-runners.md (no Windows runner needed; Windows files, built on Linux), RELEASING.md (new Needs a Windows tester; the rc step points to it; Bump a tool also bumps LINUX_LLVM_MINGW; one-time setup: Linux runners only), docs/releases.md (CI table and note), docs/control.md (the named-pipe tests are now a tester's).

Decisions:

• MSI: dropped from consideration, not ported. builder/msi/LongshotBuilder.wxs is not built by any workflow, and the release files (docs/releases.md, release.yml) have no MSI. So there is nothing to move to wixl. The source stays as it is.
• 15 checks RUN_ALL_SKIP skips on Linux (the setup's Win32 file/path handling, the portable homes, structured exceptions) are not run under Wine here. Each test runs the exe it builds directly. A --run wine option like test_dav1d_av1.py's would be a follow-up per test. Until then they are on the Windows tester's list.
• Signing: none before or now (no signtool step existed). No resource step is skipped: windres runs as before, and the SDK's apphost resource copy works on Linux (checked).

Flags and settings

None for the game or the builder. The one new option is CI's: scripts/builder_package.py llvm-mingw --host windows|linux (default: the running system) picks tools.lock's Windows llvm-mingw or the pinned Linux build; it is documented in the script's docstring.

Measurements

No runtime or game change: nothing to measure in the game. The build itself, below.

main: 5eaaf7fb (2026-11-12)
this PR: ci-windows-on-linux @ 8e5150d1 (on main @ 5eaaf7fb; built again after the rebase, the numbers below are this commit's)
Hardware: Ryzen, 24 threads, 30 GB, CachyOS Linux 7.3 (Docker)
Scene: n/a (CI)
Method: the build-windows.yml commands run in docker run ghcr.io/catthehacker/ubuntu:act-24.04 (the runner's job image), repo mounted; .NET 8.0.428 SDK from dotnet-install, wine64 9.0 and Xvfb from apt
How to reproduce: the job's steps as written, in that image

	main @ 5eaaf7fb	this PR @ 8e5150d1
Windows builder zip made	no (windows-2022 never runs)	yes: 73,930,773 bytes, 1608 files
LongshotBuilder-Setup.exe	no	193,536 bytes
longshot_vk.dll	no	13,417,984 bytes (from scratch: 86 s at 8 jobs); with LONGSHOT_FSR=1 also links

LongshotBuilder-v0.0.0-0-g8e5150d1-windows-x64.zip: 1608 files
the setup: PE32+ x86-64, subsystem 2, resources GROUP_ICON, ICON, MANIFEST, VERSIONINFO; imports api-ms-win-crt-*, bcrypt.dll, comctl32.dll, gdi32.dll, kernel32.dll, shell32.dll, user32.dll, winhttp.dll
the builder: PE32+ x86-64, subsystem 2, resources MANIFEST, VERSIONINFO; imports advapi32.dll, api-ms-win-crt-*, kernel32.dll, shell32.dll, user32.dll
the builder: .NETCoreApp,Version=v8.0/win-x64, self-contained Microsoft.NETCore.App 8.0.34, Microsoft.WindowsDesktop.App 8.0.34
ok
the setup under Wine: exit 1, error No built game to start. Build it first (the game folder needs bin\longshot.exe).
the builder under Wine: exit 1, error The build tools could not start: An error occurred trying to start process 'python' with working directory 'Z:\tmp\tmps_8qr3ma\LongshotBuilder\tools'. File not found.
ok

Testing

Tested:

• The package job's commands in the act-24.04 container: the setup, dotnet publish, builder_package.py package and zip, check_windows_files.py (output above).
• The Vulkan job's commands (RX_TARGET=windows, pinned headers) in the same container: longshot_vk.dll links, imports only KERNEL32, USER32 and the UCRT's api-ms-win-crt-*.
• dotnet build (Debug) of the builder, and the tests/builder_workers check on Linux: "Windows Builder worker checks passed (104 assertions)".
• Wine (9.0, wine64 from noble): the setup's --play <empty folder> and the builder's --cli both say why they stop. The builder needs Xvfb, because WPF's Application makes a hidden window first; without a display it throws in HwndWrapper. Wine's mscoree must stay enabled: overriding it off breaks loading .NET's IL assemblies ("Could not load System.Runtime.dll"). With those two settled it passed 6 of 6 runs, 5 of them from a fresh prefix, in about 9 s, so it is a workflow step.
• LONGSHOT_VULKAN_HEADERS=/usr/include python -I -B tests/run_all.py, interleaved, 2 runs each. main @ f41db065: 490 passed, 2 failed, 36 skipped (both runs). This PR: 491 passed, 2 failed, 36 skipped (both runs; +1 is test_windows_on_linux.py). The 2 failures are the same on both and known on main: test_bake_portability, test_builder_log_read_only. After the rebase onto main @ 5eaaf7fb, one more interleaved pair: main 491 passed, this PR 492 passed, the same 2 failures and 36 skipped on both.

Not tested:

• The workflows on the real runner: this PR's own CI run is the first.
• The DLSS link (vulkan-dlss.yml): not run locally, because it downloads NVIDIA's SDK under its license. The FSR 4 part linked locally.
• No Windows-built zip ever existed to diff against, since the windows-2022 job never ran. The comparison is against what that job specified. The setup comes from the same llvm-mingw release and command. .gitattributes forces LF, so checkout line endings can't differ. The builder's ApplicationIcon is conditional on work/longshot.ico, which no CI checkout has. So the WPF exe has no custom icon, as it would not have had on Windows either; the setup does have its icon.

Needs other testers:

• Windows 10/11: unzip the CI artifact, run LongshotBuilder.exe (setup installs the builder and tools), build from your own copy and reach the title screen. Expect the setup icon, the builder's fonts and image, and no SmartScreen/antivirus removal beyond what unsigned files got before (T-FCA3)
• Windows with Python and VS 2022: python -I -B tests/run_all.py --strict, plus the MSVC commands in RELEASING.md, Needs a Windows tester. Expect everything to pass (T-FCA3)

Screenshots

Nothing on screen

Risk and rollback

If a Windows file built on Linux differs from a Windows build in a way the checks don't cover, the symptom would be a broken install for Windows players. That is what the rc's Windows tester step is for. Reverting the commit restores the windows-2022 jobs, which would again queue forever without a Windows runner.

Reviewer notes

Start with build-windows.yml's package job and scripts/check_windows_files.py.

RELEASING.md and docs/releases.md are shared byte-identical with MagicBeanDev/LongshotLauncher: this commit's changes to both need copying there.

Issues

None

Checklist

For everyone

• One topic.
• The title is a Conventional Commit (type(scope): description).
• Rebased on current main.
• python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
• Tested in the game, or what wasn't is named under Testing.
• Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
• Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
• No game files, dumps, build output or generated files.
• third_party/ untouched (a new folder with a PROVENANCE.md instead).
• The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

• A game-free test added for the fix, failing on main and passing here.
• A check under tests/ that reads changed source updated in this PR, not weakened. (test_recomplauncher_json.py and test_ship_state_list.py read build-windows.yml and builder_package.py and pass unchanged; the new test_windows_on_linux.py reads the workflows and builder_package.py.)
• Docs updated.

<!-- Open as work in progress (a "WIP: " title; forge.py pr create does it) and mark it ready (forge.py pr ready) once every section and every For everyone box is done. Keep this description current, and post a comment for each new commit, measurement or test run: CONTRIBUTING.md, "Commits and pull requests". --> ## Why There is no Windows runner, so every job asking for `windows-2022` queues forever: the Windows builder zip, and with it every Longshot release, could never be made. This builds the Windows release files on the Linux runner we have. ## What changed - build (`.forgejo/workflows/build-windows.yml`): every job on `ubuntu-24.04`. - The setup (`builder/setup/setup.c`, `setup.rc` through `windres`) with llvm-mingw's **Linux** build of the release `tools.lock` pins (20261104). It is pinned by version, SHA-256 and size as `LINUX_LLVM_MINGW` in `scripts/builder_package.py`, and fetched with `builder_package.py llvm-mingw --host linux` (through `tools.fetch`, extracted with tarfile's `data` filter). `--host` defaults to the running system. The dav1d job now uses the same pin, not its own copy. - The WPF builder: `dotnet publish -c Release --runtime win-x64 -p:EnableWindowsTargeting=true`. It stays self-contained, a folder (not a single file), as the csproj's Release configuration has it. - The Windows Vulkan back end: `RX_TARGET=windows` (nx2/build.py's existing cross build), `$(nproc)` in place of `$NUMBER_OF_PROCESSORS`. - Two new steps: **Check the Windows files** and **Start them under Wine** (below). - build (`scripts/check_windows_files.py`, new): it checks the zip as Windows files, catching what a non-Windows build could drop without a word: - the file list (top level, the builder folder, .NET's host/runtime, WPF managed and native parts, tools); - the setup: PE32+ x86-64, GUI subsystem, `ICON`/`GROUP_ICON`/`MANIFEST`/`VERSIONINFO` resources, imports only Windows' own, `DependentLoadFlags` 0x800; - the builder's apphost: GUI, `VERSIONINFO` and `MANIFEST` copied from the assembly; - the WPF `Resource` items in `LongshotBuilder.dll`; - `runtimeconfig.json` (self-contained `Microsoft.NETCore.App` and `Microsoft.WindowsDesktop.App` 8.x), and `deps.json` (`.NETCoreApp,Version=v8.0/win-x64`). `--wine` starts both under Wine in Xvfb, with no window and nothing downloaded. - build (`.forgejo/workflows/vulkan-dlss.yml`): on `ubuntu-24.04` with `RX_TARGET=windows`. - ci (`.forgejo/workflows/ci.yml`): the `windows-2022` matrix entries are gone. The Builder's compile and its worker-delivery check (`tests/builder_workers`) now run in Linux part 1 with `EnableWindowsTargeting`; the worker check passes on Linux's .NET with Linux's Python, 104 assertions. The MSVC step (`cl` on `present_rect_test.cpp`, `test_invalidate_vcore.py --cxx cl`) and the suite on Windows' Python move to RELEASING.md, *Needs a Windows tester*. Both C++ checks already run on Linux with GCC/Clang. - tests (`tests/test_windows_on_linux.py`, new): it fails if any workflow names a Windows runner (`runs-on` or a matrix `os`). It also checks that `LINUX_LLVM_MINGW` is the release `tools.lock` pins, that the builder job publishes `win-x64` with `EnableWindowsTargeting` and runs both checks, and that the csproj stays self-contained. - docs: `docs/forgejo-runners.md` (no Windows runner needed; *Windows files, built on Linux*), `RELEASING.md` (new *Needs a Windows tester*; the rc step points to it; *Bump a tool* also bumps `LINUX_LLVM_MINGW`; one-time setup: Linux runners only), `docs/releases.md` (CI table and note), `docs/control.md` (the named-pipe tests are now a tester's). **Decisions:** - **MSI:** dropped from consideration, not ported. `builder/msi/LongshotBuilder.wxs` is not built by any workflow, and the release files (`docs/releases.md`, `release.yml`) have no MSI. So there is nothing to move to `wixl`. The source stays as it is. - **15 checks `RUN_ALL_SKIP` skips on Linux** (the setup's Win32 file/path handling, the portable homes, structured exceptions) are not run under Wine here. Each test runs the exe it builds directly. A `--run wine` option like `test_dav1d_av1.py`'s would be a follow-up per test. Until then they are on the Windows tester's list. - **Signing:** none before or now (no `signtool` step existed). No resource step is skipped: `windres` runs as before, and the SDK's apphost resource copy works on Linux (checked). ## Flags and settings None for the game or the builder. The one new option is CI's: `scripts/builder_package.py llvm-mingw --host windows|linux` (default: the running system) picks tools.lock's Windows llvm-mingw or the pinned Linux build; it is documented in the script's docstring. ## Measurements No runtime or game change: nothing to measure in the game. The build itself, below. main: 5eaaf7fb (2026-11-12) this PR: ci-windows-on-linux @ 8e5150d1 (on main @ 5eaaf7fb; built again after the rebase, the numbers below are this commit's) Hardware: Ryzen, 24 threads, 30 GB, CachyOS Linux 7.3 (Docker) Scene: n/a (CI) Method: the build-windows.yml commands run in `docker run ghcr.io/catthehacker/ubuntu:act-24.04` (the runner's job image), repo mounted; .NET 8.0.428 SDK from dotnet-install, wine64 9.0 and Xvfb from apt How to reproduce: the job's steps as written, in that image | | main @ 5eaaf7fb | this PR @ 8e5150d1 | |---|---|---| | Windows builder zip made | no (windows-2022 never runs) | yes: 73,930,773 bytes, 1608 files | | `LongshotBuilder-Setup.exe` | no | 193,536 bytes | | `longshot_vk.dll` | no | 13,417,984 bytes (from scratch: 86 s at 8 jobs); with `LONGSHOT_FSR=1` also links | ``` LongshotBuilder-v0.0.0-0-g8e5150d1-windows-x64.zip: 1608 files the setup: PE32+ x86-64, subsystem 2, resources GROUP_ICON, ICON, MANIFEST, VERSIONINFO; imports api-ms-win-crt-*, bcrypt.dll, comctl32.dll, gdi32.dll, kernel32.dll, shell32.dll, user32.dll, winhttp.dll the builder: PE32+ x86-64, subsystem 2, resources MANIFEST, VERSIONINFO; imports advapi32.dll, api-ms-win-crt-*, kernel32.dll, shell32.dll, user32.dll the builder: .NETCoreApp,Version=v8.0/win-x64, self-contained Microsoft.NETCore.App 8.0.34, Microsoft.WindowsDesktop.App 8.0.34 ok the setup under Wine: exit 1, error No built game to start. Build it first (the game folder needs bin\longshot.exe). the builder under Wine: exit 1, error The build tools could not start: An error occurred trying to start process 'python' with working directory 'Z:\tmp\tmps_8qr3ma\LongshotBuilder\tools'. File not found. ok ``` ## Testing **Tested:** - The package job's commands in the `act-24.04` container: the setup, `dotnet publish`, `builder_package.py package` and `zip`, `check_windows_files.py` (output above). - The Vulkan job's commands (`RX_TARGET=windows`, pinned headers) in the same container: `longshot_vk.dll` links, imports only `KERNEL32`, `USER32` and the UCRT's `api-ms-win-crt-*`. - `dotnet build` (Debug) of the builder, and the `tests/builder_workers` check on Linux: "Windows Builder worker checks passed (104 assertions)". - Wine (9.0, wine64 from noble): the setup's `--play <empty folder>` and the builder's `--cli` both say why they stop. The builder needs Xvfb, because WPF's `Application` makes a hidden window first; without a display it throws in `HwndWrapper`. Wine's `mscoree` must stay enabled: overriding it off breaks loading .NET's IL assemblies ("Could not load System.Runtime.dll"). With those two settled it passed 6 of 6 runs, 5 of them from a fresh prefix, in about 9 s, so it is a workflow step. - `LONGSHOT_VULKAN_HEADERS=/usr/include python -I -B tests/run_all.py`, interleaved, 2 runs each. main @ f41db065: 490 passed, 2 failed, 36 skipped (both runs). This PR: 491 passed, 2 failed, 36 skipped (both runs; +1 is `test_windows_on_linux.py`). The 2 failures are the same on both and known on main: `test_bake_portability`, `test_builder_log_read_only`. After the rebase onto main @ 5eaaf7fb, one more interleaved pair: main 491 passed, this PR 492 passed, the same 2 failures and 36 skipped on both. **Not tested:** - The workflows on the real runner: this PR's own CI run is the first. - The DLSS link (`vulkan-dlss.yml`): not run locally, because it downloads NVIDIA's SDK under its license. The FSR 4 part linked locally. - No Windows-built zip ever existed to diff against, since the windows-2022 job never ran. The comparison is against what that job specified. The setup comes from the same llvm-mingw release and command. `.gitattributes` forces LF, so checkout line endings can't differ. The builder's `ApplicationIcon` is conditional on `work/longshot.ico`, which no CI checkout has. So the WPF exe has no custom icon, as it would not have had on Windows either; the setup does have its icon. **Needs other testers:** - Windows 10/11: unzip the CI artifact, run `LongshotBuilder.exe` (setup installs the builder and tools), build from your own copy and reach the title screen. Expect the setup icon, the builder's fonts and image, and no SmartScreen/antivirus removal beyond what unsigned files got before (T-FCA3) - Windows with Python and VS 2022: `python -I -B tests/run_all.py --strict`, plus the MSVC commands in RELEASING.md, *Needs a Windows tester*. Expect everything to pass (T-FCA3) ## Screenshots Nothing on screen ## Risk and rollback If a Windows file built on Linux differs from a Windows build in a way the checks don't cover, the symptom would be a broken install for Windows players. That is what the rc's Windows tester step is for. Reverting the commit restores the windows-2022 jobs, which would again queue forever without a Windows runner. ## Reviewer notes Start with `build-windows.yml`'s package job and `scripts/check_windows_files.py`. `RELEASING.md` and `docs/releases.md` are shared byte-identical with MagicBeanDev/LongshotLauncher: this commit's changes to both need copying there. ## Issues None ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. (`test_recomplauncher_json.py` and `test_ship_state_list.py` read `build-windows.yml` and `builder_package.py` and pass unchanged; the new `test_windows_on_linux.py` reads the workflows and `builder_package.py`.) - [x] Docs updated.

HumanBean commented 2026-11-13 02:50:46 +00:00

Author

Owner

• Copy link
• Copy Markdown

Description filled in: what changed, the MSI and Wine decisions, the container run of the package and Vulkan jobs (artifacts and sizes), and the interleaved test runs (main 490 passed / this PR 491 passed, the same 2 known failures on both).

Description filled in: what changed, the MSI and Wine decisions, the container run of the package and Vulkan jobs (artifacts and sizes), and the interleaved test runs (main 490 passed / this PR 491 passed, the same 2 known failures on both).

HumanBean force-pushed ci-windows-on-linux from 6943794c78 to 8e5150d1de 2026-11-13 02:55:02 +00:00 Compare

HumanBean commented 2026-11-13 02:55:57 +00:00

Author

Owner

• Copy link
• Copy Markdown

Rebased onto main @ 5eaaf7fb (now 8e5150d1). Built again there in the act-24.04 container: the zip is 73,930,773 bytes with 1608 files, the setup 193,536 bytes, longshot_vk.dll 13,417,984 bytes; the file checks and both Wine starts pass. One more interleaved test pair: main 491 passed, this PR 492 passed, with the same 2 known failures. The description follows the updated template (Flags and settings, If applicable).

Rebased onto main @ 5eaaf7fb (now 8e5150d1). Built again there in the act-24.04 container: the zip is 73,930,773 bytes with 1608 files, the setup 193,536 bytes, longshot_vk.dll 13,417,984 bytes; the file checks and both Wine starts pass. One more interleaved test pair: main 491 passed, this PR 492 passed, with the same 2 known failures. The description follows the updated template (Flags and settings, If applicable).

HumanBean commented 2026-11-13 02:56:25 +00:00

Author

Owner

• Copy link
• Copy Markdown

Opened the Windows test request T-FCA3 (the builder end to end; the suite on Windows' Python and the MSVC checks).

Opened the Windows test request T-FCA3 (the builder end to end; the suite on Windows' Python and the MSVC checks).

HumanBean changed title from WIP: ci(windows): build the Windows release files on the Linux runner to ci(windows): build the Windows release files on the Linux runner 2026-11-13 02:56:26 +00:00

HumanBean merged commit 2a2da67f2b into main 2026-11-13 03:00:22 +00:00

HumanBean deleted branch ci-windows-on-linux 2026-11-13 03:00:22 +00:00

HumanBean referenced this pull request from a commit 2026-11-13 03:00:22 +00:00

ci(windows): build the Windows release files on the Linux runner (#99)

llun referenced this pull request 2026-11-13 03:02:42 +00:00

feat(ui): the HUD laid out for every screen shape at its 16:9 size, anchored to the screen's edges #95

mooki referenced this pull request 2026-11-13 04:10:00 +00:00

ci(windows): optionally sign builder executables with Authenticode #98

mooki referenced this pull request 2026-11-13 04:10:00 +00:00

ci(windows): optionally sign builder executables with Authenticode #98

d4nkn3ss referenced this pull request 2026-11-13 07:24:12 +00:00

fix(release): the Windows zip carries tools/version.txt, so a release's game and builder know their version #149

HumanBean referenced this pull request from a commit 2026-11-13 09:06:04 +00:00

fix(release): the Windows zip carries tools/version.txt, so a release's game and builder know their version (#149)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area/accessibility

Barriers for people with disabilities

  

area/audio

Sound and music

  

area/input

Controllers, keyboard, mouse

  

area/install

Installing, updating, building from your game

  

area/menu

In-game menu and settings

  

area/renderer

Vulkan renderer, shaders, effects

  

area/saves

Save files

  

area/upscaling

DLSS, FSR, frame generation

  

good first issue

A good start for a new contributor

  

gpu/amd

AMD GPUs

  

gpu/igpu

Integrated GPUs

  

gpu/intel

Intel GPUs

  

gpu/nvidia

NVIDIA GPUs

  

help wanted

Extra hands or knowledge wanted

  

kind

bug

Something doesn't work as it should

  

kind

chore

Build, CI, dependencies, tidying

  

kind

docs

Documentation

  

kind

feature

A new feature or an improvement

  

kind

performance

Frame rate, frame time, loading, memory

  

kind

question

A question rather than a change

  

needs measurements

Waiting for before/after measurements

  

platform/linux

Linux only

  

platform/steam-deck

Steam Deck

  

platform/windows

Windows only

  

preview

Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  

priority

critical

Crashes, data loss, or blocks most players

  

priority

high

Important: next in line

  

priority

low

Nice to have

  

status

blocked

Waits on something else first

  

status

confirmed

Reproduced or agreed on

  

status

duplicate

Already reported or proposed

  

status

invalid

Not a problem in this project

  

status

needs-info

Waiting for more information from the reporter

  

status

wontfix

Will not be worked on

  

testing wanted

Wanted: a test on other hardware (posts a test request in #test-requests)

No labels

area/accessibility

area/audio

area/input

area/install

area/menu

area/renderer

area/saves

area/upscaling

good first issue

gpu/amd

gpu/igpu

gpu/intel

gpu/nvidia

help wanted

kind

bug

kind

chore

kind

docs

kind

feature

kind

performance

kind

question

needs measurements

platform/linux

platform/steam-deck

platform/windows

preview

priority

critical

priority

high

priority

low

status

blocked

status

confirmed

status

duplicate

status

invalid

status

needs-info

status

wontfix

testing wanted

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot!99

No description provided.