ported the implementation from jak 2 into jak3 pretty much exactly.
added a new color for L2 tricks, and shrunk the text/width a bit so it
wouldn't end up covered by the minimap.
also fixed small bug in jak 2 (and 3) where dismounting jetboard
wouldn't reset the trick display, so displayed score wouldn't match the
granted score
---------
Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
- `visvol-edit`
- `editable`
- `editable-player`
- `mysql-nav-graph`
- `nav-graph-editor`
- `nav-mesh-editor-h`
- `nav-mesh-editor`
The SQL data is not filled in yet.
Similar changes as have been done in the previous two games. Test the
following things:
- normal gameplay
- defend spargus turret
- satellite
- that desert mission where you shoot the gun
- that turret mission in haven forest
At a glance, i think that's everything...?
~~Didn't debug the crash yet either, hoping this is sufficient~~ (fixed,
thanks hatkid, needed to disable some blit related code)
Closes#4160
There was some bad manual decomp in `wasdef-manager` that caused the
mission to sometimes softlock, preventing Jak from exiting the turret
after destroying all Makers.
Also adds stick sensitivity setting from Jak 2 and fixes a regression
with the Light Jak freeze screen overlay on PC aspect ratios.
Closes#4179Closes#4154
Was investigating https://github.com/open-goal/jak-project/issues/3012
and found out it's no longer an issue, fixed at some point.
Updated the method name, it actually looks like quite a few methods were
nicely named / documented in jak 3, so i might automate backporting that
documentation (likely a bunch that can go all the way back to jak 1 as
well).
Closes#3012
Implement PC camera inversion toggles, for first/third
vertical/horizontal controls
Reuses vanilla placement of Camera Options menu (as opposed to under
Input Options like jak1/2)
fixes#4158
- jak 3 extractor config
- validation that extractor expected game matches the provided ISO (no
more drag and drop extractor for jak 2/3)
- jak 3 bug report template
This PR does the following:
- Designs a mechanism by which arm64 instructions can be encoded and
emitted
- Dispatch our higher-level instruction emitting calls to either x86 or
arm64 instructions depending on what the compiler is set to (defaults to
x86)
- Bare minimum scaffolding to get the arm64 instructions successfully
executing atleast on apple silicon
- Implement enough instructions to get the codetester test suite passing
on arm
This attempts to get into master whatever work was done in this PR /
it's earlier PR https://github.com/open-goal/jak-project/pull/3965
I don't want this work to be lost / floating around in massive PRs.
However the changes are:
- switch to ntsc_v1 instead of PAL as the development target, as we have
done for all other games
- remove most of the copied-from-jak2/3 changes as they need to be
confirmed during the decompilation process not just assumed
- avoids committing any changes to `game/kernel/common` as it was not
clear to me if these were changes made in jak x's kernel that were not
properly broken out into it's own functions. We don't want to
accidentally introduce bugs into jak1-3's kernel code.
- in other words, if the change in the kernel only happens in jak x...it
should likely be specific to jak x's kernel, not common.
---------
Co-authored-by: VodBox <dillon@vodbox.io>
Co-authored-by: yodah <greenboyyodah@gmail.com>
Massive overhaul of Finnish translations
I guess it's time to finally push this out
I'll go insane if I have to proofread one more time :P
Every time I just realize my translations sucked and I keep tweaking
everything
---------
Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
Fixes for:
- `prebot` sword attack and projectile speed (fixes#4050)
- Fast first person camera turning speed (fixes#4051)
- Slow turret camera turning speed (fixes#4052)
- `flyingsaw` movement and rotation speed (fixes#4053)
- Green eco drain rate on jetboard during `forest-kill-plants` mission
(fixes#4054)
- `skeet` rotation speed
- `maker-grenade` tumble speed
- Jetboard spin speed
- `hud-skill` rotation speed (also for jak2)
- `gun-dark-shot` projectile speed (also for jak2)
- `target-float` up/down speed (also for jak2)
- Texscroll speed
- Slow walk anim after landing from a jump
All stereo VAG commands would write to an out-of-bounds array element
and corrupt the whole VAG queue list.
Fixes random sound-related crashes including a consistent Light Jak
Freeze crash.
Resolves#3075
TODO before merge:
- [x] Properly draw non-korean strings while in korean mode (language
selection)
- [x] Check jak 3
- [x] Translation scaffolding (allow korean characters, add to Crowdin,
fix japanese locale, etc)
- [x] Check translation of text lines
- [x] Check translation of subtitle lines
- [x] Cleanup PR / some performance optimization (it's take a bit too
long to build the text and it shouldn't since the information is in a
giant lookup table)
- [x] Wait until release is cut
I confirmed the font textures are identical between Jak 2 and Jak 3, so
thank god for that.
Some examples of converting the korean encoding to utf-8. These show off
all scenarios, pure korean / korean with ascii and japanese / korean
with replacements (flags):
<img width="316" height="611" alt="Screenshot 2025-07-26 191511"
src="https://github.com/user-attachments/assets/614383ba-8049-4bf4-937e-24ad3e605d41"
/>
<img width="254" height="220" alt="Screenshot 2025-07-26 191529"
src="https://github.com/user-attachments/assets/1f6e5a6c-8527-4f98-a988-925ec66e437d"
/>
And it working in game. `Input Options` is a custom not-yet-translated
string. It now shows up properly instead of a disgusting block of
glyphs, and all the original strings are hopefully the same
semantically!:
<img width="550" height="493" alt="Screenshot 2025-07-26 202838"
src="https://github.com/user-attachments/assets/9ebdf6c0-f5a3-4a30-84a1-e5840809a1a2"
/>
Quite the challenge. The crux of the problem is -- Naughty Dog came up
with their own encoding for representing korean syllable blocks, and
that source information is lost so it has to be reverse engineered.
Instead of trying to figure out their encoding from the text -- I went
at it from the angle of just "how do i draw every single korean
character using their glyph set".
One might think this is way too time consuming but it's important to
remember:
- Korean letters are designed to be composable from a relatively small
number of glyphs (more on this later)
- Someone at naughty dog did basically this exact process
- There is no other way! While there are loose patterns, there isn't an
overarching rhyme or reason, they just picked the right glyph for the
writing context (more on this later). And there are even situations
where there IS NO good looking glyph, or the one ND chose looks awful
and unreadable (we could technically fix this by adjusting the
positioning of the glyphs but....no more)!
Information on their encoding that gets passed to `convert-korean-text`:
- It's a raw stream of bytes
- It can contain normal font letters
- Every syllable block begins with: `0x04 <num_glyphs> <...the glyph
bytes...>`
- DO NOT confuse `num_glyphs` with num jamo, because some glyphs can
have multiple jamo!
- Every section of normal text starts with `0x03`. For example a space
would be `0x03 0x20`
- There are a very select few number of jamo glyphs on a secondary
texture page, these glyph bytes are preceeded with a `0x05`. These jamo
are a variant of some of the final vowels, moving them as low down as
possible.
Crash course on korean writing:
- Nice resource as this is basically what we are doing -
https://glyphsapp.com/learn/creating-a-hangeul-font
- Korean syllable blocks have either 2 or 3 jamo. Jamo are basically
letters and are the individual pieces that make up the syllable blocks.
- The jamo are split up into "initial", "medial" and "final" categories.
Within the "medial" category there are obvious visual variants:
- Horizontal
- Vertical
- Combination (horizontal + a vertical)
- These jamo are laid out in 6 main pre-defined "orientations":
- initial + vertical medial
- initial + horizontal medial
- initial + combination
- initial + vertical medial + final
- initial + horizontal medial + final
- initial + combination + final
- Sometimes, for stylistic reasons, jamo will be written in different
ways (ie. if there is nothing below a vertical vowel will be extended).
- Annoying, and ND's glyph set supports this stylistic choice!
- There are some combination of jamo that are never used, and some that
are only used for a single word in the entire language!
With all that in mind, my basic process was:
- Scan the game's entire corpus of korean text, that includes subtitles.
It's very easy to look at the font texture's glyphs and assign them to
their respective jamo
- This let me construct a mapping and see which glyphs were used under
which context
- I then shoved this information into a 2-D matrix in excel, and created
an in-game tool to check every single jamo permutation to fill in the
gaps / change them if naughty dogs was bad. Most of the time, ND's
encoding was fine.
-
https://docs.google.com/spreadsheets/d/e/2PACX-1vTtyMeb5-mL5rXseS9YllVj32BGCISOGZFic6nkRV5Er5aLZ9CLq1Hj_rTY7pRCn-wrQDH1rvTqUHwB/pubhtml?gid=886895534&single=true
anything in red is an addition / modification on my part.
- This was the most lengthy part but not as long as you may think, you
can do a lot of pruning. For example if you are checking a 3-jamo
variant (the ones with the most permutations) and you've verified that
the medial jamo is as far up vertically as it can be, and you are using
the lowest final jamo that are available -- there is nothing to check or
improve -- for better or worse! So those end up being the permutations
between the initial and medial instead of a three-way permutation
nightmare.
- Also, while it is a 2d matrix, there's a lot of pruning even within
that. For example, for the first 3 orientations, you dont have to care
about final vowels at all.
- At the end, I'm left with a lookup table that I can use the encode the
best looking korean syllable blocks possible given the context of the
jamo combination.
I discovered that `yakow`s are kinda broken if you try to use them in
custom levels in jak 2/3.
It's due to the missing `yakow-lod0` texture and associated fix,
replacing it with `yak-medfur-end`. This solution works fine for the
decompiler on vanilla levels.
But for building custom levels, the requested art-groups were being
handled before the textures were, and so it was impossible to have
`yak-medfur-end` on hand to do the replacement. You'd hit an exception
here because `idx_in_level_texture` would still be `INT32_MAX`:
https://github.com/open-goal/jak-project/blob/c08118509b84feba002bd9e208f49162b4218556/decompiler/level_extractor/extract_merc.cpp#L806
My fix was just to swap the order when building custom levels, and
handle the textures first. I only made the changes for jak2/3, because I
see @Hat-Kid has a slightly different implementation for jak1.
There's one other small change relating to the `combo_id` /
`pc_combo_tex_id` short-circtuiting - I think `pc_combo_tex_id` is
always 0 for vanilla textures? So initially `yakow-lod0` actually ended
up matching the `combo_id` of the checkerboard texture from the
test-zone GLB. I just added another sanity check here that the texture
names match too.
(I also added yakows in the test-zone.jsonc files 🐄)
Fixes the pillars being transparent (but is a bit of a hack), the desert
sand not having texture filtering, and the "No memory card" on the title
screen with debug mode off.
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
This is a simple multiplier to the gamepad axis input value received
from SDL events. Normally the values it provides cannot satisfy the
square range of the stick input. This is usually fine but it might play
differently with different controllers and compared to consoles,
especially considering the DualShock 1/2 have automatic calibration
which works in mysterious ways. The setting is there so any user can
adjust it for their controllers.
Saved to and loaded from the input-settings.json file.
133% matches PCSX2's default setting and is generally a good value to
map the square stick range within most modern(ish) controllers' circular
stick motion.
Progress menu option added to Jak 1 and 2. Setting can be changed from
50% all the way to 200%.
~~Renamed the analog deadzone options to stick deadzone since they don't
apply to the other analog buttons and only the (analog, yes) sticks.~~
This PR updates to SDL3, and with it, adds a handful of new features.
Everything seems to work but I'm going to look over the code once last
time before merging, some of the API changes are hard to spot.
Fixes#2773
### Pressure sensitivity support for DS3 Controllers
SDL3 adds pressure sensitivity support for DS3 controllers on windows. I
have not tested on linux. The option is disabled by default.
On windows you will need https://docs.nefarius.at/projects/DsHidMini/
and to be using SXS mode.
### DualSense and Xbox One Trigger Effects
If enabled, Jak 2 will have certain trigger effects. They are:
- xbox1:
- small vibrate when collecting dark eco
- big vibrate when changing to dark jak
- vibrate when shooting gun, proportional to gun type
- ps5:
- resistance when changing to dark jak
- different gun shooting effects
- red (resistance)
- yellow (weapon trigger)
- blue (vibrates)
- purple (less resistance)
> **Gun Shooting effects are only enabled if the new "Swap R1 and R2"
option is enabled**
There are more effects that could be used in `dualsense_effects.cpp`,
but I only exposed the ones I needed to OpenGOAL. If a modder wants to
use some of the others and wires them up end-to-end, please consider
contributing that upstream.
### New ImGUI Menu
Added new imgui options for selecting the active controller, for those
people that struggle to select the initial controller.
### Testing
The highlights of what I tested successfully:
- display
- [x] all mode switch permutations
- [x] launch with all modes saved
- [x] switch monitors / unplug monitor that was active, how does it
handle it
- [x] load with alternate monitor saved and all modes
- [x] allowing hidpi doesnt break macos
- controls
- [x] keyboard and mouse still work
- [x] pressure sensitivity on linux
After the change to vector ops, subrails was crashing. This fixes the
crash by fixing a stack type and also marks those new vector op
functions as inline.
Co-authored-by: water111 <awaterford1111445@gmail.com>
This adds more recognition for inlined vector functions to the
decompiler, which can clean up a bunch of ugly looking code/`rlet`s.
Unfortunately, this changes the numbering of ops in the decomp, since
all the vector instructions get combined in a single "operation" by the
decompiler. I really tried to avoid having this ever happen in the
decompiler and this is one of the few cases where it has. So I had to
update a bunch of type casts.
For that reason I haven't turned this on in Jak 2 yet, although I am
planning to do that at some point. (probably at the same time as porting
back a bunch of jak 3 improvements to jak 2)
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
This PR does a few cleanups:
- improve method names/comments/flags for `enemy.gc` and a few other
files
- fix `new-stack-matrix0` not working for jak 3
- add `matrix-copy!` detection for jak 3
- add `vector-copy!` detection
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
Hat Kid