RIC had 3 functions remaining, one of which was this one. Given its
similarity to the one in DRA, I decided to revisit it, and thankfully it
now matches.
I also did some cleanup on the DRA one, including renaming variables,
using macros, etc.
We now have two functions remaining in RIC. They are both duplicates of
remaining DRA functions, which have the same issues as the DRA ones do.
This means that once DRA is solved, RIC will be too, which is amazing!
This takes the GPU from Mednafen and hooks it up by using parts of
libgpu and writing to the fifo. I avoid using DMA and just write
directly and it seems to work fine. This means that the OTAG part isn't
required since that's part of the DMA system and not the GPU apparently.
The main bug I'm aware of is the TILE that fades to white in the warp
room doesn't show up. The GL renderer is still available. I made the
software renderer the default since it's faster and more accurate on
average. The two renderers can be toggled with F8. I turned on linear
logs by default since it's significantly faster.
The biggest gap I'm aware of is PutDispEnv needs to be properly
decompiled and hooked up.
This function was previously the last function in its file.
Upon decompiling, the rodata (specifically the `00 00 00 00` pattern)
indicated that the file does not end here, and that in fact the entire
following file should be part of this file, so I had to change the
splits to accomplish this.
It's an ugly function, and was hard to get a match, but here it is. Did
what I could to document variables but it doesn't seem to make much
sense, if you ask me.
The way this one uses scratchpad is super weird, but hey, it matches.
It's always fun to come across super-unique functions and I'm pretty
confident to say this qualifies.
This was EntityMPReplenished, but then I looked into how it is used and
found that it is used for many other things besides replenishing MP, so
I named it more generically.
I think I hunted down every situation where it is used and documented
them fairly well. In general, I think this is a relatively good-looking
function and is easy to read.
Looking forward to seeing any feedback!
Now with the maspsx changes, this can also match by using
SPRITESHEET_PTR.
Tried to document all the variables, use flags when possible, etc, so
hopefully this is mostly complete. Should be exciting to have
RenderEntities and RenderPrimitives both working now!
Open to suggestions for how to break this change up to make it easier to
review. The data extraction necessary for naming values in `D_800ACF60`
and `D_800ACF84` could be a separate commit... but I'm not sure it's
worth it.
Another one of these PRs that takes an old function that was decompiled
a while ago, and updates it to today's standards.
We move out of using ext.generic, and we use LOW() and LOH() macros
where relevant.
We also cleanup the logic by using PSP as a guide.
This looks nicer, and is also a great example of lots of LOW and LOH on
primitive members, which may be useful in studying what Primitive might
really be, and whether any of its members (such as the RGBP sets) might
actually be structs.
This links w_000 and allows the texture to be loaded to vram, as well as
the functions executed.
g_Cluts was renamed since the stages also have g_Cluts. A macro and
preprocessor defines are used to allow unique weapon function names.
This doesn't load the animsets since it seems like that stuff is getting
redone with the asset manager.
This is the largest function remaining in the decomp, and now it's dealt
with.
It's a giant beast and I can't claim to be anywhere near understanding a
single thing that it does. Researching this and documenting it will be a
second giant PR. Maybe I'll do that someday, but for now I'll leave it
to anyone else who wants to give it a try. None of the variables have
useful names. We could have "give the variables in this function useful
names relating to how they are used" be a "good first PR" issue, since
we set up several of those a while ago.
Data types on some of the externs it uses have been changed to match how
the function uses them.
This also uses g_PlOvlSpritesheet, which we have found seems to need to
be accessed as a numerical pointer, so I added a #define for that. It
seems to be working, so big thank you to everyone who was involved in
the process of setting that up. I believe this is the first function to
actually make use of that.
Besides that, I'll leave it to others to make their comments. There is
really too much in this function for me to talk about it, but hopefully
this is a reasonable start and we can make whatever tweaks are needed to
get this merged.
This is a big messy function, but it's decompiled!
Did what I could to rename variables in a useful way, but I could only
get so far. Hopefully one day we can work out exactly what all the
different angles, XY variables, etc are. But this is one of the biggest
remaining functions and it's great to have matching.
Lots of small changes here, but ultimately this ends up rewriting the
whole function.
I opened this one in PSP (it's `-O4`!) and found several differences
which I corrected. I also rewrote some of the if-statements to be a bit
more readable.
Kind of a weird function the way it's testing for hard-coded X and Y
values. Not sure what this function actually does.
We also end up only calling `func_801042C4` once, which is a nice
improvement for readability.
`func_801042C4` is not decompiled, so I'll move on to that next.
Another adventure in examining a function alongside PSP.
The CLAMP_MAX and CLAMP_MIN seem like nice ideas, but I wasn't getting
them to match on PSP. And since they are very little-used in the repo,
keeping them around in here just didn't seem worth it.
As far as the `D_8013AE##` variables, I noticed they were consecutive in
addresses (they're all s32, and are all different by 4 bytes). Rather
than being a weird mix of individual values and arrays, I thought it
made more sense to treat them all as an array, and indeed it still
matches this way, so I think this is a more reasonable way to handle
this data.
I think those are all the changes that matter.
This is a relatively unimportant function, but it messes with some
variables that I am interested in learning more about, so I went ahead
and compared it to the PSP version.
This PR incorporates some lessons I learned from that PSP version. Most
importantly, the rotPivotX and rotPivotY in Entity are signed.
I also tracked down how this entity is created, it's a bit odd since it
doesn't call any entity creation function, and instead does a direct
write into g_Entities to create it.
On exit, this function calls `func_8012C600`, which I will be doing a
similar analysis for next.
There was a leftover rodata padding that doesn't do anything, so I
removed that too.
There was a question in the decomp discord about the bounce when Alucard
dive-kicks and hits an enemy. I tracked this down, and in the process,
found some moderately old functions that could use some improvements to
their code style. I also cross-referenced these with PSP to make the
code make a bit more sense.
The PSP version makes it clear that D_800ACF7C is not a struct and is
just an array of s16, so I made that change. The struct version matched
on PS1, but now that PSP reveals that it was fake, we turn it back to
just an array.
Let me know if I missed anything! Nice to have real names for some of
these functions.
I don't understand the file loading code that well but this gets the ALK
vab running. Maybe SIM_PTR should just be D_80280000 so we have that
buffer to use?
Decided to target this one since it's the largest remaining function in
`weapon` and now it's done. Kind of surprising that such a simple weapon
has such a huge function, but I guess it has a lot of graphics and
therefore a lot of primitive manipulation.
This aims to deprecate all the Splat tools in `tools/splat_ext` in
favour of a more centralised asset manager. This brings the following
advantages:
* Much faster extraction
* Faster build
* Automatically define `static` symbols or unique names whenever
`static` is not possible
* Allow to embed assets into the output binary
* Drastically simplify `Makefile` by removing all the asset build rules
* Avoid situations where it is not possible to extract and build assets
that is not 4-byte aligned
This is achieved by having the splat YAML targeting a normal C file as
data and have an external tool to take care of the following:
1. Extract asset files straight from the overlay binary file into human
readable file in `assets/st/STAGE_NAME`
2. Build assets as header files that go into `src/st/STAGE_NAME` to just
include them from any C file
This requires each stage header to have the following new format: please
see `src/st/nz0/header.c`
Built assets in `src/st` are ignored by Git.
As for now, for simplicity sake, the steps `make extract_assets` and
`make build_assets` are just executed within `make extract` exclusively
for the US version.
I plan to auto-generate files such as `src/st/nz0/tile_data.c`.
For a first iteration I am aiming to handle the following:
* [X] Extract rooms: `assets/st/*/rooms.json`
* [X] Extract room layers: `assets/st/*/entity_layouts.json`
* [X] Extract tilemap data: `assets/st/*/tilemap_*.bin`
* [X] Extract tilemap definitions: `assets/st/*/tiledef_*.json`
* [X] Extract sprites: `assets/st/*/sprites.json`
* [x] Extract entity layouts
* [X] Build rooms: `src/st/*/rooms.h`
* [X] Build room layers: `src/st/*/layers.h`
* [X] Build tilemap data: `src/st/*/tilemap_*.h`
* [X] Build tilemap definitions: `src/st/*/tiledef_*.h`
* [x] Build sprites (aka `g_SpriteBanks`)
* [x] Build entity layouts
* [x] Allow the tool to suggest how to adjust the Splat config for each
overlay
I want the tool to cover the following stages:
* [x] CEN
* [x] DRE
* ~MAD~ I do not think this can be done, it is way too different from
the other overlays
* [x] NO3
* [x] NP3
* [X] NZ0
* [x] ST0
* [X] WRP
* [x] RWRP
* ~WRP (PSP)~ Maybe in a follow-up PR
For a later iteration I plan on extracting and build:
* Entity GFX thingie
* The CLUT thingie in the header
* Uncompressed GFX data
* Cutscene data
* Blueprints
* The `src/config_us.h` thingie
---------
Co-authored-by: Josh Lory <josh.lory@outlook.com>
The Karma Coin, surprisingly, has the largest EntityWeaponAttack of all
the weapons. For that reason, I'm targeting it next.
It has one small other entity function, so this PR decompiles that
first, prior to going ahead and decompiling the EntityWeaponAttack
itself.
Otherwise, nothing too crazy special here. I imagine decompiling the
Karma Coin will make it clear what this helper entity is.
Got this working with the aid of PSP!
Scratches here:
PS1: https://decomp.me/scratch/FDWxW
PSP: https://decomp.me/scratch/SObUR
These are identical aside from the versions defined at the top of the
context, and everything else is done with `ifdef`.
Several of the `ifdef` differences are in structs that are defined in
`include/psxsdk/libgpu.h`, and since they're in the PSX SDK, I don't
want to add those PSP differences into that file. I imagine at some
point we'll have a PSP libgpu.h or something, but until then, this
function will not actually match on PSP. But since PSP is not the focus
of this decomp, I think that's okay.
This is 99% similar to Xeeynamo's scratch, the main difference is the
treatment of the lines that look like `setSemiTrans(&primbuf->g2,
var_s0->drawMode & DRAW_TRANSP);`.
Finishes the heaven sword.
More weirdness with the ext - it appears that unk84 is used differently
in different functions within this value.
Overall, this file could use some improvements, but to start out, having
it decompiled is better than not. Hopefully someone can figure out how
this actually all works.
This one is kind of ugly in places.
It uses offset 0x84 as an s32, while Weapon uses it to hold an entity,
so this forced the creation of a new ext for the heaven sword.
There is only one more function left in this file (EntityWeaponAttack),
so once that one is done, I will move the whole file over to use the
Heaven Sword extension.
Someone in the Long Library discord was asking about Heaven Sword
(especially its special attack) so I'll go ahead and decompile that
next.
This initial function appears to reveal that Heaven Sword doesn't follow
the main Weapon struct. I'm going to keep using it until the weapon is
done, so we can get a better picture of what the mismatching fields are.
All the struct members are the same size, they're just different names.
This PR is trying to get SsVabOpenHeadWithMode running, but I'm getting
the wrong result vs. my test app. I'm putting this up to see if others
have ideas.
c7484b6800/test.c (L154)
I check a bunch of preconditions on the test app and the implementation
so I think they are starting from the same state. The test app is able
to play the library song so I think it's OK.
The problem is that SpuMalloc returns the wrong value. See
```
_svm_vab_start[vabId] = spuAllocMem;
```
_svm_vab_start[0] is supposed to be 0x00001010 but instead we get
0x11010.
c7484b6800/test.c (L201)
```
69648 != 4112 in check_ss_vab_open_head_with_mode /home/d/sotn-decomp-2/src/pc/psxsdk/emu.cpp:306
```
The scratch for SpuMalloc is https://decomp.me/scratch/UjIPd
The version here is based off this one since I think that scratch isn't
usable yet.
4ff48d4660/psx_seq_player/lib_spu.cpp (L2462)
The scratch for func_800286E0 is https://decomp.me/scratch/msP8t
After building for all supported architectures `make format` was taking
around 30s. This commit includes various changes which get that down to
around 3½s on the same machine.
This changes the `format` target in a few ways:
* filters out files generated by CMake
* runs `clang-format` in parallel
* breaks `format` into 3 separate targets which can be run in parallel
When building the PC version cmake creates a file to test compiler
features. This file is picked up by the pattern which matches files for
`clang-format`. This file took around 20s, filtering it out brought
total format time to around 10s.
Instead of passing a list created by a `find` command directly as the
args to `clang-format` the list is now passed to `xargs` which runs
several processes in parallel, each looking at 10 files (determined by
experimentation). This has the added advantage of ensuring as the source
list grows `ARG_MAX` won't be a concern. This brought total format time
to around 6s.
`format` was broken up into three targets `-src`, `-tools`, and
`-symbols`. These targets can be run in parallel, bringing the total
time down to 3½s.
---------
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
