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
water111