Game-Decompilation/sotn-decomp
1
0
Fork 0
mirror of https://github.com/Xeeynamo/sotn-decomp.git synced 2024-11-27 06:50:35 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity
95d91584b4
sotn-decomp/config/splat.us.stwrp.yaml

95 lines
3.0 KiB
YAML
Raw Normal View History

Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
options:
platform: psx
basename: stwrp
Use of rodata section
2022-10-16 08:55:11 +00:00
base_path: ..
Writes built binaries into build/us/
2023-02-21 20:06:27 +00:00
build_path: build/us
Change how game assets are managed
2023-02-21 23:25:24 +00:00
target_path: disks/us/ST/WRP/WRP.BIN
Change assembly location from asm/ to asm/us/
2023-02-21 19:11:05 +00:00
asm_path: asm/us/st/wrp
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
asset_path: assets/st/wrp
src_path: src/st/wrp
Enhance make extract on PSX (#662) Previously if either the YAML or the symbol list were changed, we were forced to either manually delete the `asm` folder of the specific overlay or to invoke `make clean`, where the latter forced us to re-extract all the overlays via `make -j extract`. That changes with this PR. How `make` works is `target: dep1 dep2` where if one of the dependencies has the last modified date greater than the target, the rule is triggered again. Previously we were extracting overlays doing `make extract_stcen`. But since every overlay extraction generates a linker script I now changed the rules to do `make build/us/stcen.ld` to extract the same overlay. As I explained above, if either the YAML or one of the related symbols changes, the linker modified date will be older and the extraction for that overlay to be trigger again. The above allowed me to stop polluting the repo root with the linker scripts as they are now moved into `build/us` or `build/hd` depending of what you're trying to build. If you do `make extract` twice in a row you will be welcomed with a `make: Nothing to be done for 'extract'.`. There are still some instances where you **might** need `make clean` beforehand, especially when modifying the `segment` section in the YAML or renaming the symbols. A `rm -rf asm/$(VERSION)/$*` can help but I want to see if the current solution will be enough. ### Please try removing `make clean` from your workflow, once this is merged, to quickly detect possible problems with this new approach. I am also planning to make more substantial changes on our build-chain like this PR or #660 in the future. I am aiming to small incremental changes over time in case I break someone's flow or detect design flaws. I am also considering the breaking changes introduced in make 4.4, which will most likely be included in Ubuntu 24.04 LTS. I set March 2024 as a deadline to finish all the new build-chain work. --------- Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
2023-10-05 08:26:29 +00:00
ld_script_path: build/us/stwrp.ld
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
compiler: GCC
Pass undefined_syms files to linker (#1065) Creating a PR for this, will look at updating splat in a separate PR
2024-02-18 14:57:03 +00:00
symbol_addrs_path:
- config/symbols.us.txt
- config/symbols.us.stwrp.txt
Rename config folder to use game version
2023-02-21 01:42:33 +00:00
undefined_funcs_auto_path: config/undefined_funcs_auto.us.stwrp.txt
undefined_syms_auto_path: config/undefined_syms_auto.us.stwrp.txt
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
find_file_boundaries: yes
use_legacy_include_asm: no
Use of rodata section
2022-10-16 08:55:11 +00:00
migrate_rodata_to_functions: no
use jlabel for rodata labels (#260) Compare https://decomp.me/scratch/dhUE5 with https://decomp.me/scratch/NZt5p. e.g. with this PR: ![image](https://github.com/Xeeynamo/sotn-decomp/assets/22226349/bf999863-a66f-4b64-abbe-a41e4be34181) vs without: ![image](https://github.com/Xeeynamo/sotn-decomp/assets/22226349/04141d82-aedd-4451-817c-ff98e9e10a17)
2023-06-18 14:17:36 +00:00
asm_jtbl_label_macro: jlabel
WRP split some data and add new split tools (#109) The objective is to separate the data that is usually written into `asm/*/data` into separate files. Those will initially be binary files. There is also an utility that allows to decompress compressed data. The decompressed data is currently not read as we are missing a compression algorithm that matches the original one. I tried writing one in the past: it worked, it re-created similar files but sadly not the same ones. The decompression algorithm is there to allow to do some data mining and understand what the data is and how it is used.
2023-03-09 13:32:00 +00:00
extensions_path: tools/splat_ext
Turn on disassemble_all for most yamls (#1689) This is prep for fixing our tooling and all the force_extract stuff. Weapon0 doesn't seem to match with this setting on for some reason?
2024-09-28 16:29:16 +00:00
disassemble_all: True
Fix decomp on binutils 2.36 and onward
2022-12-25 09:46:07 +00:00
section_order:
Set right sections for WRP
2023-01-08 23:30:47 +00:00
- ".data"
Fix decomp on binutils 2.36 and onward
2022-12-25 09:46:07 +00:00
- ".rodata"
- ".text"
Set right sections for WRP
2023-01-08 23:30:47 +00:00
- ".bss"
Update splat to 0.24.4 (#1112) Still work in progress. I removed splat as a submodule and started using it as a pip package instead. Everything is matching but the memory card icons part in both DRA and SEL. I still have no idea what the issue is. Once this PR is good to be merged, we can get rid of the splat fork too.
2024-06-12 17:50:32 +00:00
- ".sbss"
Build QoL (#1632) Several quality of life changes for building: * The Makefile has a `help` target which will show common targets. Targets with comments starting with `##@` will be included in the help output. * The `check` target now has colored output. * Added `check_disk` target which will check hashes of extracted disk contents (useful for those who dump their own discs) * Added `dump_disk` target which will create a bin/cue pair from an original disc.
2024-09-20 22:56:34 +00:00
sha1: 2ae313f4e394422e4c5f37a2d8e976e92f9e3cda
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
segments:
- name: stwrp
type: code
start: 0x00000000
vram: 0x80180000
Update splat to 0.24.4 (#1112) Still work in progress. I removed splat as a submodule and started using it as a pip package instead. Everything is matching but the memory card icons part in both DRA and SEL. I still have no idea what the issue is. Once this PR is good to be merged, we can get rid of the splat fork too.
2024-06-12 17:50:32 +00:00
align: 4
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
subalign: 4
subsegments:
WRP extract room data
2023-03-31 07:42:03 +00:00
- [0x0, .data, header]
Asset handler for graphics (#1862) Another chunky PR that automates the extraction of stage graphics and generate the necessary header data. This greatly simplifies and standardise the whole data import process for graphics. By observing the gaps between graphics data I also found some unused graphics. These are marked in the YAML.
2024-11-01 18:15:33 +00:00
- [0xA0, .data, header] # palette definitions
New asset manager (#1343) 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>
2024-07-02 20:38:36 +00:00
- [0xB8, .data, header] # layers
Asset handler for graphics (#1862) Another chunky PR that automates the extraction of stage graphics and generate the necessary header data. This greatly simplifies and standardise the whole data import process for graphics. By observing the gaps between graphics data I also found some unused graphics. These are marked in the YAML.
2024-11-01 18:15:33 +00:00
- [0x1B8, .data, header] # graphics banks
New asset manager (#1343) 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>
2024-07-02 20:38:36 +00:00
- [0x23C, .data, e_laydef] # layout entries header
Merge RWRP with WRP (#1425) This will decompile all the functions but the new `EntityRWarpRoom` from the RWRP overlay. Note that as `e_misc.c` has a function with a different castle flag, I had to use a shared header. Everything else was identical. --------- Co-authored-by: bismurphy <tjmurphy@mit.edu>
2024-07-22 14:57:21 +00:00
- [0x3E4, .data, e_init]
Move WRP data to match C file structure (#1292) More data imported into the C files. I reached this stopgap due to `st_debug.c`, where I am failing to import the data from PSP. Strangely enough, PSP suggests `st_debug`, `e_breakable` and even `warp` being in the same file?! The INIT section seems to follow the `PfnEntityUpdates` on both PSP and PSX. But on PSX this is very close to the top while on PSP is right in the middle. Overall the PSX C and DATA order seem to align perfectly. PSP is far more unpredictable, but the DATA order seem to also follow the C files. The advantage of PSP is that almost everything is out of order compared to PSX, which easily suggests file splits. Another key difference between PSP and PSX is that arrays filled with `0x00` are found in DATA on PSX and in BSS on PSP.
2024-06-10 04:14:03 +00:00
- [0x528, .data, st_debug]
- [0x5A8, .data, e_breakable]
Replace g_HeartDropArray with PrizeDrops (#1787) I discovered that `g_HeartDropArray` was always very weirdly used in overlays such as WRP, CEN and DRE where there are no prizes dropped from breakable objects. This lead me to discover that every overlay has a prize array that describes what items to drop. But for WRP CEN and DRE since the array has length zero, the symbol overlaps with what comes right after. The array is also different for every overlay. The array will be renamed as `OVL_EXPORT(PrizeDrops)`. This PR aims to adjust such array in all overlays: * [x] CEN * [x] DRE * [X] ~MAD~ cannot be moved * [x] NO0 * [x] NO3 * [x] NP3 * [x] NZ0 * [X] ~ST0~ not existent * [X] WRP * [X] RWRP * [x] MAR
2024-10-14 00:06:52 +00:00
- [0x608, .data, d_prize_drops]
Move WRP data to match C file structure (#1292) More data imported into the C files. I reached this stopgap due to `st_debug.c`, where I am failing to import the data from PSP. Strangely enough, PSP suggests `st_debug`, `e_breakable` and even `warp` being in the same file?! The INIT section seems to follow the `PfnEntityUpdates` on both PSP and PSX. But on PSX this is very close to the top while on PSP is right in the middle. Overall the PSX C and DATA order seem to align perfectly. PSP is far more unpredictable, but the DATA order seem to also follow the C files. The advantage of PSP is that almost everything is out of order compared to PSX, which easily suggests file splits. Another key difference between PSP and PSX is that arrays filled with `0x00` are found in DATA on PSX and in BSS on PSP.
2024-06-10 04:14:03 +00:00
- [0x648, .data, warp]
- [0x690, .data, st_update]
Share more code and data between stage overlays (#1281) Given the fact that sharing compiled C objects is not exactly possible (code heavily copy&pasted maybe? this initiative is now abandoned 👉 https://github.com/Xeeynamo/sotn-decomp/commit/53a566f075a395e064f42db28737d5ef351f0ea1) I decided to keep pressing forward with shared headers. Thanks a lot to @hohle for making our life much easier by cross-referencing symbols. The file split on WRP seems to be the closest file split we might have compared to the original source code (still speculating here). I think it would be a good idea to start splitting other overlays too with the same approach. My idea is to have a file split like the following: ``` st/ cen/ e_particles.c e_misc.c st_common.c nz0/ e_particles.c e_misc.c st_common.c wrp/ e_particles.c e_misc.c st_common.c e_particles.h e_misc.h st_common.h ``` each of those C files will just be a one-line `#include "../the_shared_code.h"` as usual. Right now we create individual headers for single functions, sometimes for more than one function when we think grouping makes sense. But I think we can start merging some of those headers and consolidate the code. This can be done gradually. For example `src/st/e_particles.h` is still importing function headers under the hood. That is okay for now, but later on I wish to import those headers functions into their respective parent headers. Another important aspect to consider that will validate a correct file split is to start importing the data inside these new C files. Right now we have floating data such as `src/st/wrp_psp/wrp_data_EA00.c` or monstrosities such as `src/st/wrp/6FD0.c`. An example of a (possibly) correct migrated data is what this PR does with WRP PSP and NZ0 PSX, with data pointing in `src/st/*/e_particles.c`.
2024-06-08 19:34:58 +00:00
- [0x6BC, .data, collision]
- [0xA7C, .data, e_red_door]
- [0xA94, .data, st_common]
- [0xC94, .data, e_collect]
ST WRP PSX re-organise C files (#1185) Same as #1181 but on PSX. The imported data falls right at the top of each new file based on some old assumptions of mine, suggesting we're probably on the right track.
2024-05-26 22:44:33 +00:00
- [0xF84, .data, e_misc]
- [0xFE8, .data, e_particles]
- [0x1120, .data, e_room_fg]
New asset manager (#1343) 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>
2024-07-02 20:38:36 +00:00
- [0x11AC, .data, rooms]
- [0x1228, .data, e_layout] # layout entries data
WRP split some data and add new split tools (#109) The objective is to separate the data that is usually written into `asm/*/data` into separate files. Those will initially be binary files. There is also an utility that allows to decompress compressed data. The decompressed data is currently not read as we are missing a compression algorithm that matches the original one. I tried writing one in the past: it worked, it re-created similar files but sadly not the same ones. The decompression algorithm is there to allow to do some data mining and understand what the data is and how it is used.
2023-03-09 13:32:00 +00:00
- [0x1420, cmp, D_80181420]
- [0x1764, cmp, D_80181764]
Asset handler for palette definition in the header (#1852) Automates the extraction of `u_long** OVL_EXPORT(cluts)[]` in `assets/` at extraction time and its code generation in `src/[boss|st]/palette_def.h`. This has the advantage that now palettes can be loaded and modified externally, change in size and external tools has now context on the palette order and where in the VRAM they are located. This also simplifies `header.c`, getting rid of the whole `PAL_BULK` section. Creating headers for stages and boss rooms will get progressively simpler. The tool is pickier on the size of exported palettes. This allowed me to find gaps of data for potential unused palette data. I marked them in the NZ0 YAML. If there are no concerns and I get an approval, I will extend `config/assets.us.yaml` to the remaining overlays.
2024-10-31 21:06:06 +00:00
- [0x1D08, pal, D_80181D08]
- [0x1D28, pal, D_80181D28]
New asset manager (#1343) 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>
2024-07-02 20:38:36 +00:00
- [0x1D68, .data, tile_data] # tile data
- [0x2968, .data, tile_data] # tile definitions
- [0x6D88, .data, sprites]
- [0x6E30, .rodata, warp] # warp strings
Add ST/WRP from PSP (#1172) Extract ST/WRP out of #1119 . All the function symbols should have been cross-referenced. There as some PSX functions missing from PSP and some new functions from PSP that are not present on PSX (e.g. `st_init_wrp.c`). The files `st_debug.c` and `e_breakable.c` are shared between WRP PSX and WRP PSP. Everything else from PSP is isolated into its own folder. I had to do some tricks on the YAML config to allow shared code. `ST_WRP_MERGE = st_debug e_breakable` in the `Makefile` is a bit annoying as MWCC complains about every single minute detail from the C source that has been already decompiled for the PSX US build. `EntityWarpSmallRocks` is matching on PSP but I couldn't extract the rodata without having a bunch of linker errors. This might be a Splat issue. I need to investigate further. `func_psp_09244760` is soooo interesting. The values from `0x11` to `0x17` matches the Entity IDs that are unique to the WRP overlay. This aligns to what we have in `typedef enum EntityIDs`. Overall I am very excited to the recent discoveries from the PSP build!
2024-05-25 18:56:06 +00:00
- [0x6E70, .rodata, warp] # EntityWarpRoom
- [0x6E90, .rodata, warp] # EntityWarpSmallRocks
ST WRP PSX re-organise C files (#1185) Same as #1181 but on PSX. The imported data falls right at the top of each new file based on some old assumptions of mine, suggesting we're probably on the right track.
2024-05-26 22:44:33 +00:00
- [0x6EA8, .rodata, e_red_door] # EntityRedDoor
Share more code and data between stage overlays (#1281) Given the fact that sharing compiled C objects is not exactly possible (code heavily copy&pasted maybe? this initiative is now abandoned 👉 https://github.com/Xeeynamo/sotn-decomp/commit/53a566f075a395e064f42db28737d5ef351f0ea1) I decided to keep pressing forward with shared headers. Thanks a lot to @hohle for making our life much easier by cross-referencing symbols. The file split on WRP seems to be the closest file split we might have compared to the original source code (still speculating here). I think it would be a good idea to start splitting other overlays too with the same approach. My idea is to have a file split like the following: ``` st/ cen/ e_particles.c e_misc.c st_common.c nz0/ e_particles.c e_misc.c st_common.c wrp/ e_particles.c e_misc.c st_common.c e_particles.h e_misc.h st_common.h ``` each of those C files will just be a one-line `#include "../the_shared_code.h"` as usual. Right now we create individual headers for single functions, sometimes for more than one function when we think grouping makes sense. But I think we can start merging some of those headers and consolidate the code. This can be done gradually. For example `src/st/e_particles.h` is still importing function headers under the hood. That is okay for now, but later on I wish to import those headers functions into their respective parent headers. Another important aspect to consider that will validate a correct file split is to start importing the data inside these new C files. Right now we have floating data such as `src/st/wrp_psp/wrp_data_EA00.c` or monstrosities such as `src/st/wrp/6FD0.c`. An example of a (possibly) correct migrated data is what this PR does with WRP PSP and NZ0 PSX, with data pointing in `src/st/*/e_particles.c`.
2024-06-08 19:34:58 +00:00
- [0x6EC0, .rodata, e_collect] # CollectGold strings
- [0x6F10, .rodata, e_collect] # EntityPrizeDrop
ST WRP PSX re-organise C files (#1185) Same as #1181 but on PSX. The imported data falls right at the top of each new file based on some old assumptions of mine, suggesting we're probably on the right track.
2024-05-26 22:44:33 +00:00
- [0x6F30, .rodata, e_collect] # EntityEquipItemDrop
- [0x6F48, .rodata, e_misc]
- [0x6F94, .rodata, e_stage_name] # EntityStageNamePopup
Move WRP data to match C file structure (#1292) More data imported into the C files. I reached this stopgap due to `st_debug.c`, where I am failing to import the data from PSP. Strangely enough, PSP suggests `st_debug`, `e_breakable` and even `warp` being in the same file?! The INIT section seems to follow the `PfnEntityUpdates` on both PSP and PSX. But on PSX this is very close to the top while on PSP is right in the middle. Overall the PSX C and DATA order seem to align perfectly. PSP is far more unpredictable, but the DATA order seem to also follow the C files. The advantage of PSP is that almost everything is out of order compared to PSX, which easily suggests file splits. Another key difference between PSP and PSX is that arrays filled with `0x00` are found in DATA on PSX and in BSS on PSP.
2024-06-10 04:14:03 +00:00
- [0x6FC8, .rodata, prim_helpers]
Add ST/WRP from PSP (#1172) Extract ST/WRP out of #1119 . All the function symbols should have been cross-referenced. There as some PSX functions missing from PSP and some new functions from PSP that are not present on PSX (e.g. `st_init_wrp.c`). The files `st_debug.c` and `e_breakable.c` are shared between WRP PSX and WRP PSP. Everything else from PSP is isolated into its own folder. I had to do some tricks on the YAML config to allow shared code. `ST_WRP_MERGE = st_debug e_breakable` in the `Makefile` is a bit annoying as MWCC complains about every single minute detail from the C source that has been already decompiled for the PSX US build. `EntityWarpSmallRocks` is matching on PSP but I couldn't extract the rodata without having a bunch of linker errors. This might be a Splat issue. I need to investigate further. `func_psp_09244760` is soooo interesting. The values from `0x11` to `0x17` matches the Entity IDs that are unique to the WRP overlay. This aligns to what we have in `typedef enum EntityIDs`. Overall I am very excited to the recent discoveries from the PSP build!
2024-05-25 18:56:06 +00:00
- [0x6FD0, c, st_debug]
- [0x726C, c, e_breakable]
- [0x73A0, c, warp]
ST WRP PSX re-organise C files (#1185) Same as #1181 but on PSX. The imported data falls right at the top of each new file based on some old assumptions of mine, suggesting we're probably on the right track.
2024-05-26 22:44:33 +00:00
- [0x81E8, c, st_update]
- [0x861C, c, collision]
- [0x9DD8, c, create_entity]
- [0xA950, c, e_red_door]
- [0xB600, c, st_common]
- [0xCAB0, c, e_collect]
- [0xE01C, c, blit_char]
- [0xE2CC, c, e_misc]
- [0x117BC, c, e_stage_name]
- [0x12610, c, e_particles]
- [0x12E54, c, e_room_fg]
- [0x12F40, c, popup]
Deduplicate functions and un-fake use of some Primitive structs (#991)
2024-01-18 19:04:04 +00:00
- [0x13270, c, prim_helpers]
Stage BSS Organizing, Padding Macros (#1497) Maps `create_entity` and `e_collect` data, text, and bss for all stages. Adds macros for defining padding for various sections by size. Tables for section sizes have been added to common includes to make calculating offsets easier when segments.
2024-08-11 14:49:53 +00:00
- [0x13AB0, .bss, create_entity]
- [0x13AC0, .bss, bss]
- [0x14728, .bss, e_collect]
Disassemble DRE, ST0, WRP and RWRP
2022-02-09 12:49:33 +00:00
- [0x14768]
Reference in New Issue Copy Permalink