## Problem
Windows builds break with a current local toolchain (Scoop LLVM 22.1.8,
CMake 4.4.0, VS 2026), in two independent ways:
1. The build stops at curl's deliberate guard: `#error "no non-blocking
method was found/used/set"` in `third-party/curl/lib/nonblock.c`.
2. From the second configure onward, `cmake --build` re-runs CMake in an
endless loop (observed 42 consecutive reconfigure cycles in a single
build). Likely the same mechanism behind the "endlessly building" VS
2026 note in `docs/setup/dev/vs.md`.
## Root cause
1. `third-party/curl/CMake/CurlTests.c` passes `int *` to
`ioctlsocket()`, whose third parameter is `u_long *`. Clang 22 promotes
`-Wincompatible-pointer-types` to a hard error in C, so the
`HAVE_IOCTLSOCKET_FIONBIO` try_compile silently fails and
`curl_config.h` never defines it. Upstream CI does not see this because
the windows-2022 runner image ships an older LLVM. GCC 14 promotes the
same warning to a hard error, which is very likely the `CurlTests.c.obj`
failure reported from MSYS2 in open-goal/jak-project#3551. Upstream curl
hit the identical problem with GCC 14 and fixed the probe in curl 8.8.0
(curl/curl#13578).
2. The root CMakeLists copies the build tree's `compile_commands.json`
into `<src>/build/` for clangd using `configure_file()`, which registers
its input as a configure dependency. CMake rewrites
`compile_commands.json` late in every generation, after
`CTestTestfile.cmake` and `cmake_install.cmake` (outputs of the same
Ninja regen rule), so once the dependency is registered the rule is
deterministically dirty and every `ninja` invocation re-runs CMake. A
pristine first configure is safe (the file does not exist yet, so the
`if(EXISTS ...)` guard skips the copy), which is why the loop looks
machine- or IDE-specific.
## Fix
1. Per review, re-vendor `third-party/curl` at the `curl-8_21_0` tag
(previously `curl-8_3_0`), which carries the upstream probe fix plus two
years of upstream development; `vendor.yaml` updated to match.
Adjustments the version jump forced:
- curl 8.15 removed the native macOS Secure Transport backend
(`CURL_USE_SECTRANSP`), so macOS now builds curl against OpenSSL like
Linux. The two macOS workflows install Homebrew `openssl@3` and export
`OPENSSL_ROOT_DIR` (keg-only), and the macOS setup docs gained the same
two lines.
- `CURL_BROTLI` / `CURL_ZSTD` switched to AUTO-detection in curl 8.10;
pinned OFF to keep the previous no-compression behavior and avoid
silently linking whatever the CI images happen to have.
- curl's new top-level `BUILD_EXAMPLES` cache option (default ON) leaked
into discord-rpc's identically named option and broke configure at a
nonexistent `examples/send-presence` directory; pinned OFF ahead of the
third-party subdirectories.
The diff is dominated by the mechanical tag-tree swap under
`third-party/curl` (linguist-vendored, collapsed in review). The
hand-written changes are `CMakeLists.txt`, the two macOS workflows,
`docs/setup/system/macos.md`, and `vendor.yaml`.
2. Swap `configure_file()` for `file(COPY ...)`: the same clangd copy
with no configure dependency registered. (`file(COPY_FILE ...
ONLY_IF_DIFFERENT)` would be cleaner still but requires CMake 3.21,
above the declared `cmake_minimum_required(VERSION 3.10)`.)
## Test plan
- [x] Fresh `cmake --preset Release-windows-clang` (LLVM 22, no cache
seeding) completes and logs `Enabled SSL backends: Schannel`; the
FIONBIO probe passes without the previous `#error`
- [x] Full Windows Release build from scratch in the branch worktree
(all 1422 targets)
- [x] goalc-test suite: 1509 passed, 0 failed
- [x] Second consecutive configure with `compile_commands.json` present:
the regen rule in `build.ninja` has no `compile_commands.json` input;
`<src>/build/compile_commands.json` is still refreshed for clangd
- [x] Repeated `ninja` invocations after a full build no longer re-run
CMake
- [x] macOS Intel and ARM CI green (first exercise of the OpenSSL
backend switch)
---
I work off a self-hosted forge, so this GitHub account is quiet; the
configure logs and ninja dirty-node traces from the investigation are
available if anyone wants the raw data.
(AI-assisted)
This adds a debug server to `goalc` that sends JSON over the socket to
communicate with an external debugger using the Debug Adapter Protocol.
This lets us debug GOAL code in a proper debugger with breakpoints, step
over, step in and step out per line, stack frames and supports watches
for global symbols, registers and local variables (local variables only
work within the most recent stack frame). Special registers (`r13`,
`r14`, `r15`, argument registers, etc.) are tracked separately and the
current process register even displays the type of the current `pp` if
possible.
Watches that track addresses holding a reference type generate a list of
field names according to the object's type. All fields will show their
name, type and value and, depending on the type, will try to infer extra
info like symbol names/values, function names for `function` fields,
enum values and more. This also works nested, so any field that is also
a reference type can also be accessed and display its fields, etc.
Dynamic arrays are also supported where possible, e.g. in
`inline-array-class` children and boxed arrays, it will figure out the
value of the `length` field and access the memory up to that point so
all the elements can be accessed and viewed from the `data` field.
Our VS Code extension implements the DAP in
open-goal/opengoal-vscode#375.
Using it is as simple as connecting a REPL to a running game instance
with `(lt)`, compiling with `(mi)` and, with the extension installed,
pressing F5 in VS Code to start the debugger. By default, it will try to
connect to the game that the active `.gc` file is from, the socket port
is different per game (8128 for Jak 1, 8129 for Jak 2, 8130 for Jak 3).
The `launch.json` was updated with two entries for this, the second
entry lets you pick the game/port manually if desired.
~~Not tested on Windows.~~ Only supports x86 for now.
Added the file to have the menus of Jak 1 translated into Galician (main
menu, options, task/missions and their states, as well as some
minigames).
Already tested, at least on Windows 10, 4x3 aspect ratio and 1920x1080p
monitor.
--------
Translated and revised by: SilversHotsuin and Aziamuth
Inadvertently removed as part of improved decompiler stack variable
support #4222
We suspect this is the reason some nav-enemies have been randomly
disappearing in recent mods/versions
Thanks Evelyn for catching the regression
Fixes another long-standing subtitle translation bug.
There is a `merge` flag on each subtitle line, the idea being that we
would merge in the text from the base game if this was set. However in
jak 2 and beyond:
- The subtitles for english (base) are not predefined for the cutscenes,
only the hints. The rest are in the game files and we do not
simultaneously load both languages when the game is running so there is
no trivial fallback path.
- However, every subtitle language by default inherits the base games
metadata, where all `merge` flags are set to `true`
This means that all custom cutscene translations were being ignored
unless this flag was set to false in the metadata file for each line.
This is what finnish does since it changes the number of lines and their
timings, and is why it works fine.
This flag can probably be completely removed, as per the above, it
serves no actual purpose. All it does in our code is if it's set, we
skip the line when writing out the subtitle file.
But for now i simply just iterate through and flip these flags
automatically if the language overrode the cutscene. Tested on
english/finnish/pt-BR
<img width="648" height="467" alt="image"
src="https://github.com/user-attachments/assets/292e3dfe-df66-4d23-942a-b41f2b157bf8"
/>
Adds `game_base_text_pt-BR.json` — the missing base game text (menus,
options, mission tracker strings) for Brazilian Portuguese in Jak II.
The custom menu text and subtitles for pt-BR were already present in the
project; this fills in the last missing piece (`game_base_text`) needed
for the language to be fully usable in-game.
Tested in-game by switching to Portuguese and checking menus, pause
screen, and mission objective text.
Found while investigating the jak2/jak3 one-frame sky flicker (see the
fog CLUT inline payload PR: `#4343`).
## Problem
`TextureAnimator::run_clouds` calls `glGenerateMipmap` on the final
cloud texture while that texture is still attached to the currently
bound draw framebuffer (the `FramebufferTexturePairContext` is still in
scope). Reading a texture that is attached to the bound framebuffer is a
driver hazard even outside a draw call.
Every other site in this file already avoids this: `run_slime` and
`opengl_upload_resize_texture` both close the FBO context scope before
generating mipmaps. `run_clouds` is the one outlier, presumably an
oversight.
## Fix
Scope the `FramebufferTexturePairContext` in braces and generate the
mipmaps after it restores the previous framebuffer binding, matching the
established pattern in the rest of the file.
## Test plan
- [ ] jak2/jak3 clouds render identically (hires and normal cloud modes)
(AI-assisted)
basically initial commit to add support for polish base game text
needs work before you could push to master
im a little rusty so testing along side me if everything is working
would be appreciated
<img width="1919" height="1107" alt="jak2 pl menu"
src="https://github.com/user-attachments/assets/862dcbe0-1c6a-4b9e-9565-7aa91b0a9115"
/>
We already skip the "first autosave warning" prompt in speedrunner mode,
this just moves the check up a bit earlier, where it feels more
appropriate imo.
This also prevents a potential softlock from occurring in speedrunner
mode only, if you manage to bring up the progress menu while the first
autosave occurs/finishes (e.g. by pause buffering 7th scout fly, or one
of the citadel sage cells).
In that scenario, the `auto-save` process gets stuck in `done` state in
this loop because `progress-allowed?` is false due to the pending
powercell cutscene, and so we keep resetting `state-time`:
https://github.com/open-goal/jak-project/blob/d8710bb2f645528e598e2bd799708d9d945f76c6/goal_src/jak1/engine/game/game-save.gc#L1172-L1174
(in normal circumstances, this prevents the autosave prompt from popping
up during and shortly after the cell cutscene)
The problem is that the `progress` code has a sort of mirrored check,
where it will only `enter!` the next state if there is no `auto-save`
process:
https://github.com/open-goal/jak-project/blob/d8710bb2f645528e598e2bd799708d9d945f76c6/goal_src/jak1/pc/progress-pc.gc#L3600-L3609
Here's an example of the locked progress screen, I run some code in the
REPL to show the game is still running, and then use a breakpoint and
continue to artificially get past the `time-elapsed?` check in the
`auto-save` code
https://youtu.be/4eZlQbRq6l8
All that remains (8 instructions) are division, and NEON instructions
that require me to convert the x86 control byte to NEON `TBL` values.
Those handful of instructions can be done later while doing the next
steps (finally something more interesting than just encoding
instructions).
Namely all I did was include the normals from MercVertex in with the glb
exporter. I also converted parts of MercVertex to use union structs for
faster casting. The union structs should just work on most compilers
from what I researched, if not I can revert that and go a different
route for that.
Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
This implements the functionality for the `PLUGIN_MESSAGE` grain and the
989snd VAG plugin system, allowing sounds to queue up VAG streams.
Closes#2582
Less than 100 instructions left to implement, with the vast vast
majority being load-and-stores. These will likely be knocked out quickly
but they require a more involved implementation than just simply
translating the instructions (several need multiple instructions, others
may need reserved registers (x16 or x17 are common for this purpose))
This is a good milestone to get something pushed to master.
ImGUI does have ways to make sure the Internal IDs are unique and
separate from the display label, however I still thought that appending
a count to the end of the name was more clear/understandable.
If you add `ImGui::PushID(i);` Into the loop it appends i to the end of
the internal ID without modifying the display label. The other
alternative would be to use a syntax like
`ImGui::Button((controller_name + "##option1").c_str());` etc....
https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-how-can-i-have-multiple-widgets-with-the-same-label
In both cases I think just adding a number that increments communicates
that its a different controller cleaner to the user.
Closes#4289
This adds the blerc data from merc models to the GLB export as shape
keys, also including the data from animations. Blender is unfortunately
a bit weird about this and only really lets you change what animated
weights are used via the NLA track editor by selecting both the
corresponding armature animation and then the one for the shape keys.
Additionally, due to the way the Blender GLB import works when you have
animated weights on a model + animations as actions for an armature, any
models that have blerc data get an extra useless empty, but this seems
to be harmless.
This PR also fixes materials that use texture animations so they now
have their base texture in the export, rather than using the default
material. Materials now also get named after their base texture for
easier recognition.
The one crate with gold triple orb in temple doesn't update `(-> e extra
perm user-int8 1)` the way I was expecting based on how the one crate
that drops two orbs behaved. This check fixes that and is a bit simpler
This PR provides minor typo fixes and harmonizes the French subtitles
with the game's original terminology used in cutscenes and menus.
---------
Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
Three changes:
1. Add lazy merging/replacing for texture `rgba_bytes`.
2. Use a single thread when decompiling with texture replacements.
3. Drop textures after serializing and before compression.
These changes should enable users to install **massive** texture packs
without issue.
When `do_zoom_blur` sets up its draw, it doesn't update the blend
settings, so it ends up inheriting the previous values.
In retail mode, the previous draw is from a texture animation, which
sets up the blend in a specific way that causes it to draw a white
texture over the screen. In debug mode, right before the zoom blur is
drawn, the debug text is drawn, which modifies the blend settings to
something that makes the blur look as it should.
Closes#4206
This adds some buttons to the loader debug menu and GOAL functions to
allow you to manually force a reload of a level's FR3 data (including
the common level), allowing for live texture replacements, model swaps
and custom level modifications without requiring a game restart or
waiting for the loader to fully discard a level.
Implements the envmap for the ocean generated by
`ocean-method-89`/`ocean-method-88`.
While the resulting envmap looks accurate compared to PCSX2 in
Renderdoc, the end result does not seem 100% identical, but it is a big
improvement over the default placeholder texture.
Closes#3417
Once `(-> *display* game-clock frame-counter)` gets too large, in the
HUD flashing math the `sin` function breaks down at high values. It's
effectively reading the number of ticks (times a multiplier) as degrees,
so we can modulo that by 360 to avoid breaking `sin`
This applies to both the eco meter and the dark jak icon in jak 2 - the
icon stops flashing twice as early because it's multiplied by x4 vs the
eco meter x2.
example:
you can see dark jak icon stops flashing around 2:36:02
https://youtu.be/3V2GneLSY14?t=9362
and dark eco meter stops flashing between 4:30 and 4:37
https://youtu.be/3V2GneLSY14?t=16235https://youtu.be/3V2GneLSY14?t=16619
Alexander J. Semenuk