Adds support for exporting animations for foreground models. It's not
perfect and doesn't handle the Jak 2/3 animations very well in some
cases (scale can often get messed up, especially for the LZO compressed
ones, I have no idea what is going on with the data in those art groups
sometimes, so that'll have to be revisited later...), but it does a
decent job on Jak 1.
Additionally, the `build-actor` tool has also been changed to support
setting the `master-art-group-name` and `master-art-group-index` fields
to allow for custom art groups to link their animations to a different
master art group, which lets you add custom animations to vanilla art
groups.
Closes#1496
This brings back the SCE splash screens. Also adds a runtime flag
`-nosplash` to skip it. Right now, it's on by default, but open to
changes on that (maybe always disable in debug to speed up start times,
etc.).
fixes#3150
the scoring system counts up to 16 (point-scoring) tricks, but the
opengoal-secret display system was ignoring the 16th one, causing score
discrepancies
This bit of ff-squad-control code is trying to sort guards based on
their distance from some shared target. In some cases the
`vector-vector-distance` returns NaN. In the bubble sort below this
change, the < operation always returns #t when NaN is involved, so the
NaN guard gets swapped back and forth endlessly, causing an infinite
loop.
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 <[email protected]>
addresses:
- starting new game from title screen with speedrun mode on -> shows
intro cutscene, doesn't start autosplitter, verification text not shown
- resetting run during intro cutscene leaves weird desert state across
training course (not an issue if we fix^)
- reset in hero mode after completing training course -> verification
text not shown
- resetting during tentacle grab leaves the water bubble sound playing
forever
Three fixes for fullscreen map screens:
**1. Expand scanlines to cover whole screen**
Instead of just the 4:3 square, scales dynamically without overshooting.
**2. Fix map icon stretching**
On a real PS2, map icons squash incorrectly at 16:9, gets worse with
custom aspects. Fixed but preserves original game bug at PS2 16:9.
**3. Stop fast map scrolling at high FPS**
Same map scroll speed regardless of framerate.
Fixes#4195
Fixes#4177
Also additionally fixes the setting not doing anything to the
terraformer tentacles. Tentacles are no longer considered 'solid' when
dead while the setting is on.
- `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.
Closes#4183
Jak 2 didn't have this logging call so its fine, but jak 3 added this
which is a nice idea. TLDR - there's some settings we stopped loading
from the memcard as the source of truth, this function (`load-game...`)
skips said portions of the save file and in jak 3, includes a helpful
log message.
It constructed that log message by calling a `defun-debug` function,
which means that in retail mode, that function is gone, instead of that
being a straight forward crash, it returns garbage, which is passed to
`format`, which causes the crash. Fix is simple, make it a non-debug
function so it's always available.
Feels like something that could be improved about `goalc` but,
be-careful with debug only functions is the take away.
This would seem to impact any save file that wrote these related tags
(and thus, triggered the logging code) but it might also be semi-random
with how unlucky you get with the returned garbage addr
Hopefully the excluded languages are correct, it's a bit hard to tell
without testing since there seems to be some languages/localization in
the original game that was abandoned / not complete.
So some of these (depending on the version you use as well) may only be
partially done in the final games and will require translation -- which
is a perfect job for a translator to investigate.
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
Took @ManDude 's suggestion to make the sandstorm's push effect on Jak
slightly less aggressive, to better match the effect on PS2 where it
never hits 60fps. This was especially noticeable in finalboss. Tested at
higher FPS as well
- Fixed font scaling for main menu options and auto save info box
- Removed surround sound option (we probably won't be implementing this
any time soon)
Discord RPC fixes/additions:
- Now shows what gun you currently have out
- Fixed outdoor levels not showing their icons
- Added icons for vehicles and various other states
- Fixed glider mission not displaying
Exact same changes as jak 2, except I have the left trigger effect moved
from `target-darkjak-get-on` to `target-powerjak-get-on` (the crouching
state before he goes to dark or light jak)
a bit of a hack but I'm not sure what else to do besides completely
unload/reload wasstadb-obs. open to suggestions
here is the bug
https://youtu.be/C1KZlRFbjys?t=50
Title casing was done in this script (which we used when going from jak1
to jak2) because we went from a game that had no lowercase letters, to
one with them.
Not the case for jak2 -> jak3, strings recopied correctly without
changing the casing.
Did this while investigating #3299 which I could not reproduce.
ImGui's had a recent version that allows for dynamically scaling the
font, pretty cool, slightly improves our styling menu.
Closes#3299
- 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
If these were not meant to be changed, they should be updated on crowdin
-- I did not check (maybe they were), but on the next translation update
I will assume whatever comes from crowdin is correct.
The particles for the grey memcard slots already had functions
associated with them, so scaling the grey boxes was simply a matter of
making use of those functions.
The memcard boxes expand and shrink with the aspect to resemble the PS2
behavior, where at 4:3 you get a short grey box and at 16:9 you get a
long grey box.
Although I added scaling to the grey boxes, I wasn't satisfied with the
way elements would "slip" as they would scale differently to each other.
Mainly, the collectable counts and their totals slide more and more off
from each other.
This is due to the game's use of integer offsets to decided UI
placements; they were the right numbers for 4:3, but once you start to
scale, they can slide more and more off. You can see this on a real PS2,
where at 4:3, the collectibles are centered above the totals, and at
16:9, the collectibles are more right-aligned above the totals.
To fix this, I used the same text flags on the totals as the counts, so
everything is snapped to each other.
Guards against `(-> *pc-settings* use-vis?)` ensure PS2 aspects remain
untouched, and at PS2 16:9, you still get the original game bug of more
right aligned counts.
https://github.com/user-attachments/assets/0fa00a5d-0090-4cd0-b68b-8b8f28816185
I'm switching away from visual studio (because its broken) so figured
I'd document / commit the minimum to get a working environment with the
editor I chose (Zed).
Also cleaned up the main README so it's not so verbose, link out to
secondary pages, etc.
I also deleted the Arch and Fedora dockerfiles, they were broken. The
ubuntu one still works, so i left it.
The `Split Boxes` option in jak2/3 currently crashes as soon as you
select it because of the `*debug-region-hide-empty*` code added in
openGOAL. The split boxes aren't true regions, but they reuse the
`debug-draw-region` functions, and crash trying to access `(-> this
region on-enter)`.
<img width="2160" height="1620" alt="image"
src="https://github.com/user-attachments/assets/e8753fcc-8234-40fa-9278-d2dca4dff71a"
/>
yay split boxes
Based on [similar changes we made awhile back for
jak1](https://github.com/open-goal/jak-project/pull/3902) - this way
runners don't need to figure out the -0.3s offset or whatever, and it
won't vary based on where they reset from.
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 <[email protected]>
Co-authored-by: yodah <[email protected]>
Fixes https://github.com/open-goal/jak-project/issues/2635 by zeroing
out the volume of the VAG command on the first chunk upload. This isn't
a "true" fix because I'm only addressing the symptom instead of the
actual problem.
But this did allow me to complete Mountain Temple without a single chirp
of static from the `mtn-step-plat-rocks` explosion sounds. They were
completely silent until I hit their buttons. All other sounds in the
game, to my untrained ears, sounded unaffected.
As an additional concern, I clear the IOP threads' `waitType` whenever
their `state` is set to Ready. This didn't seem to affect the sound bug,
but it seemed to be "the right thing to do." Will happily remove this
from the PR if it's deemed unnecessary, extraneous, or ought to be
addressed separately.
If the `arg0` vector has extreme values, `a2-0` and `a1-1` can end up
being negative, which leads to out-of-bounds access when using these
values to read from the `xz-height-map`'s `data` array, and crashes the
game (you can pretty easily reproduce this in jak 3 by overcharging the
"superfasthoverbikeglitch")
The `min` here already makes sure these values don't go too high, but
doesn't cover the case when they go negative.
As I understand it, this `data` in the `*traffic-height-map*` functions
as a 2d array, bucketing x/z coordinates into heights for the vehicle.
Looking at the balance-plats, they showed an immediate visual clue,
which was the stuttering of Jak's feet on their surface.
This is precisely what happens when you don't include sticky on a
collision; it doesn't "pull" Jak along with it, and he repetitively
"falls" onto it's surface over and over as it moves downwards.
This is a mystery, since this actor does have sticky, in fact, it's not
even possible to detect riders without sticky, which these certainly do.
This same appears on PS2, so I knew fixing it was not an option.
I had an immediate theory of what was happening: since Jak is
continuously falling onto it as it moves downwards, he's only riding
some frames, and skipping others. A higher frame rate = more moments
he's touching.
This means that basically, the balance-plat's entire speed is determined
by when his feet happen to micro-stutter. This is the hardcoded scalar
for it's entire speed.
This means I needed to emulate the 60 FPS "falling" at different
framerates. I tried adding an fps counter to the actor so that the rider
check only ran once every 60th of a second, but I knew adding a variable
to the actor just for fps wasn't a good idea.
However, I was able to confirm that would work. Luckily, this
[comment](https://github.com/open-goal/jak-project/blob/0fa93ce7b83d1621f3fd040625bfa865eadaeef0/goal_src/jak1/engine/game/game-h.gc#L116)
gave me an idea, which meant I could use a variable of process drawable,
avoiding adding a variable.
This unique problem needs a unique solution, I gate rider checks so they
only pass if one sixtieth of a second `(seconds 0.01666666)` has passed
since the last ride. This makes it act like his feet are stuttering like
they do at 60 FPS, avoiding the extra frames where his feet are touching
at high framerates that add more speed.
I also added the same for the send-to messages, since at high frame
rates the passive return to center that runs every frame was stomping
the send-to-next velocities which run less often.
Then, I managed to refactor it down to a tiny edit, a guard in one place
that gates on 1/60th of a second, framerate already 60, or, self grow
(since you don't want to double-gate these).
```lisp
(when (or (= (-> *pc-settings* target-fps) 60)
(time-elapsed? (-> self state-time) (seconds 0.01666666))
(-> self got-grow))
```
It's just: this guard, `(set-state-time)` on ride, and
`(set-state-time)` on grow (limits increased-rate return to center
stomping grow).
Lastly, there was an issue with the existing multiplies by FPS RATIO,
which was a clear double scale of the acceleration (once when setting
accelerate, then again when adding the accelerate). I'm guessing since
the extra riding frames added so much speed, this double scalar helped
slow it down, however when corrected the double scalar made it too slow
since it was slowing down for framerate twice.
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 <[email protected]>
I was changing aspect ratios when I noticed something was off, getting
different results for the same setting.
On screen positions are determined by both the aspect ratio you select
as well as the last time you selected a PS2 aspect ratio.
You get different result by choosing 4x3 (PS2), then 16:9, compared to
16:9 (PS2), then 16:9. The same is true for all aspects and Fit to
Screen.
By contrast, Jak 2 always uses the 'aspect4x3 scale factor for all
custom aspects, making the menu option you select consistent.
There is an intention to use 4x3 for custom aspects
[here](https://github.com/open-goal/jak-project/blob/abf27960f0033436b066c712c787160d2c9a5346/goal_src/jak1/pc/progress-pc.gc#L2618);
when `fit-to-screen` then `(set-aspect-ratio 'aspect4x3)`. However it
needs the extra lines to take effect.
This is helpful as the only cause of vertical misalignment on memory
cards is using PS2 16x9 on custom aspects:
<img width="1800" height="1013" alt="2"
src="https://github.com/user-attachments/assets/5a5e5ea9-00fc-439b-b3d6-dcf3419a8bd1"
/>
<img width="1800" height="1013" alt="4"
src="https://github.com/user-attachments/assets/4876d267-5a44-4074-bd63-d7a5d8ac02e5"
/>
So `target` has some logic here which checks if the pending attack has
the same ID as the last attack, and if so it checks for a 2s grace
period `(-> *TARGET-bank* same-attack-invulnerable-timeout)` before the
attack will actually count:
https://github.com/open-goal/jak-project/blob/7320bfc068acfa385f929b176f61caf3b7aabbbe/goal_src/jak3/engine/target/target-util.gc#L1664-L1674
This `same-attack-invulnerable-timeout` check uses `time-elapsed?`,
which under the hood references `(current-time)` AKA `(-> PP clock
frame-counter)`, which makes sense.
However the code that actually stores the `attack-time` uses a different
clock `(-> *display* base-clock frame-counter)`:
https://github.com/open-goal/jak-project/blob/7320bfc068acfa385f929b176f61caf3b7aabbbe/goal_src/jak3/engine/target/target-util.gc#L1765-L1768
So if these two clocks get out of sync - say the `target` process clock
falls behind the `*display*` clock - then we can end up storing an
`attack-time` that's "in the future" from `target`'s perspective,
effectively increasing the `same-attack-invulnerable-timeout`.
This clock drift can happen in real gameplay - Usual today was having it
happen consistently with the route he was attempting for NoOOB. I was
able to reproduce it consistently in OpenGOAL as well:
- get "invuln 2" (i.e. you have `(target-flags disable-attacks)` but not
`(focus-status dead ignore)`)
- restart mission at the top of temple before the glider mission trigger
- immediately go into the trigger and fall off the cliff (during the
black screen)
- you'll get the glider cutscene, but should respawn back at the bottom
of temple
Somewhere in this^ cutscene/blackout, the two clocks drift apart -
presumably `target`'s clock is paused but the other is not. Later in the
speedrun, this causes the extra long invuln timeout bug, which wastes
time while trying to intentionally lower health.
https://www.youtube.com/watch?v=WD2MLj8ccfg
As far as I can tell, any other code interacting with `attack-time` also
uses `(current-time)` or one of the wrapping macros like `set-time!` or
`time-elapsed?`
Very similar to https://github.com/open-goal/jak-project/pull/4068, but
adjusts the scale based on the process clock. I think this approach is a
little bit better since it shouldn't depend on frame timing at all.
There were a few things going on here.
Jak 2's menu wheel is zoomed in at 16:9 but zoomed out at 4:3. However,
the custom aspects use the scaling from the 4:3 mode, this makes sense
as you'd want the zoomed out wheel.
However I noticed HUD elements scaled correctly on PS2 16:9 but not PC
16:9, which was a hint.
The hardcoded values for every individual HUD element for 16:9 and 4:3
are in pixels, normalized across 480 being the stretch of the screen.
To fix the HUD alignment I scaled those offsets, scaling them inside
`set-hud-piece-position` meant both textures and merc models got scaled
at the same time.
Note that you can get (very tiny) snapping into different integer values
as you scale to different aspects. This is simply the result of scaling
integer offsets which is what the game uses.
<img width="1704" height="639" alt="2"
src="https://github.com/user-attachments/assets/81e75f7c-04ba-4c9a-8a50-215d13bd4089"
/>
There are two issues here:
1 is the "punch in" where the logo punches inwards towards the camera on
first appearance, this effect reveals the edges of village1
significantly and happens for all users even on regular 16:9.
2 is on aspect ratios wider than 16:9, you see even larger areas of
village1 on either side.
The blackout is an artgroup that breaks apart and is set to the shape of
the Jak 1 logo. It has a baked in animation and is a set size, so it
cannot simply be scaled or adjusted to be wider.
Seeing the sides of village1 before seeing the logo is not the immersive
experience this opening was going for, where the game "bursts" into the
screen.
My first thought to fix was to simply call `set-letterbox-frames` until
the right moment. This worked, however, it didn't produce an ideal
result simply because the letterbox also went on top of the light blue
"logo volumes" starburst.
Having experimented with the range of edits possible here, I decided the
best approach is actually to simply delay displaying village1 ever so
slightly. This avoids editing the very particular blackout art group,
with set sizes of chunks that break apart. This also avoids covering the
blue volumes with a side letterbox/covering.
This scales with any aspect, supports both different language logo
blackout shapes, and fixes both wide aspect issues as well as the
regular 16:9 punch in issue. This is an important edit as it's the first
thing people see.
<video controls
src="https://github.com/user-attachments/assets/9e5bfd39-4189-4c7c-bf76-e7ea0df0464f"></video>
---------
Co-authored-by: Hat Kid <[email protected]>
Have done some custom ripples so thought I could fix this. At first I
scaled ripple speeds before realizing that wouldn't work if you change
FPS mid-game.
Instead I found the delta increment is there as a variable, and just
scaled that increment directly. I followed the same convention used
everywhere; just multiply by `DISPLAY_FPS_RATIO`.
That was the easy bit, the hard part was a second, unrelated issue,
whether you scale the delta or not, which is on level entry at high fps,
it shows no water movement at all.
I saw the delta was always being created at 0.0 on high FPS, and saw the
delta was computed nowhere in GOAL, only mips2c. I found inspiration
from [this
patch](https://github.com/open-goal/jak-project/blob/5ac5b6aae8f8058e76a27cd14d37db6c0b4d5821/goal_src/jak1/engine/common-obs/ropebridge.gc#L605-L611),
where the time ratio is changed to 60 FPS temporarily. However, fixing
the time ratio still created 0.0 deltas, and no matter what I did, it
always created 0.0 deltas.
I was about to give up, thinking there's no way to scale the mips2c
deltas. However, I found out why it was giving 0.0 deltas, which is on
high FPS, the video-mode is neither `pal` or `ntsc`, but `custom`, and
the misps2c code uses settings for `pal` or `ntsc`.
To include support for high FPS, I temporarily change it to `ntsc`, and
only apply this at the wave table creation when `custom`.
Rename `Language` to `Audio Language` in the menu, and connect it to
`audio-language` instead of `language`.
After this change, we have:
<img width="559" height="322" alt="image"
src="https://github.com/user-attachments/assets/d928a91b-6184-4bde-b147-aa08f22b02d2"
/>
where
- Subtitle Language controls `subtitle-language` on both PC settings and
the normal setting control (unchanged)
- Audio Language controls `audio-language` on setting-control
- Text Language controls `text-language` on PC settings and `language`
on setting control. The game looks at `(-> *setting-control*
user-default language)` to determine text scaling sometimes, so I think
it's good for this to set both.
### The Problem:
The tpages list at the top of the JSONC, never actually gets used or is
written into memory:
<img width="270" height="195" alt="1"
src="https://github.com/user-attachments/assets/d3983363-23db-496e-bcea-136ab0e04058"
/>
This means that previously, the only way that texture remapping was
working was in very specific circumstances, which is when the autofill
would trigger. The autofill would only trigger under these specific
conditions:
- Both a sky remap and level remap are used
- The sky remap and level remap are the same level
- The tpages list is empty
If you went against any of these three parameters, texture remapping
could not be done.
### The Solution:
I simply reversed the logging line
[here](https://github.com/open-goal/jak-project/blob/0fa93ce7b83d1621f3fd040625bfa865eadaeef0/goalc/build_level/jak1/build_level.cpp#L240),
which turns the tpages into numbers in order to print them, and reversed
the shift from << to >> to instead take the numbers and write them into
memory.
```cpp
if (!tpages.empty()) {
file.texture_ids.resize(tpages.size());
for (size_t i = 0; i < tpages.size(); ++i) {
file.texture_ids[i] = tpages[i] << 20;
}
}
```
Pictured: A sunken level remap (correct generic textures on water) with
a village1 sky (so not depending on the autofill that only runs when the
sky and level are matching):
<img width="1716" height="1012" alt="aaa"
src="https://github.com/user-attachments/assets/1af3eddb-a5fb-4387-b644-bf84ba60ab62"
/>
Resolves#3698
This is a known issue confirmed by HatKid after the release of the build
actor tool as something that came up during testing.
There is a problem which is you can't go over 255 vertices or faces in a
single collision primitive. The solution then is to split a single
object into two different primitives. This is what's done in the real
game.
The problem here is that the build actor tool also doesn't support
splitting an object into multiple objects in Blender. If you do, any
subsequent objects appear invisible. This is because the pipeline for
building materials is single-object. If you have a material on multiple
objects in Blender, only one gets built and any subsequent uses get
skipped as they were presumed to have already been built.
This simple fix adds an additional check to check both materials AND
objects when building materials.
This is a pretty important fix, as there's no way to get around the 255
hex limit, so at that point you have no choice but to separate objects
into two separate Blender objects. At this point, it doesn't make sense
to not be able to display the same material on multiple Blender objects.
This affects BOTH collision meshes as well as visual meshes.
This is also a particular issue for non-armature actors.
[Here](https://discord.com/channels/967812267351605298/989587365884485732/1310328952069296290)
is an example of others stumbling across this problem. The solution
found was to make sure all objects were in a single object.
Before this PR:
<video controls
src="https://github.com/user-attachments/assets/fabcd951-d855-4d52-8ed0-0aeea0b75414"></video>
After this PR:
<video controls
src="https://github.com/user-attachments/assets/3e3b7d53-e4ed-43bb-aef1-08cc147d44c0"></video>
After verifying so many things about the BVH trees being correct, I
noticed a pattern across missing collision: all missing collision was
always a face-containing child that was inside a node alongside another
non-face-containing parent.
This minimalist fix simply adds a wrapper so that when a face-containing
child exists alongside a non-face-containing parent, ie. `if (has_leaves
&& has_not_leaves)`, then it simply wraps the face-containing node in
another parent, so that face-containing spheres and non-face-containing
parents don't co-exist in the same node.
The result: restored collision for missing sections in custom levels.
I realized this `temple-defend-door-4` was getting triggered twice, once
during the temple skip % warp, then again when entering palace ruins %
warp (because it's un-closed by a restart mission, since the overall
`temple-defend` task isn't closed). `temple-defend-introduction` remains
closed after the restart mission, so works better here.
Fix Generic2 bug where a tricky way to disable z-buffer writing wasn't
being detected. This should fix some lightning or other effects:
<img width="968" height="982" alt="image"
src="https://github.com/user-attachments/assets/cf3225c1-9ea4-45ed-86e3-2ad3b9a6b1ee"
/>
Also fixed an original game issue(?) where a hud box could be used
uninitialized . Sometimes this would end up drawing a really large box
area which would overflow the DMA buffer and cause confusing crashes.
Adds some additional autosplit points that I think will be useful.
Also tweaks the `errol-dead?` condition to update immediately on the
final hit (there's a sec or so of animation before it returns to
`initial-state`, where it was being updated previously)
Corresponding autosplitter updates:
https://github.com/open-goal/speedrunning/pull/27
Listened with RIG 500 headphones:
The farmer:
<img width="1920" height="1080" alt="1"
src="https://github.com/user-attachments/assets/0f399461-653e-412a-8e33-6a33e7f59277"
/>
I really could not hear that "spitting", percussive sound of the "p" for
"pack". I think it's unlikely the line is "pack" or "packed into the
pen".
The strong, healthy bass of "b" is more likely. Furthermore, he points
visually over his shoulder in the same moment, physically referring to
his own "back" as if referencing the past or a previous state.
The geologist:
<img width="1920" height="1080" alt="2"
src="https://github.com/user-attachments/assets/7ff7f4c3-2ded-41c1-84c7-1f6b44c5b081"
/>
"Lighting" to "lightning" would match consistency to the other
references to lightning moles. Listening to the sound, you can hear the
distinctly "nasally" sound of the "n" connecting the "light" and "ing".
This fixes the metal head tower resolution cutscene having an awkward
amount of blackout at the start unless the framerate dipped to at least
(most?) 33FPS, since its frame num starts in the negative. There may be
other cutscenes that start at negative or higher than zero, but I don't
know of any (did not check thoroughly as that's boring as hell).
I don't really understand what the purpose of this check is in the first
place to be honest.
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
The dust storm will now always behave as if it was at 60 FPS. Particles
only spawn every 1/60th of a second and the push vector is converted as
if it was originally equivalent to 1/60th of a second.
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.
Fix textures on the bomb (just a simple typo fix):
<img width="1638" height="1067" alt="2025-10-05_18-22"
src="https://github.com/user-attachments/assets/d31fedd4-b4f3-4e65-8457-a67068b137be"
/>
Fix issue with ocean culling when in the war factory. In this level, the
make the background rotate by defining a different camera matrix. We
need to use that matrix when culling the ocean, since it rotates too.
This is different on PC because the original game stashed the camera
frustum planes in some vf registers for background drawing.
<img width="1638" height="671" alt="image"
src="https://github.com/user-attachments/assets/feb5f931-e71f-411e-8a29-e8d970f70078"
/>
Fixes#4023
This fixes a duplicated entry in the Jak 2 keybind details page where
"Right Analog Stick Left" appears twice.
File: goal_src/jak2/pc/progress/progress-static-pc.gc
Change: corrected the :entries list to include r-analog-right once
and removed the duplicate r-analog-left, resulting in the 8 expected
analog directions (L and R sticks).
Repro: Options → Input → Reassign Binds → Keyboard (Jak 2)
Before: Right stick shows duplicate "Left"
After: Right stick shows Left/Right correctly
Bumps
[actions/download-artifact](https://github.com/actions/download-artifact)
from 4 to 5.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/actions/download-artifact/releases">actions/download-artifact's
releases</a>.</em></p>
<blockquote>
<h2>v5.0.0</h2>
<h2>What's Changed</h2>
<ul>
<li>Update README.md by <a
href="https://github.com/nebuk89"><code>@nebuk89</code></a> in <a
href="https://redirect.github.com/actions/download-artifact/pull/407">actions/download-artifact#407</a></li>
<li>BREAKING fix: inconsistent path behavior for single artifact
downloads by ID by <a
href="https://github.com/GrantBirki"><code>@GrantBirki</code></a> in <a
href="https://redirect.github.com/actions/download-artifact/pull/416">actions/download-artifact#416</a></li>
</ul>
<h2>v5.0.0</h2>
<h3>🚨 Breaking Change</h3>
<p>This release fixes an inconsistency in path behavior for single
artifact downloads by ID. <strong>If you're downloading single artifacts
by ID, the output path may change.</strong></p>
<h4>What Changed</h4>
<p>Previously, <strong>single artifact downloads</strong> behaved
differently depending on how you specified the artifact:</p>
<ul>
<li><strong>By name</strong>: <code>name: my-artifact</code> → extracted
to <code>path/</code> (direct)</li>
<li><strong>By ID</strong>: <code>artifact-ids: 12345</code> → extracted
to <code>path/my-artifact/</code> (nested)</li>
</ul>
<p>Now both methods are consistent:</p>
<ul>
<li><strong>By name</strong>: <code>name: my-artifact</code> → extracted
to <code>path/</code> (unchanged)</li>
<li><strong>By ID</strong>: <code>artifact-ids: 12345</code> → extracted
to <code>path/</code> (fixed - now direct)</li>
</ul>
<h4>Migration Guide</h4>
<h5>✅ No Action Needed If:</h5>
<ul>
<li>You download artifacts by <strong>name</strong></li>
<li>You download <strong>multiple</strong> artifacts by ID</li>
<li>You already use <code>merge-multiple: true</code> as a
workaround</li>
</ul>
<h5>⚠️ Action Required If:</h5>
<p>You download <strong>single artifacts by ID</strong> and your
workflows expect the nested directory structure.</p>
<p><strong>Before v5 (nested structure):</strong></p>
<pre lang="yaml"><code>- uses: actions/download-artifact@v4
with:
artifact-ids: 12345
path: dist
# Files were in: dist/my-artifact/
</code></pre>
<blockquote>
<p>Where <code>my-artifact</code> is the name of the artifact you
previously uploaded</p>
</blockquote>
<p><strong>To maintain old behavior (if needed):</strong></p>
<pre lang="yaml"><code></tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/actions/download-artifact/commit/634f93cb2916e3fdff6788551b99b062d0335ce0"><code>634f93c</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/download-artifact/issues/416">#416</a>
from actions/single-artifact-id-download-path</li>
<li><a
href="https://github.com/actions/download-artifact/commit/b19ff4302770b82aa4694b63703b547756dacce6"><code>b19ff43</code></a>
refactor: resolve download path correctly in artifact download tests
(mainly ...</li>
<li><a
href="https://github.com/actions/download-artifact/commit/e262cbee4ab8c473c61c59a81ad8e9dc760e90db"><code>e262cbe</code></a>
bundle dist</li>
<li><a
href="https://github.com/actions/download-artifact/commit/bff23f9308ceb2f06d673043ea6311519be6a87b"><code>bff23f9</code></a>
update docs</li>
<li><a
href="https://github.com/actions/download-artifact/commit/fff8c148a8fdd56aa81fcb019f0b5f6c65700c4d"><code>fff8c14</code></a>
fix download path logic when downloading a single artifact by id</li>
<li><a
href="https://github.com/actions/download-artifact/commit/448e3f862ab3ef47aa50ff917776823c9946035b"><code>448e3f8</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/download-artifact/issues/407">#407</a>
from actions/nebuk89-patch-1</li>
<li><a
href="https://github.com/actions/download-artifact/commit/47225c44b359a5155efdbbbc352041b3e249fb1b"><code>47225c4</code></a>
Update README.md</li>
<li>See full diff in <a
href="https://github.com/actions/download-artifact/compare/v4...v5">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
During the iso creation process it's possible that this file in will be
internally renamed to `WATER_AN.CGO`, despite the external file name
displaying `WATER-AN.CGO`. We expect the file to be named
`WATER-AN.CGO`.
We can't control how our users create their iso files. We can alleviate
future friction regarding this matter by adopting this simple change.
---------
Co-authored-by: Tyler Wilding <[email protected]>
Fixes#3997: The script for the orb that is spawned when getting a medal
in the satellite game was using the wrong entity name.
Fixes#3998: The `spider-manager` process was invalid for one frame,
causing the score to be set to the value of `#f`, winning the game
instantly.
Also doubled the PC port texture count, which should hopefully fix the
crash that happens when playing the game all the way through to the end
of the Destroy Dark Eco Tanks mission in one sitting.
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.
Similar issue to the orbs-per-level counts, while loading a save (in
blackout) these values are reset to 0 briefly. This can cause extra
autosplits (see https://github.com/open-goal/speedrunning/pull/25)
The context for this is that i was symlinking files from a mod
installation that were identical to the unmodded game, for space
considerations, because i remembered having success with that in the
past, before the project made the switch to ghc's filesystem library, it
seems. <sub>(I was also much more pressed for space back then, but well,
i thought writing a small program to check for matches and link them for
me would be a good, not-so-difficult exercise...)</sub>
However i quickly started getting weird errors that it couldn't find
GAME.CGO or KERNEL.CGO even when i hadn't touched them. Initially since
i found that it occurred only when symlinking any files that were
earlier alphabetically, i assumed it was some kind of index mismatch,
but it was actually caused by a bug in an older version of
filesystem.hpp causing the `directory_iterator` to read everything after
a symlink as also a symlink, making them fail to be read properly:
https://github.com/gulrak/filesystem/pull/162
Adding `f.is_symlink()` is not as much of a change to the loop's
condition from the previous behavior as it might first appear. It seems
that even without that condition the iterator *was* reading symlinks
before, just incorrectly (and before ghc::filesystem, they were being
read just fine, iirc). With the new version, though, symlinks do have to
be accounted for explicitly.
Given that the library's major and minor version are both the same, i
don't expect there should be any breaking changes to the API, and i
didn't find any when i was testing but there might need to be more
investigation into that before merging. Also, without the added check
for `f.exists()`, the behavior is exactly the same as if, for some
reason, a fakeiso file the game needs just doesn't exist in the first
place (which has no real reason to happen in a normal installation of
the game): there's a decent chance it will either crash at some point
later during runtime, or something will happen like a level failing to
load causing Jak to trip infinitely. I thought it might be helpful to
have it fail right away in the case that, say, someone moved their
vanilla installation and staled their symlinks, but i'll defer to
maintainers' judgement on that point.
Taking the suggestion from @Calinou
(https://github.com/open-goal/jak-project/pull/3943#issuecomment-3017359144),
this replaces the resolve/render framebuffer -> window framebuffer blit
with an actual drawn tri-strip which covers the entire viewport, which
the PCRTC blackout already does.
It appears we have no guarantee what state the internal window
framebuffer will be in, so drawing an actual primitive and letting the
fragment shader do all the work seems to be the more
compatible/functional solution here.
Thanks for the suggestion!
Some monitors are very specific about their reported refresh rates:
```
[54:37] [debug] [DISPLAY]: Skipping 640x480 as it requires 360.11hz but the monitor is currently set to 360hz
```
The current code truncated the display mode, but would compare against
the reported refresh rate. As per the log, they are obviously not equal.
- Retain the float component and only round it off when sending the
value to GOAL
- Make the comparison more generous, +/- 1.0hz
The main bug this fixes is not being able to use level select when your
language isn't translated. Why? Because they use the result from
`lookup-text!` to determine if a menu item should be drawn or not. No
text found, no menu item.
However this uncovered a long-standing bug in my fallback extension to
this code. If you call this function with a text-id that doesnt even
have an english string, it will recursively keep calling itself until it
crashes. Of course the first few tasks in the game are dummies and have
no valid text-id so this had to be fixed.
Should be fixed for all 3 games.
Compilation with the NO_ASSERT flag set results in errors.
This happens because some the macros are not defined in the else branch
of #ifndef NO_ASSERT.
If long_name is too long, it will result in the level being invisible
but the collide loading, lets detect this and point the user in correct
direction to solve it with a clear error message.
---------
Co-authored-by: Hat Kid <[email protected]>
Fixes#3151 by applying the same fix as #2686 to another Mips2C
function.
Tested by mashing Jak's body into the bad collision walls for 30 minutes
without a single crash.
Fixes a small bug introduced in #3902.
Without this change, whenever you load a save it is treated as if you
started a new game and resets the autosplitter back to 0s.
When building the eye texture, the background is first set to the top
corner of the iris texture.
A long, long time ago, I implemented this by peeking at the data in the
texture itself. This doesn't work if the iris texture is animated since
the texture will only on the GPU.
To fix this, this PR changes the eye renderer to draw a square over the
entire eye texture using iris texture's top corner, avoiding the need
for getting the texture data on the CPU. I don't remember why I didn't
do this in the first place, but this seems better in every way.
Also `input_data` in TexturePool not being initialized, which was
leading to hard-to-debug crashes when it was randomly initialized to a
sometimes invalid but non-null pointer.
Co-authored-by: water111 <[email protected]>
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 🐄)
Two changes that fix some Jak 3 audio bugs.
In some areas, sound effects would seem to cut off randomly. This was
caused by the sound code reusing IDs, but overlord didn't realize. It
would try to kill a sound effect by ID that had already died, and the ID
was reassigned to a new sound. To fix this, I made the handle IDs always
increment. I also tested starting the ID at large numbers and confirmed
that worked.
I also added support for the BRANCH grain. This makes the
`wastelander-shot` and possibly other sound effects work. It doesn't
support all the features, but this is probably enough.
Fun fact: the wastelander shot is supposed to have 7 variations, but you
always get the same one because they set the sound mask wrong.
I added a line you can uncomment if you want to experience the other 6
variations.
---------
Co-authored-by: water111 <[email protected]>
There's a suspicion that MSAA might be what causes the black screen
problem for some users, additionally this can cause perf issues for
people with really bad PCs so this is probably a better default.
Needs testing before merging, i think this is all inclusive though.
This needs a parameter, otherwise it was reading some uninitialized
value. In some cases, the uninitialized value would leave the nav stuff
on, and the marauders would go crazy trying to avoid each other.
This should solve the issue where buttons are held down until you push
them the same time. This would cause the cars in jak 3 to not move until
you pushed square/circle and "released" the brake.
Co-authored-by: water111 <[email protected]>
When the `dp-bipedal`s get blown up by the nuke gun, their bones go to
NaNs on the last frame. The shadow renderer doesn't handle this well and
draws all possible triangles as single tris. This overflows the vif
`unpack` field and triggered an assert when sizes inside the shadow
renderer weren't consistent.
My guess is that this works on the real game either because:
- their shadow renderer draws garbage data, but you can't tell because
the screen is white from the nuke
- no NaN on PS2 means that the shadow renderer behaved differently, not
using all single tris.
As a workaround, if the bones are NaN, the shadow renderer treats them
as 0, meaning there is no shadow drawn.
---------
Co-authored-by: water111 <[email protected]>
Fixes both interval and animation speed. (jak1 previously only had a fix
for the former.)
This should close#3518, and one of the issues of #1499.
The solution is not the cleanest. The results are going to be wrong in
case the FPS doesn't reach the maximum set.
A better solution would be to make `random-time` a float, so that it can
be subtracted by `time-adjust-ratio`, but I don't know if changing a
type for this purpose is allowed here. Tell me if I should do that
instead.
Tested only on jak2.
Co-authored-by: Tyler Wilding <[email protected]>
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 <[email protected]>
Prior to SDL3, borderless windows were kinda a hack, they cleaned all of
that up. The side-effect of that is that the C++ code keeps track of the
current window size (it does this for framebuffer sizing, but also to
set the size of the window).
This is now an issue because SDL is properly firing events when you
change to borderless mode, so our window size gets updated to the size
of the entire monitor. When you switch to windowed mode from borderless,
it now seems like it didn't work (it did, its just still taking up the
entire screen).
This could be better cleaned up if more settings are extracted out of
GOAL and put into C++ so they can be managed and accessed where they
belong. But for now, this is a minimally invasive fix.
Fixes#3917
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.~~
libidn2 which is a potential part of libcurl seemingly slipped into the
latest release (0.2.25) and it was dynamically linked.
This causes issues:
```
dyld[95648]: Library not loaded: /usr/local/opt/libidn2/lib/libidn2.0.dylib
Referenced from: <9DA6EC1D-F99A-3233-8264-AAEA87F07743> /Users/tyler/Downloads/opengoal-macos-arm-v0.2.25/gk
Reason: tried: '/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file), '/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file)
zsh: abort ./g
```
My theory for why is that the underlying image changed (now has this
library) and so the cmake detected that and started building with it.
The simple fix is to just disable it, as we don't need it. If we do
eventually, I can figure out how to ensure it's properly compiled.
For dualsense controllers, when the game exits we explicitly clear any
trigger effects. This was happening after SDL was already terminated, so
the hardware handles were already lost.
From a practical standpoint though, this mostly just cleans up logs.
Fixes#3909
Long standing issue in Jak 2's subtitles, it's actually kinda incredible
that finnish didn't run into this problem. Later in this code it
accesses the subtitle based on the language-id, and finnish is always
out of bounds -- but it never caused a catastrophic issue.
Polish on the otherhand is much more out of bounds and always causes an
access violation / crash.
Jak 2's subtitle code has no fallback (ie. use english if not
translated) for cutscenes, since they are not defined in the base file
like in Jak 1. This means that an untranslated language will render no
subtitles during cutscenes. Translations are welcome!.
Tested a cutscene in:
- english
- italian (base game with subtitles)
- finnish (new language, actually is translated)
- polish (new language, not translated)
Follow-up later on improving the validation of the extractor (that may
require testing with all iso versions), but this is just some simple
safe-guarding code that will improve the error messaging, instead of
just a vague invalid map error.
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
Because merc effects for custom models would always have the
`envmap-usage` flag set, this would also set the `ignore-alpha` flag,
making transparency effects not work. Now the envmap flag is only set
when the effect actually has an envmap.
Used a PR since many things can't be changed using Crowdin, such as
timings.
Same team as the italian Jak 1 translation.
This PR won't include subtitles, which will be included later on in a
separate PR, once things will be worked on.
Still needs to be revised by the team.
---------
Co-authored-by: pex93 <[email protected]>
Co-authored-by: Francesco <[email protected]>
Co-authored-by: Tyler Wilding <[email protected]>
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 <[email protected]>
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 <[email protected]>
Add support for `as-type` macro, and detecting inline font methods. This
works in all three games but I've only updated jak 3's goal_src for now.
Eventually I will go back and work through the others, but I want to get
more decompiler features in first.
---------
Co-authored-by: water111 <[email protected]>
Custom levels for Jak 2/3 now support envmapped TIE geometry. The TIE
extract was also changed to ignore materials that have the specular flag
set, but are missing a roughness texture.
Jak 2/3 now also support the `build-actor` tool.
The `build-custom-level` and `build-actor` macros now have a few new
options:
- Both now have a `force-run` option (`#f` by default) that, when set to
`#t`, will always run level/art group generation even if the output
files are up to date.
- `build-custom-level` has a `gen-fr3` option (`#t` by default) that,
when set to `#f`, will skip generating the FR3 file for the custom level
and only generate the GOAL level file to skip the potentially slow
process of finding and adding art groups and textures. Useful for when
you want to temporarily edit only the GOAL side of the level (such as
entity placement, etc.).
- `build-actor` has a `texture-bucket` option (default 0) which will
determine what DMA sink group the model will be placed in, which is
useful to determine the draw order of the model. Previously, this was
omitted, resulting in shadows not drawing over custom actors because the
actors were put in a bucket that is drawn after shadows (this behavior
can be restored with `:texture-bucket #f`).
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 <[email protected]>
There's a feature to draw levels with a different camera matrix. This
uses `camera-temp-other`, `camera-rot-other`, etc instead of
`camera-temp`, `camera-rot`... I assumed that `trans-other` was the
"other" version of `trans`, but it turns out this isn't true -
`trans-other` is combined with `quat-other` and the original camera
matrix.
This fixes the issue by using the translation part of
`inv-camera-rot-other` for othercam levels only. (it works in all cases,
but I didn't want to use it for normal levels since I think it will be
less accurate)
Co-authored-by: water111 <[email protected]>
Migrates all code, there should be no change in the compilation output
(linter should check this)
At first i was considering making these builtins, which short of a bunch
of code generation, would require some sort of dynamic definition in
`Atoms.cpp`. This isn't hard but, i figured it would be better to keep
it simple and just generate the OG macros.
Fixes https://github.com/open-goal/jak-project/issues/233
Kind of silly fix.
The cloth update function sometimes runs before the "setup" is done
(`need-setup` is set), which divides by zero in a bunch of places. This
fix prevents NaNs from spreading during this time.
Co-authored-by: water111 <[email protected]>
This should fix the crash when entering the freedom HQ elevator. It was
caused by a large number of prints, one for each process in the city
being killed by `check-for-rougue-process`, which would overflow the
print buffer. So I increased the print buffer.
Detecting buffer overflow here is hard because lots of things are
allowed to write to it, including the user's GOAL print methods. I added
a basic check that will assert when there's 1k or less space in the
buffer. It won't catch every overflow, but it would have caught this
one.
Co-authored-by: water111 <[email protected]>
I finally went through and worked out the math for the camera matrix,
and improved how it works for PC rendering. I was able to finally avoid
the double perspective divide issue, which I always thought would cause
accuracy issues.
This will help tfrag, tie (no envmap), shrub, and hfrag have less
z-fighting in cases where the camera and the thing you're looking at are
pretty close, but the entire level is far from the origin - like jak 3
temple. I was able to modify the camera matrix so we don't have to do
all the weird scaling/addition in the shader.
Here's a screenshot from the temple oracle checkpoint, cropped from 4k.
This used to have a lot of fighting issues.
It doesn't help issues where the thing you're looking at is very far
away (jak 1 mountains, some jak 2 city stuff). It also doesn't help with
jak's skirt/scarf, since those use a different renderer.
There's definitely more to do here, but this is a good starting point
and proof that I can at least figure out the math.
Co-authored-by: water111 <[email protected]>
In Jak 3, the default PC settings file would have a language of 255
because it runs before the first settings update. This would cause the
game to crash the second time it is started.
I also added this simple imgui window to see the names of streams in the
"SPU" memory, which has been useful for debugging
---------
Co-authored-by: water111 <[email protected]>
Accidentally incrementing `s` twice in the loop, so queued streams in
slot 1, and 3 were skipped by the overlord.
This would usually cause the audio to never start playing because the
game would wait for the audio to successfully get queued.
Co-authored-by: water111 <[email protected]>
Change jak 3 SPU DMA to run the interrupt handler "immediately" (or at
least before `DMA_SendToSPUAndSync` returns).
This fixes an issue where audio can hang during fast cutscene playback.
I'm hoping it fixes more issues with looping/stuck audio as well, but
this needs more testing.
I originally wanted to do it this way, but thought that it didn't work -
from Jak 2 it seemed like things broke if the DMA was too fast. But, at
least for Jak 3, everything seems to work like this. This will remove a
huge source of non-deterministic timing in audio stuff and hopefully
make things easier to debug. It also means that a large portion of
streaming audio code will never have to run - from the game's point of
view there's always the next SPU buffer available.
If this works well, I might revisit jak 2 as well.
Co-authored-by: water111 <[email protected]>
Fix a missing scale factor when using the large mode in the animation
compressor. This would make some joints have a translation of near 0 if
the original animation had stuff moving a large distance
Co-authored-by: water111 <[email protected]>
Two new flags were added to the Blender plugin to allow reusing the mod
and/or eye draws of the original model that is being replaced. Works
pretty well for eyes, but the blerc draws can cause some Z-fighting with
the non-moving parts of the model.
Also a small refactor to the merc replacement code to de-duplicate some
code by moving stuff to `gltf_util.cpp`.
A few improvements to color palette selection. These were made by
tracing some particularly bad colors through and seeing where it made
obviously bad decisions for splitting. I tested on crystal cave, and a
test GLBs from Kuitar that previously had issues with alpha.
- The previous approach to splitting was based on trying to keep a tree
of deduplicated colors balanced (same count in each leaf). This is not
really a good idea for generating color palettes. A better approach is
to try to minimize the volume of the child node, limiting how inaccurate
a color can be. Splitting is now chosen based on the average of the
_deduplicated channel values_, which in practice seems to work pretty
well for Kuitar's levels. Other approaches could work here too.
- The previous approach of alternating through dimensions to split on
was kept.
- The depth of the KD tree during the initial split was increased,
allowing it to use up to 8192 colors, instead of just 1024.
- In most cases, not all child nodes of the tree have colors in them,
meaning that a tree of depth 13 would have less than 8192 colors. If
this happens, child nodes are split until the color count reaches 8192.
The selection of which nodes to split is somewhat arbitrary, but is
breadth-first. The axis for splitting is the one with the largest range.
(which might be a better idea in general?)
On crystal-cave, the worst case color error was reduced from 221 to 9.
---------
Co-authored-by: water111 <[email protected]>
Fixes the issue with animations doing a full 180 degree rotation and
disappearing. The quaternions in the GLB export "flip", and when
interpolating animation frames in between a flip, we got bogus
quaternions.
Fixes https://github.com/open-goal/jak-project/issues/3786
Also fix a crash in `goalc` when using merc models without any
materials.
Co-authored-by: water111 <[email protected]>
After collecting 600 orbs, cloth systems that didn't have any
`alt-tex-name`s defined would vanish because the `static-cloth-params`
macro doesn't default them to `#f`.
Store a small database of which models have already been swapped out in
a level to prevent duplicate processing.
Also a small fix for cases where using a model replacement that has no
armature would cause merc nightmares due to only having a `max_bones` of
3.
Folder names were in common with the normal intel x86 build, the release
wasn't going to work. Hopefully with these changes it will but, still
technically untested. Don't have time to do so tonight.
Several users have reported that ArchipelaGOAL is not launching
properly, even when using the OpenGOAL Launcher. The window pops up with
a black screen, and then quits. The only way they can run it is if they
double click gk.exe.
This comes down to the Launcher providing gk.exe with the `config_path`
parameter, which leads the program to find `archipelagoal-settings.gc`.
Here is an example from me:
```
D:\Applications\Games\OpenGOAL\features\jak1\mods\JakMods\_settings\archipelagoal\OpenGOAL\jak1\settings/Mods/archipelagoal-settings.gc
```
If a user's base OpenGOAL install directory is long enough, this path
becomes longer than 128 characters. This overflows the character buffer
in `kopen` which is used to open file streams. If you're only slightly
over the limit like myself, at 135 characters, you may not have noticed
a problem. But some users have paths a little longer, like 168
characters, and they report the issue is consistent.
Water111 suggested we remove the 128 character buffer and use the
filename data directly. This fix requires no changes to the Launcher,
just to the kernel, and every mod could stand to benefit from this fix.
When a material in Blender has its IOR level changed to anything other
than the default value of 0.5, the `KHR_materials_specular` extension is
applied during the glTF export, which is what we use to check for
envmaps in custom models. If an envmap is undesired, but the IOR value
was accidentally changed, the program would assert during model
processing if there is no metallic roughness texture attached to the
material.
Since this is an easy mistake to make and is hard to spot, this adds a
better error message for such cases.
Create explicit x86_64 and ARM64 macOS build targets, so it's clear that
the CI is building x86_64 binaries (on both Intel and ARM64 build
machines). Also, use the `CMAKE_APPLE_SILICON_PROCESSOR` CMake variable
(which sets `CMAKE_SYSTEM_PROCESSOR`) so `BUILD_X86_ON_MACOS` is not
necessary.
And update the README.
Simple workaround to put an effect in a different bucket. I don't think
there's a difference in the result, but this is just easier to handle on
the PC renderer side.
Co-authored-by: water111 <[email protected]>
Base implementation of the popup menu and speedrunner mode in Jak 3.
Autosplitter is untested because I'm on Linux.
Also a couple of other misc changes:
- Model replacements can now have custom bone weights. Needs the "Use
Custom Bone Weights" property (provided by the OpenGOAL Blender plugin)
enabled in Blender.
- Better error message for lump syntax errors in custom level JSON
files.
Fix compiler warnings, and a bug where the `snd_handle` of
`SoundBankInfo` was never set, leading to sound banks never unloading.
The game relies on unloading soundbanks to make sure certain sounds
don't play, like the blue gun 1 fire noise when using blue gun 2.
---------
Co-authored-by: water111 <[email protected]>
The fundamental issue is related to hiDPI / Retina displays, I don't
think our rendering code is setup properly to handle the scaling between
the two (which you can derive by comparing `SDL_GetWindowSize` and
`SDL_GL_GetDrawableSize`).
So rather than opening that can of worms, I just removed the window
flag.
Also fixed an unrelated issue for displaying resolution options when in
windowed mode, it was previously only adding options to the list if they
were invalid for full-screen.
Fixes#3099
if you sideflip into grind in the digsite mission, the clasps wont break
because it is considered a `board-spin` attack instead of `board`. This
extends the condition to allow for `board-spin` as well.
~~Should I wrap this in an `#if PC_PORT`?~~ done
DMA sizes are 16-bits, not 12-bits. This would cause rare crashes when
the ocean far renderer uses more than this.
I'm not really sure what the ocean far rendering is doing at this time,
but it happens as stuff is loading in.
There's a chance this fixes crashes in jak 2 as well, since we used to
see errors that would be explained by this.
Co-authored-by: water111 <[email protected]>
Fixes https://github.com/open-goal/jak-project/issues/3753 hopefully
Rapidjson is never cutting a release, ever, and even if they did, the
discord-rpc library is deprecated so it would never consume it.
Instead of updating 8 years worth of changes and praying that works, I
just made the alleged fix from 8 years ago and changed discord-rpc's
cmake to not pull from the release.
Fixes a regression in #3722.
```
[18:34] [error] Failed to compile vertex shader sprite3_3d:
ERROR: 0:122: '&' does not operate on 'unsigned int' and 'int'
ERROR: 0:129: Use of undeclared identifier 'xy0_vf19'
ERROR: 0:129: Use of undeclared identifier 'xy0_vf19'
ERROR: 0:144: '&' does not operate on 'unsigned int' and 'int'
ERROR: 0:151: Use of undeclared identifier 'xy0_vf19'
ERROR: 0:151: Use of undeclared identifier 'xy0_vf19'
```
It looks like one of the tie models in this level has bad color data in
the lowest LOD. For now, just skip extracting the lowest lod for this
TIE only.
Co-authored-by: water111 <[email protected]>
Since #3735, loading consite in Jak 2 crashes due to an assert in the
code that handles the PC clut blender DMA. The unused and
half-implemented `kor-transform` texture animation doesn't have any
blenders as the texture names are commented out in the C++ definition
(and it seems that these textures are defined multiple times within
different tpages in the same DGO, leading to errors during startup if
uncommented), leading to a mismatch between the actual qwc in GOAL and
the assumed DMA data size in C++.
By adding the `draco` library as a dependency, `tinygltf` can support
GLB files compressed with the Draco compression algorithm which allows
for drastically reduced file sizes for custom levels (TFL's Crescent Top
GLB for example went from 135 MB to 37 MB).
- Bug fix to KD tree splitting, should fix cases with bad vertex
colors/alphas.
- Normalize normals instead of asserting if they are the wrong length.
**the fact that blender exports normals incorrectly is a bug and I doubt
their implementation is correct if you've scaled things on only on
axis.**
- Automatically resize metallic texture (envmap strength) if it doesn't
match the size of the rgb texture instead of asserting
Co-authored-by: water111 <[email protected]>
This is so I can get rid of wgpu from the launcher, where it's only
purpose is to figure out the GPU name for the support package.
The problem with it is that on some environments, it errors, but the
function cannot have it's errors gracefully handled (it panics and
crashes instead).
So I'm tired of it, do it ourselves.
Fixes issue with not handling texture flipping flags in sprite renderer
(new jak 3 feature). As far as I can tell, there is no visible
difference because the textures that use this flag are symmetric.
Fix issue with not adding an `and` with `0xf` on the offset into the xy
table. This is added only in jak 3, where `vi07`'s upper bits are
sometimes nonzero, but doesn't hurt to have in all three games.
```
iaddi vi09, vi00, 0xf | nop
iand vi07, vi07, vi09 | nop
```
Fix issue with inf/nan causing the tentacle to not appear:
---------
Co-authored-by: water111 <[email protected]>
I hope this is everything I needed, and nothing I didn't.
## What's Changed
This update adds a command-line parameter to goalc, `--iso-path`.
Providing a path to a directory like
`D:\Files\Repositories\ArchipelaGOAL\iso_data\jak1` will inform the
compiler to use that directory instead.
## Why is this useful?
When combined with `--proj-path`, the compiler can be pointed to a
completely different project folder, given the `(mi)` command, and
immediately begin building from that directory, with everything it
needs. This eliminates the need to copy `iso_data` to multiple `data`
directories.
If a subsequent change to the Launcher is made, each mod could be passed
an --iso-path pointing to a single shared folder, allowing mods to each
run their own REPL _without_ requiring a copy of `iso_data` in a
subfolder.
## Independent testing required!
My local repositories are a little suspect, with a mod, a fork of
mod-base, and a fork of jak-project, all on the same drive. My
decompiler_out and iso_data folders are in the mod repo, not mod-base
nor jak-project. So what I did was make the change in the mod-base fork,
point `--proj-path and --iso-path` to the mod folders, and then ran
`(mi)`. The output showed a build starting with no errors.
Then I had to create this PR, which my fork of mod-base is unable to do,
so I created a patch file, forked jak-project, then applied the patch
there.
All this is to say that it would be preferable if someone could apply
this code to their own installation and see if it works. Even I wouldn't
take my own word for this.
---------
Co-authored-by: Tyler Wilding <[email protected]>
Fix https://github.com/open-goal/jak-project/issues/3701, and possibly
other issues where projectiles were invisible/messed up. The use of
`align16` with the -16 was subtracting 16 in cases when the pointer was
already aligned, causing a bad value to be loaded for the quaternion.
I also renamed some variables and did some manual cleanup on a method in
process-drawable, since this one comes up a lot during debugging.
Co-authored-by: water111 <[email protected]>
Fixes#3644 which I believe is the same underlying issue as "NG+ glitch"
To reproduce the issue in #3644 you can:
- choose Hub 2 100% in the speedrun fast reset menu
- hit the blue sage warp gate switch
- go deep enough into any adjacent level (e.g. basin) where `village2`
display is turned off
- reset speedrun in the fast reset menu
- tasks are reset but the switch will be pressed, giving the cutscene
early
You can also grab orbs/scout flies in `village2`, and they won't be
reset properly because of this same bug.
It happens because of the way entity perm status is managed across both
`level` vs `game-info` objects.
- when `village2` is deactivated (still loaded but display hidden), its
entity perms are copied to `game-info`'s `perm-list`
- this is how we persist `warp-gate-switch-7` being pressed if village2
is ever unloaded
- during the speedrun reset `reset-actors` is called:
- any active levels (loaded+displayed) have their entity perm statuses
reset
- because `village2` is not displayed yet, its entity perm statuses are
not touched
- `game-info` is re-initialized, clearing out its `perm-list`
- continue is set to `firecanyon-end`
- this unloads `rolling` or whatever to make room for `firecanyon`
- `village2` is already loaded, and just gets displayed
- at this point the game does copy entity perm status from `game-info`
back to the `village2` level
- but we reset the game, so it has no data about the warp-gate-switch,
leaving it pressed!
This adds some new JSON entries to custom levels so they can support
vanilla sky textures and the texture remapping tables, allowing for
proper textures on objects that use `generic`, like dark eco pools or
dying enemies.
The comments explain it in more detail, but the gist is:
For skies:
- `sky` needs to be a vanilla level that has sky textures.
- The alpha tpage (fourth entry in `tpages`) needs to be that vanilla
level's alpha tpage (if `tex_remap` is the same level as `sky`, this
will be handled automatically).
- The tpage needs to be added to the custom level `.gd` and to
`textures` in the JSON.
- In `level-info.gc`, `sky` needs to be `#t`, your level's mood needs to
call `update-mood-sky-texture` (the default mood, `update-mood-default`,
handles this as an example) and `sun-fade` needs to be nonzero for the
sun to show up.
For `generic` textures:
- `tex_remap` needs to be the name of a vanilla level.
- When using a vanilla level's remap table, you need to adhere to the
order of the files in that level's `.gd` in your own level.
- Code files are first.
- Then the tpages (in the order `tfrag`, `pris`, `shrub`, `alpha`,
`water`).
- Then the art groups.
- Lastly, the level file.
- The tpages need to be added to the `textures` in the JSON.
- Fix global heap display in cheat mode
- Fix `tpl-watcher` NaNs after they fire their laser (`vf0` was being
clobbered) (Fixes#3684)
- Fix `artifact-race` talkers (Fixes#3685)
This is basically applying the same fix as `vector<-cspace!`, which
we've been doing since jak 1.
They often make bugs where they use bones before they are properly
initialized. On PS2, it's relatively harmless - it results in stuff
going to the origin for 1 frame (where it collides with nothing, since
the collide cache was filled somewhere else), then going back to normal.
On PC, using these uninitialized bones results in NaNs. This is because
`0 * (1 / w)` where `w = 0` done in the `update-transforms` is `NaN` on
PC, but 0 on PS2. These NaNs propagate to the velocity, and you get
stuck with everything being NaN.
Co-authored-by: water111 <[email protected]>
This only applies to the background for now:
- support for alpha for vertex colors in custom levels
- switch time of day palette generation from octree to k-d tree
- support for alpha masking in custom levels
- support for transparent textures
- support for envmap in custom levels
---------
Co-authored-by: water111 <[email protected]>
Similar to the workaround added in jak 3, if too many sounds are
playing, a sound will be removed. If there are multiple instances of the
same sound being played, those will be removed first. Within that, older
sounds are removed first.
It's not exactly the same as the instance limits of 989snd, but it seems
to work well. It's at least better than what we had before.
Co-authored-by: water111 <[email protected]>
`bigmap` and `blit-displays` mostly work. `blit-displays` is still
missing all of the special effects that were added in Jak 3 (brightness
and contrast settings, screen blur effect, etc.).
`bigmap` is missing the player marker texture (`hud-target-marker`) for
some reason, it's part of `tpage-17` which is coming from
`progress-minimap` and should already be included. The icons also
currently stretch when using aspect ratios other than 4:3.
The progress menu now also works for the most part. The draw order is a
bit messed up because some code was initially drawing things with the
ocean bucket, which was changed to use `hud-draw-hud-alpha` instead for
now. The texture for the volume and brightness/contrast sliders still
looks wrong.
Fixes#3653Fixes#3656
A small change that makes the models look a lot better.
Will likely cause a crash if imported model has no normal data, but
that's on the user to fix on their model.
Found out the hard way that the `abutton` array for pressure sensitivity
uses a different order than the `pad-buttons` enum, so I created a new
enum for abutton indexing.
I replaced any magic numbers across the codebase where it made sense,
e.g.
`(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number)
abutton 6)`
becomes
`(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number)
abutton (abutton-idx x))`
Goes with https://github.com/open-goal/speedrunning/pull/21
Based on some of the autosplit points from the [comgold
sheet](https://docs.google.com/spreadsheets/d/1ZtceX0ZxCLkufVFQuCgVxptvmVgp6deHwPYWxUPi258/edit?gid=0#gid=0),
plus one after talking to samos to give a clean split for timing the
deload.
```
(tomb-poles-poles uint8) ;; left tomb/daxter boulder start
(fortress-save-friends-introduction uint8) ;; talk to torn (before rescue friends)
(sewer-escort-get-gun uint8) ;; get peacemaker
(forest-protect-introduction uint8) ;; talk to onin (protect samos)
(forest-protect-meeting uint8) ;; talk to samos (protect samos)
```
e.g. instead of just `beach-foreground.glb` and `beach-background.glb`,
you'd now get:
- `beach/babak-lod0.glb`
- `beach/babak-lod1.glb`
- `beach/babak-lod2.glb`
- `beach/barrel-lod0.glb`
- `beach/beach-background.glb`
- `beach/beachcam-lod0.glb`
- ... (42 other files)
- `beach/windmill-one-lod2.glb`
`common` models are also grouped into their own folder
This adds a feature to `build_actor` to support importing skeletons and
animations from .glb files.
Multiple animations are handled and will use the name in the GLB. The
default `viewer` process will end up playing back the first animation.
There are a few limitations:
- You can only have around 100 bones. It is technically possibly to have
slightly more, but certain animations may fail to compress when there
are more than ~100 bones.
- Currently, all animations have 60 keyframes per second. This is a
higher quality than what is normally used. If animation size becomes
problematic, we could make this customizable somehow.
- There is no support for the `align` bone.
---------
Co-authored-by: water111 <[email protected]>
Finnish translations for Jak 2. These include cutscenes and all game
text.
All subtitle timings for cutscenes as well as non-cutscenes have been
edited for a better flow and to fit the 4x3 ratio.
I've been working on these solo for the most part so any input from
other finns would be appreciated.
A few issues in the progress menu I mentioned in #3504 still persist
I couldn't figure out how to add Finnish to the options menu, so I'm
gonna need someone else to do that part. 💀
But I was able to add them to the debug menu.
I also increased subtitle heap so hopefully that doesn't break anything.
Fixes#3620
---------
Co-authored-by: Tyler Wilding <[email protected]>
Also saves out the default `pc-settings.gc` file so it's less confusing
_and_ so we can request it from users to actually see what it's doing.
The fix in the last release was only to fix bad `game-size` values when
_loading_ the file. But if you don't have a file, it picks a default.
Right now it picks that default by:
1. Your largest reported resolution
2. If that fails, the one that is currently set
In reality this scenario can never really happen (if you have a set
resolution, it will be one of the reported ones). However what can
happen is for SDL to be misinformed by bad display/monitor drivers/the
OS and be given "supported" resolutions that aren't actually supported.
For example some users have a 4K resolution as their highest, despite
them using a 1080p monitor.
The solution is to not blindly assume the largest resolution is valid,
instead use the one the user already has set.
I'm also now filtering out resolutions by refresh rate, as perhaps this
also caused a problem. ie. the monitor supports a resolution if the
refresh rate is lowered, but it's currently set high (at 144hz for
example).
description:Take a couple minutes to help our maintainers work faster.
options:
- label:I have [searched](https://github.com/open-goal/jak-project/issues?q=is%3Aissue+is%3Aopen+label%3Abug+label%3Ajak3+sort%3Aupdated-desc+) for duplicate or closed bug reports
required:true
- label:I understand that I am supposed to provide my own legitimately obtained copy of the game
required:true
- type:textarea
attributes:
label:Describe the Bug
description:A clear and concise description of what the bug is. You may post screenshots or videos of the bug here.
validations:
required:true
- type:textarea
attributes:
label:How To Reproduce
description:Steps to reproduce the behavior. You can also post a video of it here.
validations:
required:true
- type:dropdown
attributes:
label:Does this problem occur on original hardware or PCSX2?
description:Some things that may seem like bugs are actually exactly how the original game behaved.
options:
- Yes,it's unique to OpenGOAL
- Didn't check
- Not needed, bug is obvious
validations:
required:true
- type:textarea
attributes:
label:Expected Behavior
description:A clear and concise description of the expected behavior.
placeholder:When I do X, Y should happen.
validations:
required:true
- type:textarea
attributes:
label:Environment Information
description:"You can upload the [Support Package](https://github.com/open-goal/launcher#asking-for-help) provided by the Launcher here, or you can provide the following information: CPU, GPU, OS Version, OpenGOAL Version (found in the window's title bar)"
validations:
required:true
- type:dropdown
attributes:
label:Game Version
options:
- NTSC 1.0 (black label)
- NTSC Greatest Hits version (red label)
- PAL
- KO
validations:
required:true
- type:dropdown
attributes:
label:Have you set the game to something other than `60fps`?
./third-party/run-clang-format/run-clang-format.py -r common decompiler game goalc test tools lsp --color always
./third-party/run-clang-format/run-clang-format.py -r common decompiler game goalc test tools lsp --color always --clang-format-executable $(which clang-format-18)
> Our repositories on GitHub are primarily for development of the project and tracking active issues. Most of the information you will find here pertains to setting up the project for development purposes and is not relevant to the end-user.
> Our repositories on GitHub are for development of the project and tracking active issues. Most of the information you will find here pertains to setting up the project for development purposes and is not relevant to the end-user.
For a setup guide on how to install and play the game there is the following video that you can check out: https://youtu.be/K84UUMnkJc4
@@ -22,45 +22,27 @@ For questions or additional information pertaining to the project, we have a Dis
Additionally, you can find further documentation and answers to **frequently asked questions** on the project's main website: https://opengoal.dev
> [!WARNING]
> **Do not use this decompilation project without providing your own legally purchased copy of the game.** We do not distribute any assets from the game - you must use your own legitimately obtained PS2 copy of the game. We support every retail PAL, NTSC, and NTSC-J build, including Greatest Hits copies.
> **Do not use this decompilation project without the use of your own legally purchased copy of the game.** OpenGOAL does not include any assets from the original games, so you must provide your own legitimately obtained PS2 copy of the game. OpenGOAL supports every retail PAL, NTSC, and NTSC-J build, including Greatest Hits copies. Please note that does NOT include any of the later releases (PS3/PS4/PS5).
- [Project Description](#project-description)
- [Current Status](#current-status)
- [Methodology](#methodology)
- [Setting up a Development Environment](#setting-up-a-development-environment)
- [Docker](#docker)
- [Linux](#linux)
- [Ubuntu (20.04)](#ubuntu-2004)
- [Arch](#arch)
- [Fedora](#fedora)
- [Windows](#windows)
- [Required Software](#required-software)
- [Using Visual Studio](#using-visual-studio)
- [MacOS](#macos)
- [Intel Based](#intel-based)
- [Apple Silicon](#apple-silicon)
- [VSCode](#vscode)
- [Building and Debugging](#building-and-debugging)
- [OS Setup](#os-setup)
- [Editor Setup](#editor-setup)
- [Building and Running the Game](#building-and-running-the-game)
- [Extract Assets](#extract-assets)
- [Build the Game](#build-the-game)
- [Build the Game (Running the Compiler)](#build-the-game-running-the-compiler)
- [Run the Game](#run-the-game)
- [Connecting the REPL to the Game](#connecting-the-repl-to-the-game)
- [Running the Game Without Auto-Booting](#running-the-game-without-auto-booting)
- [Interacting with the Game](#interacting-with-the-game)
- [Running the decompiler](#running-the-decompiler)
- [`goal_src/`](#goal_src)
- [`game` runtime](#game-runtime)
## Project Description
This project is to port the original Jak and Daxter and Jak II to PC. Over 98% of the games are written in GOAL, a custom Lisp language developed by Naughty Dog. Our strategy is:
The project's goal is to port the original trilogy (Jak 1 -> Jak 3) to PC. Over 98% of the games were written in GOAL, a custom LISP language developed by Naughty Dog. Our strategy is:
- decompile the original game code into human-readable GOAL code
- develop our own compiler for GOAL and recompile game code for x86-64
- develop our own compiler for GOAL and recompile the game code for x86-64
- create a tool to extract game assets into formats that can be easily viewed or modified
- create tools to repack game assets into a format that our port uses.
@@ -70,217 +52,50 @@ Our objectives are:
- try to match things from the original game and development as possible. For example, the original GOAL compiler supported live modification of code while the game is running, so we do the same, even though it's not required for just porting the game.
- support modifications. It should be possible to make edits to the code without everything else breaking.
We support both Linux and Windows on x86-64.
> We do not support, or plan to support the ARM architecture. This means that this will not run on devices such as an M1 Mac or a mobile device.
At the moment we support **x86_64** on Windows, Linux and macOS (via Rosetta translation). There are no plans to ever make a mobile release.
### Current Status
Jak 1 is largely playable from start to finish with a handful of bugs that are continually being ironed out. Jak 2 is in development.
-Jak 1 has been considered in a polished, complete state for years at this point.
- Jak 2 is considered in beta due to a few issues we are aware of that need fixing, however to the casual user, the game is essentially complete.
- Jak 3 has a good amount of work left to do.
YouTube playlist:
YouTube playlist showcasing some of the early progress for Jak 1:
To help with decompiling, we've built a decompiler that can process GOAL code and unpack game assets. We manually specify function types and locations where we believe the original code had type casts (or where they feel appropriate) until the decompiler succeeds, then we clean up the output of the decompiled code by adding comments and adjusting formatting, then save it in `goal_src`.
To assist with decompiling, we've built a decompiler that can process GOAL code and unpack game assets. We manually specify function types and locations where we believe the original code had type casts (or where they feel appropriate) until the decompilation succeeds, then we clean up the output of the decompiled code by adding comments and adjusting formatting, then save it in `goal_src/`.
Our decompiler is designed specifically for processing the output of the original GOAL compiler. As a result, when given correct casts, it often produces code that can be directly fed into a compiler and works perfectly. This is continually tested as part of our unit tests.
## Setting up a Development Environment
The remainder of this README is catered towards people interested in building the project from source, typically with the intention on contributing as a developer.
The remainder of this README is aimed at people interested in building the project from source, typically with the intention of contributing as a developer.
If this does not sound like you and you just want to play the game, refer to the above section [Quick Start](#quick-start)
### Docker
### OS Setup
All three Linux systems are supported using Docker.
- [Windows](/docs/setup/system/windows.md)
- [Linux](/docs/setup/system/linux.md)
- [MacOS](/docs/setup/system/macos.md)
- [Docker](/docs/setup/system/docker.md)
Pick your supported prefered flavour of linux and build your chosen image
### Editor Setup
```
docker build -f docker/(Arch|Fedora|Ubuntu)/Dockerfile -t jak .
```
You can of course use whatever editor you want, but here is some documentation that should help you get started on some of the editor's we have used and have written about:
This will create an image with all required dependencies and already built.
```
docker run -v "$(pwd)"/build:/home/jak/jak-project/build -it jak bash
```
Note: If you change the content of the `build/` directory you'll need to rerun the `build` command. Alternatively you can get the build via `docker cp`.
This will link your `build/` folder to the images so can validate your build or test it on an external device.
Docker images can be linked into your IDE (e.g. CLion) to help with codesniffing, static analysis, run tests and continuous build.
Unfortunately you'll still need task runner on your local machine to run the game or instead, manually run the game via the commands found in `Taskfile.yml`.
sudo sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin
```
Compile:
```sh
cmake -B build && cmake --build build -j 8
```
Run tests:
```sh
./test.sh
```
Note: we have found that `clang` and `lld` are significantly faster to compile and link than `gcc`, generate faster code, and have better warning messages. To install these:
```sh
sudo apt install lld clang
```
and run `cmake` (in a fresh build directory) with:
We primarily use Visual Studio on Windows for C++ development. Download the latest community edition from [here](https://visualstudio.microsoft.com/vs/). At the time of writing this is Visual Studio 2022.
You will require the `Desktop development with C++` workload. This can be selected during the installation, or after via the `Visual Studio Installer`, modifying the Visual Studio Installation.
On Windows, it's recommended to use a package manager, we use Scoop. Follow the steps on the bottom of the homepage [here](https://scoop.sh/) to get it.
Once Scoop is installed, run the following commands:
```sh
scoop install git llvm nasm python task
```
#### Using Visual Studio
Clone the repository by running the following command in your folder of choice.
This will create a `jak-project` folder, open the project as a CMake project via Visual Studio.
Then build the entire project as `Windows Release (clang)`. You can also press Ctrl+Shift+B as a hotkey for Build All. We currently prefer `clang` on Windows as opposed to `msvc`, though it should work as well!
### MacOS
> NOTE: At this time you can only run the game on macOS if you have an Intel processor.
Ensure that you have Xcode command line tools installed (this installs things like Apple Clang). If you don't, you can run the following command:
If you either don't want to or cannot use Visual Studio for working with the C++ project, VSCode is a good alternatively.
The `clangd` extension is [recommended](https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd) and requires `clangd` to be on your `$PATH`. If you can run `clangd` in a terminal successfully then you should be good to go.
Once you generate your CMake for the first time the clangd LSP should be able to index the project and give you intellisense.
#### Building and Debugging
TODO - Consider Contributing Documentation :)
- [Visual Studio (Windows)](/docs/setup/dev/vs.md)
- [Visual Studio Code](/docs/setup/dev/vscode.md)
- [Zed](/docs/setup/dev/zed.md)
### Building and Running the Game
Getting a running game involves 4 steps:
Getting a running game involves 4 main steps:
1. Build C++ tools (follow Getting Started steps above for your platform)
2. Extract assets from the game
@@ -289,25 +104,16 @@ Getting a running game involves 4 steps:
#### Extract Assets
First, setup your settings so the following scripts know which game you are using, and which version. For the black label version of the game, run the following in a terminal:
First, we have to setup our environment so we know which game and version we are operating with. For the black label version of Jak 1 we would run the following:
```sh
task set-game-jak1
task set-decomp-ntscv1
```
For other versions of the game, you will need to use a different `-set-decomp-<VERSION>` command. An example for the PAL version:
```sh
task set-game-jak1
task set-decomp-pal
task set-decomp-ntscv1# or for example for PAL, `task set-decomp-pal`
```
> Run `task --list` to see the other available options
> At the time of writing, only Jak 1 is expected to work end-to-end!
The first step is to extract your ISO file contents into the `iso_data/<game-name>` folder. In the case of Jak 1 this is `iso_data/jak1`.
Next, ensure you extract your ISO file contents into the relevant `iso_data/<game-name>` folder. In the case of Jak 1 this is `iso_data/jak1`.
Once this is done, open a terminal in the `jak-project` folder and run the following:
@@ -315,7 +121,7 @@ Once this is done, open a terminal in the `jak-project` folder and run the follo
task extract
```
#### Build the Game
#### Build the Game (Running the Compiler)
The next step is to build the game itself. To do so, in the same terminal run the following:
@@ -352,7 +158,7 @@ g > (mi)
#### Run the Game
Finally the game can be ran. Open a second terminal from the `jak-project` directory and run the following:
Finally the game can be launched. Open a second terminal from the `jak-project` directory and run the following:
```sh
task boot-game
@@ -408,81 +214,6 @@ gc> (test-play)
gc>
```
#### Interacting with the Game
In the graphics window, you can use the period key to bring up the debug menu. Controllers also work, using the same mapping as the original game.
Check out the `pc_debug`, `examples` and `pc` folders under `goal_src` for some examples of GOAL code we wrote. The debug files that are not loaded automatically by the engine have instructions for how to run them.
## Technical Project Overview
There are four main components to the project.
1.`goalc` - the GOAL compiler for x86-64
2.`decompiler` - our decompiler
3.`goal_src/` - the folder containing all OpenGOAL / GOOS code
4.`game` - aka the runtime written in C++
Let's break down each component.
### `goalc`
Our implementation of GOAL is called OpenGOAL.
All of the compiler source code is in `goalc/`. The compiler is controlled through a prompt which can be used to enter commands to compile, connect to a running GOAL program for interaction, run the OpenGOAL debugger, or, if you are connected to a running GOAL program, can be used as a REPL to run code interactively. In addition to compiling code files, the compiler has features to pack and build data files.
#### Running the compiler
**Environment Agnostic**
If you have installed `task` as recommended above, you can run the compiler with `task repl`
**Linux**
To run the compiler on Linux, there is a script `scripts/shell/gc.sh`.
**Windows**
On Windows, there is a `scripts/batch/gc.bat` scripts and a `scripts/batch/gc-no-lt.bat` script, the latter of which will not attempt to automatically attach to a running target.
### `decompiler`
The second component to the project is the decompiler.
The decompiler will output code and other data intended to be inspected by humans in the `decompiler_out` folder. Files in this folder will not be used by the compiler.
#### Running the decompiler
You must have a copy of the PS2 game and place all files from the DVD inside a folder corresponding to the game within `iso_data` folder (`jak1` for Jak 1 Black Label, etc.), as seen in this picture:
The decompiler will extract assets to the `assets` folder. These assets will be used by the compiler when building the port, and you may want to turn asset extraction off after running it once.
**Environment Agnostic**
If you have installed `task` as recommended above, you can run the compiler with `task decomp`
**Linux**
To run, you can use `scripts/shell/decomp.sh` to run the decompiler
**Windows**
To run, you can use `scripts/shell/decomp-jak1.bat` to run the decompiler
### `goal_src/`
The game source code, written in OpenGOAL, is located in `goal_src`. All GOAL and GOOS code should be in this folder.
### `game` runtime
The final component is the "runtime", located in `game`. This is the part of the game that's written in C++.
In the port, that includes:
- The "C Kernel", which contains the GOAL linker and some low-level GOAL language features. GOAL has a completely custom dynamically linked object file format so in order to load the first GOAL code, you need a linker written in C++. Some low-level functions for memory allocation, communicating with the I/O Processor, symbol table, strings, and the type system are also implemented in C, as these are required for the linker. It also listens for incoming messages from the compiler and passes them to the running game. This also initializes the game, by initializing the PS2 hardware, allocating the GOAL heaps, loading the GOAL kernel off of the DVD, and executing the kernel dispatcher function. This is in the `game/kernel` folder. This should be as close as possible to the game, and all differences should be noted with a comment.
- Implementation of Sony's standard library. GOAL code can call C library functions, and Naughty Dog used some Sony library functions to access files, memory cards, controllers, and communicate with the separate I/O Processor. The library functions are in `game/sce`. Implementations of library features specific to the PC port are located in `game/system`.
- The I/O Processor driver, OVERLORD. The PS2 had a separate CPU called the I/O Processor (IOP) that was directly connected to the DVD drive hardware and the sound hardware. Naughty Dog created a custom driver for the IOP that handled streaming data off of the DVD. It is much more complicated than I first expected. It's located in `game/overlord`. Like the C kernel, we try to keep this as close as possible to the actual game.
- Sound code. Naughty Dog used a third party library for sound called `989SND`. Code for the library and an interface for it is located in `game/sound`.
- PC specific graphics code. We have a functional OpenGL renderer and context that can create a game window and display graphics on it. The specific renderers used by the game however are mostly implemented. Aside from post-processing effects, everything in the game is rendered. This is located in `game/graphics`. While many liberties will be taken to make this work, the end result should very closely match the actual game.
- Extra assets used by the port in some fashion, located in `game/assets`. These include extra text files, icons, etc.
Some more detail about the various components of the project can be found [here](/docs/project-overview.md)
Loaded 100 of 8910 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hat Kid