372 Commits

Author	SHA1	Message	Date
Jonathan Hohle	249cd2ae7c	Support Servants in make-config.py (#1917) ... Adds match targets for servants.	2024-11-19 19:36:37 +00:00
H.M. Burger	1148580550	Adding Demon servant overlay (#1915)	2024-11-19 18:29:23 +01:00
H.M. Burger	a3678181dc	Changing PLAYER_STATUS_UNK40000 to PLAYER_STATUS_ZERO_HP (#1911) ... Simple change. Figured out that UNK40000 is either "Player has Zero HP" or "Player is dead", which is largely the same I think. The Faerie "Life Apple" ability triggers off of this status. Touches a lot of files so I didn't want to put it in my Faerie refactor. Also a small renaming in Faerie that I realized I forgot in my refactor	2024-11-19 05:58:31 +01:00
Mark Street	38fb2600ef	Migrate rodata for dra_psp (update mwccgap) (#1894)	2024-11-11 20:16:36 +00:00
Luciano Ciccariello	c1eec14a1a	Remove PR bot (#1890) ... It was a funny little experiment that it was worth trying. Unfortunately it had to major flaws: * There is no easy way to update an existing comment without some scripting, use of tokens and PR manipulation through the GitHub API. It was simply not worth it. * If the opened PR does not have the very latest changes from the default branch, it will report a drop in progress, which is obviously not correct. I could have internally rebased the PR before calculating the changed progress, but it has its own challenges like having to deal with conflicts.	2024-11-09 17:42:24 +00:00
Jonathan Hohle	966cfae72a	Fix VERSION Warning When Generating Context (#1887) ... This updates `m2ctx` to be aware of the `VERSION` env var and sets that env var in the Makefile prior to running `m2ctx` to eliminate the: warning: #warning "Version not specified. Falling back to the US version." [-Wcpp] error caused by `common.h`. This also removes `#define __STDC_HOSTED__ 0` from the generated context. That macro causes redefinition warnings in decomp.me.	2024-11-09 12:18:08 +00:00
bismurphy	9eb2d507b9	Decompile PSP version of func_801024DC (#1886) ... Picked a random `.c` file from PSP to decompile. This caused me to discover that this function requires `-O4,p`, which is new. All the other -O4 files also match with this, which is good. Also back-ported my changes to PS1. Some tiny changes to the texture displaying tools that I made due to xeeynamo finding a tiny bug; not worth a whole PR so I just tossed them into this one.	2024-11-08 20:11:45 +00:00
Luciano Ciccariello	3649d507c1	Decompress image assets found in the stage files as PNGs (#1868) ... Instead of outputting a `D_80123456.dec` from an extracted compressed asset, now a PNG is written from the decompressed data from the specified YAML entry. The asset tool will synchronize with splat to retrieve the symbol names for graphics and palettes. The new splat extension `cmpgfx` will also be able to detect unused graphics by failing with a hint on how to tweak the YAML. That way I found some unused placeholders under the name `stage_placeholder` and some kind of beta graphics from the prologue stage.	2024-11-03 08:51:42 +00:00
Luciano Ciccariello	078056fead	Re-activate all the overlay progresses	2024-11-02 10:31:34 +00:00
Luciano Ciccariello	b479872f0d	Report data (.data, .rodata, .bss) progress (#1866) ... I should have done this before the sotn-assets work. Better late than never.	2024-11-02 01:22:29 +00:00
Luciano Ciccariello	84d6aa802c	Fix progress for pspeu overlays (#1864) ... Fix regression required to correctly report progresses. I plan to get this merged before #1861 . I modified the validation step to report the progress on the PR as as comment, so we can avoid any weirdness in the future.	2024-11-01 19:43:28 +00:00
Luciano Ciccariello	ff50d01dee	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
Luciano Ciccariello	32cd40b860	Add PSP DRA (#1119) ... Co-authored-by: sozud <122322823+sozud@users.noreply.github.com> Co-authored-by: bismurphy <tjmurphy@mit.edu>	2024-11-01 11:07:20 +00:00
bismurphy	2467f973d6	Various cleanup on a few things (#1858) ... 1. Give a name to the variable `g_PauseAllowed` - this is a bool which gets tested when we're also testing for pressing START or SELECT to open the menu or map, so to me it seems like it's flagging whether or not you are allowed to pause. It is normally 1, but gets set to 0 at the start of cutscenes, and then restored to 1 at the end of them. 2. Name LAYOUT_RECT_PARAMS_HIDEONMAP, which is relevant for item 3 on this list. I already used the HideOnMap name when setting up this flag in the assets handler in my previous PR. 3. Name `g_canRevealMap` - this is a variable that is normally set to true, but for some particular rooms in the game, it's set to 0. Those rooms will not appear on your map. Good examples include the forest area left of the castle gate (the first moment we see Alucard), and the DRE stage. This variable gets set to 0 if the LayerDef has the LAYOUT_RECT_PARAMS_HIDEONMAP flag set. 4. Deduplicate a common structure in the code where entities have a debug routine that lets the Player 2 controller control the behavior of the entity. By pulling this out, the code can be more concise. Most importantly, when searching the codebase for g_Pads[1] (which is an interesting thing to do, since we're looking at uses of the Player 2 controller in a single-player game), you can focus on the interesting, unique examples, rather than having a ton of copies of the same exact code. 5. Change all instances of `g_Pads->` to `g_Pads[0].` A minor change, but good to use a formatting which makes it clear that g_Pads is the array of both pads, and not a pointer to one. 6. A couple functions I noticed with obvious fake stuff (including a do{}while(0)) have been adjusted so that they will match on PSP. Naturally, this also meant removing those fake things, which is always nice. Overall, this is several small changes combined into one PR; honestly I just scrolled through the codebase for a while, finding things that made me think "I know a way this could be better". Others may disagree with some of these though, happy to take input, especially on the new names!	2024-10-31 23:44:05 +00:00
bismurphy	86bcbb69d6	Eliminate MyLayer and MyRoomDef to use the normal structs (#1857) ... These were temporary structs that were needed for the assets tool. I adjusted the assets tool so that we will now properly produce normal RoomDef and LayerDef structs, so now we don't need these. Should help with understanding how the rooms work.	2024-10-31 22:12:30 +00:00
Luciano Ciccariello	5a447796d6	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
Josh Schreuder	43a75ee47c	Add linter for g_Player.status (#1849)	2024-10-30 21:02:00 +00:00
Jonathan Hohle	7b8ccc3e29	PrimitiveType Lint (#1845) ... Adds a line transformer to `sotn-lint` for replacing integers with the appropriate `PrimitiveType` enum when the variable is named `prim` and the field being accessed or mutated is named `type`. The regex for matching statements with enum fields and some binary operation has been moved out to be shared by `EnumLineTransformer` which can find and replace traditional incrementing `enum`s, as well as the existing `BitFlagLingTransformer`, which finds and replaces flag-type enums.	2024-10-29 15:24:36 -07:00
Luciano Ciccariello	1b10fd7806	Asset tool refactor (#1844) ... `sotn-assets stage extract` and `sotn-assets stage build` are gone in favour of `config/assets.$(VERSION).yaml`. `sotn-asset stage info` is now replaced with `sotn-stage info` to retrieve expanded metadata on how to use the tool for new overlays and reduce the burden of hunting for data. There are tons of change, too many to describe. In short the tool is much simpler than before and data is decoupled from each other. Each data type is defined as a handler. A handler has `Extract` to create the files in `assets/`, a `Build` to convert `assets/` files into embeddedable code in `src/`, and `Info` to get stage metadata. Please refer to the commit list for a breakdown of the changes done.	2024-10-29 08:38:05 +00:00
Luciano Ciccariello	86c09e6e15	Add rooms handler in the asset manager (#1836) ... Like #1831, I am decoupling the rooms from the old way to the new one.	2024-10-27 23:06:18 +00:00
Luciano Ciccariello	d243ab82d9	Extract sprite banks from all overlays (#1831) ... Took me for ever to get through this this but here you go. All the `assets/st/*/sprite_banks.json` and `assets/boss/*/sprite_banks.json` are getting extracted and built back into `src/`. Not all of them are actually linked but there are some major changes to make before that happens. Despite the asset-tool being relatively new, it suffered from a major design flaw. The tool expected overlays to store data in a contiguous way. The order of the data type must be the same and no gaps between data are allowed. This assumption started to show the cracks for new overlays The tool needs to change. Data should be uncoupled but that means offset and type has to be explicitly defined in `config/assets.us.yaml`. I plan to keep maintaining `sotn-assets stage info` to automatically generate the right asset and splat YAMLs, so it should be easier to maintain.	2024-10-27 11:12:49 +00:00
bismurphy	5d68662c27	Name FLAG_BLINK for entities (#1828) ... This came up a little while ago, I discovered the purpose of this entity flag and we agreed in Discord that FLAG_BLINK would be the best name. This entire PR was a single find-and-replace operation; doesn't seem to have caught any false matches :)	2024-10-26 11:40:16 +01:00
bismurphy	5bc549223e	Tweak the handling of the LayoutEntity files created by sotn-assets (#1817) ... This changes the formatting of the generated layout entities in order to make the files (in my opinion) more readable. We do the following: 1. change the types in e_laydef to make the offsets make more sense and reduce casts 2. Break up e_layout into blocks to more easily see where the boundaries between each room's data are 3. Add comments between those boundaries with the offsets, to easily cross-reference e_laydef and e_layout 4. Implement reading of the EntityIDs enum so that entities are listed by ID in e_layout.c to make it easier to identify them 5. Include the overlay's .h file rather than common.h, to allow access to the EntityIDs enum. Sounds like we want to make changes here to move this stuff up to the JSON, so I'll mark this as a draft while we determine the long-term desired functionality. Also, just a heads-up that this is my first time working with Go, so I might have done some bad code practices.	2024-10-23 17:36:31 +01:00
bismurphy	16c3226a09	Name DRA EntitySmallRisingHeart; improve animations (#1811) ... I found `func_80119D3C` and then went through the process of identifying it as the rising heart that comes when Alucard gains hearts through use of the Blood Cloak or the Alucard Shield or Herald Shield. In this process, I used display_animation.py to be able to view the sprite for the entity; doing this required me to convert some of the sprite data from placeholder u32 arrays to the proper s16 arrays, so I've also modified that data in d_2F324.c. Just another PR that makes things more readable without really changing anything in terms of real progress.	2024-10-20 21:10:10 +01:00
Luciano Ciccariello	621eeb2501	Fix RBO3 progress (#1810) ... The code path I deleted was pretty much dead with the exception of `BORBO3` where the bug was triggered. Essentially the tool was looking for `asm/us/boss/rbo3/nonmatchings/rbo3/nonmatchings`, which had no content and let the tool assume the overlay completion was 100%. I also added a guard where if `nonmatchings` is not found but also `matchings` is not there, the tool will terminate immediately. This should prevent any future oddity.	2024-10-19 20:00:46 +01:00
Jonathan Hohle	617d3e94b7	Support Additional Enum Lint Detection (#1796) ... `sotn-lint` can now find numeric enum values within equality expressions (`==`, `!=`), inside the condition of logical expressions, (`if`, `while`, `?:`, etc.), within compound statements, and if the numeric value is the starting value of a mixed numeric and enum logical expression (e.g. `self->flags = 15 | FLAG_FOO | FLAG_BAR;`). Resolves #1795.	2024-10-19 18:51:25 +01:00
Josh Schreuder	f379677011	Fix issue with line split INCLUDE_ASM not being picked up by dups report (#1799) ... Noticed this in the workflow output: ``` checking "../../src/boss/rbo3/create_entity.c" Failed to match regex on line: INCLUDE_ASM( Failed to match regex on line: INCLUDE_ASM( ``` This is because of the linting line breaks inserted to enforce column width https://github.com/Xeeynamo/sotn-decomp/blob/master/src/boss/rbo3/create_entity.c#L6-L7 For INCLUDE_ASM lines this code checks if it contains a `;`, otherwise it will attempt to buffer subsequent lines until `;` is found to get the full INCLUDE_ASM. Also updated the regex slightly to allow for an optional line break component Gist output: https://gist.github.com/JoshSchreuder/bf8621628640e9da96de2a565c982d00	2024-10-17 17:30:53 -07:00
H.M. Burger	11232925cc	Adding tt_002 (Faerie) overlay (#1801) ... I also deduped the common shared servant functions except ProcessSfxState. That one has a jumptable and I didn't want to mess with multiple files/.rodata while just adding a new overlay.	2024-10-17 14:02:53 -07:00
Jonathan Hohle	753e2efc9e	Split RBO3 (#1794) ... Splits RBO3 into logical segments based on other stage overlays. Updates key in `progress.py` to match overlay naming convention.	2024-10-16 11:47:09 -07:00
Josh Schreuder	6b544663ff	Ensure decompiled function is treated as the initial comparison basis in dupe report (#1791) ... This should prevent cases like this:  Where the nonmatching function is treated as the comparison for similarity. After fixing: 	2024-10-15 18:11:34 -07:00
Luciano Ciccariello	533822ad76	WRP and CEN cohabitation (#1701) ... Experimental piece of work I feel confident enough to submit. A few things to take in consideration: * The new `pfn_entity_updates.h` header aims to use the PSP variant of `PfnEntityUpdates` and the two `g_pStObjLayout`, I just tweaked a bit the code from `stage.h` * Add overlay prefix to the PSX version of `PfnEntityUpdates` and the two `g_pStObjLayout` * Changed `wrp/create_entity` to `rwrp/create_entity` in RWRP because we need the `RWRP_` prefix to be issued * Remodernized the WRP header * I am still not sure what's wrong with `g_HeartDropArray` in `warp.c`. I am pretty sure it is a PSX bug. I opted for the PSP version There's a `// PfnEntityUpdates = OVL_EXPORT(EntityUpdates);`. If you uncomment and resolve the multiple definitions you will have the two overlays linked. I still need to figure out how to handle the `InitializeEntity` parameters in `e_init` without going mad with the `#ifdef`. Takeaways from the Xbox 360 build: * `EntityBreakable` is different in every overlay, so we can use the `OVL_EXPORT` in our decomp * Every other function seem to be de-duplciated. For those functions that are slightly different between overlays, the developers of the Xbox port opted for `if (g_StageId == XYZ)` Takeaways from the PSP build: * god bless the psp	2024-10-13 22:15:19 +01:00
Luciano Ciccariello	a915ff0fbd	Modernize headers (#1743) ... Extract some commits out of #1701 and avoid the part that will lead to a build failure (fixed in #1738). Now every header uses `OVL_EXPORT`.	2024-10-10 21:37:25 +01:00
Luciano Ciccariello	30652db2dd	Asset cutscene two stages (#1738) ... I completely rewrote the cutscene asset handler. Now instead of parsing the data from the original overlay into a C-like header file, it instead follows a two-stage process. This works by extracting it in `asset/` with `make extract_assets`, to then allow modders to modify the file and build it as a C-like header with `make build_assets`. This also aims to fix #1701 as the build process takes account of the two-stage process. I created a framework where each asset type should only make available the two methods `Extract` and `Build`. The entire transformation process should be isolated to not create cognitive overload like what we can find in `build.go`. I would need to migrate all the existing asset types to properly use this new framework. The old code served well enough to understand how to build the entire infrastructure, but it needs to be migrated using the new pattern. Last, but not least, I renamed `config/assets.us.weapon.yaml` to `config/assets.us.yaml` as it is now used by all the overlays	2024-10-06 13:10:06 +01:00
bismurphy	02e4c62f6a	Add display_animations.py tool for viewing entity animation frames (#1746) ... This extends upon my work in display_texture.py. I have used this for identifying a few entities already. display_texture is suited for viewing prims, while this one is better for entities that are rendered by RenderEntities. I think there's enough documentation at the top of the function for others to use it. Hopefully it can be helpful, especially as it evolves over time. At some point this could be converted to an editor in addition to a viewer, but for now the viewing capability is the core focus. Also rewrote some of DRA's sprite data (this should probably be in sotn-assets though) to fit the standard format so that this tool could parse the data.	2024-10-06 13:09:33 +01:00
bismurphy	9ce2a3fbf6	Rework sotn-assets animation pointers (#1742) ... I was reviewing some of the animations pulled out by sotn-assets. Speicfically, I found that in `src/st/no3/sprite_banks.h` (a file created by sotn-assets locally, which does not exist directly in this repo), we have: ``` extern s16* sprites_no3_0; extern s16* sprites_no3_1; extern s16* sprites_no3_2; extern s16* sprites_no3_3; extern s16* sprites_no3_4; extern s16* sprites_no3_5; extern s16* sprites_no3_6; extern s16* sprites_no3_7; extern s16* sprites_no3_8; static s16* spriteBanks[] = { 0, &sprites_no3_0, &sprites_no3_3, &sprites_no3_1, &sprites_no3_2, &sprites_no3_4, &sprites_no3_5, &sprites_no3_6, &sprites_no3_7, &sprites_no3_8, ``` However, those are not the right pointer types. `sprites_no3_#` should have a type of `s16* []`, so I reworked the sotn-assets tool to use the right pointers for each of these things. Now the sprite_banks.h file looks like: ``` extern s16* sprites_no3_0[]; extern s16* sprites_no3_1[]; extern s16* sprites_no3_2[]; extern s16* sprites_no3_3[]; extern s16* sprites_no3_4[]; extern s16* sprites_no3_5[]; extern s16* sprites_no3_6[]; extern s16* sprites_no3_7[]; extern s16* sprites_no3_8[]; static s16** spriteBanks[] = { 0, sprites_no3_0, sprites_no3_3, sprites_no3_1, sprites_no3_2, sprites_no3_4, sprites_no3_5, sprites_no3_6, sprites_no3_7, sprites_no3_8, ``` Which more accurately represents the data within. Naturally, since this PR mostly just changes the tool, the real changes are in the tool's output, so feel free to clone this branch and investigate the sprite_banks.h file if you want to see anything further about it. DRA's equivalent of the SpriteBanks array is `D_800A3B70`, and is currently in the repo as extracted data, without using `sotn-assets`; this PR makes it so the types in the overlays (which do use `sotn-assets`) will match the types in DRA.	2024-10-05 21:28:16 +01:00
bismurphy	4ec4a04c38	Migrate sotn-assets to use u16/s16 types (#1740) ... I did a find and replace for "unsigned short" to "u16" in the sotn-assets `build.go` file and the same for "signed short" to "s16". Then I went through and added common.h imports to fix each of the build errors until it worked. Using the numerical types is preferred due to being shorter (reducing line wrapping), and to be future-proof for any systems where the "short" type might not be 16 bits.	2024-10-05 18:22:03 +01:00
sozud	887e32510b	Get rid of non-functions in function_finder	2024-10-02 23:47:11 -07:00
sozud	b64cda2e3f	Fix dirs?	2024-10-02 21:47:57 -07:00
sozud	a239ecc7e0	Fix argument?	2024-10-02 21:34:09 -07:00
sozud	a24c5cdca1	Fix path?	2024-10-02 21:31:16 -07:00
sozud	3ac5786db0	Try fixing analyze_calls	2024-10-02 21:23:59 -07:00
Josh Schreuder	98b784a592	Add duplicate match info to function report (#1719)	2024-10-02 20:54:24 -07:00
sozud	82a40f7a24	Fix dups tool	2024-09-30 11:13:21 -07:00
bismurphy	2e4ebb994e	Add NO0 (Marble Gallery) overlay (#1691) ... This adds this overlay to the project. Importantly, we use a new tool (tools/auto_dedupe_new_overlay) to process the new overlay and automatically split its C files according to known duplicate files. As of now, this does not do any decompiling (the whole overlay is kept as INCLUDE_ASM), but it automatically does all the file splits and code copying needed. Hopefully this reduces some amount of duplicated work. To be clear, this new script is not in any build chain, but is meant to be used after `make-config` to take the overlay from being a single giant lump of `us.c` to being individual files, for the sake of easier deduplicating. It will likely need some revision for future overlays, but at least it should be a good start toward reducing tedious work. I'll leave this overlay in place like this for about a week in case there are any newcomers who would like to try de-duplicating some of these files and decompiling the new functions; after that week I'll get into doing things myself.	2024-09-30 00:53:54 +01:00
sozud	fb8e5d7950	Revert "Add duplicate match info to function report" (#1693) ... Reverts Xeeynamo/sotn-decomp#1690	2024-09-28 20:39:33 -07:00
Josh Schreuder	efcf8d4d20	Add duplicate match info to function report (#1690) ... This can be merged after #1689 which fixes some things with the CI workflows	2024-09-28 20:18:19 -07:00
Luciano Ciccariello	f86e111fc5	Extract cutscene scripts, portraits and normalize code (#1686) ... More research on how cutscenes work. I normalized all the various C files as `cutscene.c`, marked all the isolated function as `static` and renamed the main entity as `{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the `OVL_EXPORT` to automate the names. TO-DO: - [x] Rename entity as `{STAGE}_EntityCutscene` for consistency - [x] CEN - [x] DRE - [x] NO3 - [x] NZ0 - [x] ST0 - [x] MAR ~~SEL~~ The offset of the portrait data seems to be hardcoded. I have no idea how to resolve these offsets at compilation time. The entire cutscene script thing is very sketchy and horribly designed by the original developers. What a nightmare to integrate into our project. This is how a cutscene script gets decompiled: ``` LOAD_PORTRAIT(0x80188D8C, 0), SET_PORTRAIT(1, 0), SCRIPT_UNKNOWN_11(), PLAY_SOUND(0x37B), WAIT_FOR_SOUND(), SET_SPEED(4), 'T','h','a','t',' ','v','o','i','c','e','!',' ', SET_WAIT(16), SET_SPEED(3), 'A','l','u','c','a','r','d',',', LINE_BREAK(), SET_WAIT(16), SET_FLAG(2), 'i','t','\'','s',' ','y','o','u','!', SET_WAIT(48), NEXT_DIALOG(), ```	2024-09-28 19:56:35 -07:00
sozud	4be6249664	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 09:29:16 -07:00
sozud	0ac2fa8bf7	Revert "Add duplicate match info to function report" (#1688) ... Reverts Xeeynamo/sotn-decomp#1685	2024-09-27 22:12:34 -07:00
Josh Schreuder	b31367b227	Add duplicate match info to function report (#1685) ... Had an idea, not sure if this is useful or not but I figured it might help give an indication for newer people or those not in the Discord loop if code is already duplicated when looking at the function report. Here's an example output from the current state (minus the scratches which didn't seem to load for me locally so I skipped them) [functions.md](https://github.com/user-attachments/files/17162454/functions.md) @bismurphy guessing this would be your area of expertise 😄 	2024-09-27 21:21:30 -07:00