2788 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
Josh Schreuder	6c8454590a	Decompile no0 Ghost functions (#1889) ... `EntityGhostEnemySpawner` / `func_us_801D606C` matching both PSX: https://decomp.me/scratch/CrIPN PSP: https://decomp.me/scratch/RyIgW `EntityGhostEnemy` / `func_us_801D5E4C` matching both PSX: https://decomp.me/scratch/YEAXd PSP: https://decomp.me/scratch/HpJ4I Also extracted the data and split files. That's for these cute little fellas: 	2024-11-09 14:48:40 +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
H.M. Burger	4eca413d89	Adding structs for servant ability stat tables (#1884) ... Adding GhostAbilityValues and BatAbilityValues structs for the ability stats by level lookup tables instead of using a multi dimension array with index defines.	2024-11-08 09:03:53 -08:00
H.M. Burger	65e22ca864	Decompile tt_002 func_us_80173D60 (#1883) ... This is the primary ability update function for Faerie. The basic idea is that we some upkeep every frame, and tick down the timer. Once the timer has ticked down, it resets and then searches through it's logic to figure out if the player is in a state that the Faerie can alliviate. If a path is found, a luck check is performed and if sucessful, the Entity ID is updated so that a different update function is called on the next update(s) to perform the action. Note, this is not initiated from the engine, this is called from many of the update functions that the engine does call on every frame. PSX: https://decomp.me/scratch/3ADW8 PSP: https://decomp.me/scratch/53Vc0 This should be a PSP match. @hohle got this most of the way, I just figured out the local variables. Co-authored-by: hohle <jonhohle@gmail.com>	2024-11-07 20:01:32 -08:00
H.M. Burger	7078ad6bc7	Data import tt_002 part two (#1882) ... Adding more of the animation data as well as some of the ranked lookup tables. I was trying to use a struct and/or unions to organize the data, but I just can't get it to match with anything other than a flat array that uses math and casts. So I've added some macros to hopefully help document the code and what's happening. I'm unsure if this "ranked lookup table" type thing is being done elsewhere, so I only added it to faerie for now. I do realize this sort of makes a mess of the file structure for the time being and a lot of these files can/will be merged back together once we get more of it set up. But a lot of what is left has offsets that break data that is most likely an array into a bunch of single variables, and then the remainder of the array, even though they all should be the same array. But we need to have the last few functions decomped before we can do that, so I'm going to switch back to that and will get the rest of the data put together after.	2024-11-07 09:04:39 -08:00
AlChar	85c7f9d961	Decompile no0 func_us_801D9264 (#1881) ... PSX : https://decomp.me/scratch/rJEtD	2024-11-06 14:11:43 -08:00
Luciano Ciccariello	89f1933811	NZ0 cohabitation (#1871) ... I had this on a local branch. I do not remember why I did not submit it. Main changes: * `EntityRedDoor` ➡️ `OVL_EXPORT(EntityRedDoor)`: while the entity is the same across all stages, their `OVL_EXPORT(RedDoorTiles)` is different * `g_EInitBreakable` ➡️ `OVL_EXPORT(EInitBreakable)`: each stage has variations of the breakable NZ0 is now good to go 👌	2024-11-06 19:51:31 +00:00
H.M. Burger	b978d7e432	Decompile tt_002 func_us_80176504 (#1880) ... The data structure for the ranked lookup table is messy because the PSP version requires it to be a flat array. I'm pretty sure I have a union solution for that so the data tables will at least make sense, but until I can get data import done, we'll keep it like this as it will need to be used like this anyway. PSX: https://decomp.me/scratch/SN6vr PSP: https://decomp.me/scratch/DM13D PSP has a register swap that I couldn't figure out, but is largely a match	2024-11-06 09:13:44 -08:00
Jonathan Hohle	6c0544e1c7	Decompile & Map tt_002 Functions (#1879) ... Decompiles `func_us_80177958` and `func_us_80177F64`. Maps shared `ProcessSfxState`.	2024-11-05 21:49:57 -08:00
AlChar	2765a6eb80	Decompile func_us_80177F84 (#1878) ... PSX : https://decomp.me/scratch/9GOEx I haven't tested if it matches on PSP	2024-11-05 22:22:26 +00:00
Josh Schreuder	25f8eb1d91	Decompile no0 Marionette helper functions (#1877) ... I'm continuing work on this enemy with the final unmatched function in this file, and I'll do a clean up of function names + pull in data later once I have a better context over what they are used for. The main Marionette entity function is pretty huge so wanted to get this up first as a starting point. `func_us_801D6254` with help from @gamezter matching both PSX: https://decomp.me/scratch/zYeQa PSP: https://decomp.me/scratch/RgXT3 `func_us_801D6474` matching both PSX: https://decomp.me/scratch/OIS9x PSP: https://decomp.me/scratch/QqPkx	2024-11-05 22:21:43 +00:00
AlChar	1b9e5dded8	Decompile func_us_80176C98 (#1876) ... PSX: https://decomp.me/scratch/oJCYW PSP: https://decomp.me/scratch/Uu6xa Thanks to @Onenutmcgee and @bismurphy who helped me out to get a match on both PSP and PSX. `if ((*((FgLayer32*)&D_8003C708)).flags & (LAYOUT_RECT_PARAMS_UNKNOWN_20 | LAYOUT_RECT_PARAMS_UNKNOWN_40)` For PSX is the only way to load D_8003C708.flags as a word while keeping the order of operations. Co-authored-by: gamezter <gamezter93@gmail.com>	2024-11-05 19:06:34 +00:00
Jonathan Hohle	44e0336463	RBO3 Config Fixes (#1875) ... Some small fixes to RBO3 symbol map and BSS layout.	2024-11-05 08:45:55 -08:00
Jonathan Hohle	77fe7114b4	Remove SOTN Includes from PSXSDK (#1874) ... Removes the SOTN-specific `game.h` include from an SDK file.	2024-11-04 16:47:34 -08:00
H.M. Burger	f317c636b6	Import data tt_002 shared/common (#1873) ... This is just the shared and or semi-common parts of the data. The faerie specific data will come in the next PR, mostly because I ran out of time and will be off for a few days.	2024-11-04 10:18:44 -08:00
H.M. Burger	a8103c8d4f	Decompile tt_002 func_us_80173994 (#1872) ... This function was used all over the code so I just wanted to see what it was. It's a very small utility function that just sets animation data from the animation data array. Matches both PSX and PSP	2024-11-04 00:36:51 -08:00
Josh Schreuder	7ab0220a00	Extract Ouija Table data (#1869)	2024-11-03 12:22:47 +00:00
Josh Schreuder	d8f94dfb96	Decompile no0 EntityFleaMan functions (#1870) ... `CheckFieldCollisionY` / `func_us_801DC64C` with thanks to @mrmidi who had done most of the work here. Matching both PSX: https://decomp.me/scratch/Ga3ax PSP: https://decomp.me/scratch/ki27x `EntityFleaMan` / `func_us_801DC788` Matching both PSX: https://decomp.me/scratch/Vu3Zx PSP: https://decomp.me/scratch/Y8HsL Also extracted the data while I was here. I think this enemy also appears in Olrox so should be able to extract into a shared header later on. --------- Co-authored-by: Aleksandr Shabelnikov <mistermidi@gmail.com>	2024-11-03 11:46:24 +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
Josh Schreuder	95d91584b4	Decompile no0 Ouija Table components sub-entity (#1867) ... Also split into a separate entity file for Ouija Table Matching both PSX: https://decomp.me/scratch/oph7c PSP: https://decomp.me/scratch/MTVot I'll probably extract the data on this one shortly just to round it out	2024-11-02 17:40:36 -07: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
H.M. Burger	5c0a64991a	Decompile tt_002 func_us_80174F0C (#1865) ... This looks like the Faerie's revive you if you die mode (ie, use Life Apple). Apparently there is a sound clip that gets played if you die while the faerie is active and you don't have a Life Apple. I don't believe I've ever heard this clip before.	2024-11-02 00:42:57 +00:00
Luciano Ciccariello	bd6cee2ed6	Run progress dry-run on PRs	2024-11-02 00:33:56 +00:00
Luciano Ciccariello	5bbe6f7cce	Revert "Do not longer use the confusing pull_request_target for the CI" ... This reverts commit 0623959ce0.	2024-11-01 20:23:33 +00:00
bismurphy	f9feecf70b	Decompile PSP DRA file 63C90.c (#1861) ... Decided to tackle this whole file. It mostly matches with the existing DRA, so I've been back-porting the required changes to get the matches. Everything here matches in both. The only issue is the deadstripping, which we still need to figure out. I'm not sure why there's a file split at the end of this PSP file, where there isn't one in the PS1 game. I'll try removing the split once the functions are done on each side of the split. Also adjusted the makefile filter logic so that we only need to give the name of the file, rather than the full path. This makes the file list more concise. If we run into collisions (two files of the same name, in different overlays, which need different optimizations) we can revisit this.	2024-11-01 20:20:37 +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
Josh Schreuder	8dbb75fb78	Decompile no0 main Ouija Table function (#1859) ... Match on both PSX: https://decomp.me/scratch/A79x5 PSP: https://decomp.me/scratch/HJrWp The functions directly after this are related to the sub-entities such as vase and beaker I believe, so I'll decompile those next. Possible this might lead to changes in the extensions I've added here. Think this was my first time adding new extension(s) so let me know if something's wrong there Once all that's done I'll split into a separate Ouija Table file with all the related code.	2024-11-01 19:38:44 +00:00
H.M. Burger	55a696cba9	Decompile tt_002 func_us_80176178 and func_us_80175DBC (#1863) ... A lot of these update functions are code revolving around the faerie using items (which makes sense, that's what the familiar does). This means that these update functions share a lot of code. In fact, entity update steps 0, 1, 4,5,6 are mostly shared between the update functions. Steps 2 and 3 vary in what they do exactly, but tend to pull from common ideas. Combined, they look like they do the same concepts for each function. Data structures are slightly different, but all are used in similar methods. I will add an enum for these steps as I get farther along. But there is still some steps that I am not sure of and I'd rather keep it like it is for now, and do it when I'm either done with decomp or at least done with the base update functions. There is a lot of refactoring that I'll do when I'm closer as well. Worth noting that I believe all of these functions are mostly a PSP perfect match meaning we may be able to add this to PSP build fairly easily once the decomp is finished. This PR has 2 functions. Step 2 and 3 are really the only differences. func_us_80176178/func_psp_092EAC80 PSX: https://decomp.me/scratch/axD5C PSP: https://decomp.me/scratch/3KWit func_us_80175DBC/func_psp_092EA6F0 PSX: https://decomp.me/scratch/Rx6yJ PSP: https://decomp.me/scratch/youUM	2024-11-01 18:17:51 +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
bismurphy	a860e7bc49	Decompile PSP DRA SetPrimRect (#1860) ... I picked a random function from PSP and figured out what it was in PS1. Turns out it was one of these two. `SetPrimRect` and `SetTexturedPrimRect` happen to be pulled into a .h file already. The source code there required a line swap to get a PSP match. Interestingly, these are compiled with -O4. I'm guessing for now that functions with -O4 are grouped together into the same .c files (that is, some .c files were compiled with -O4, rather than some functions being -O4). Therefore, I adjusted the PSP makefile so that we can specify what object files use -O4. This is the same approach I used in Aironauts when I found some functions being GCC 2.7 and some being 2.8. Not sure if this will be the strongest approach long term, but I think that will become more clear as we begin crunching through PSP.	2024-11-01 12:32:23 +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
H.M. Burger	c82d3726cb	decompiling func_us_801753E4 (#1856) ... D_us_80172BE4 seems like it should be an array of a struct, but the psp version uses math to move around the single dim array of s32. I messed with it, but couldn't figure out a way to do it where we kept all the left shifts in the psp version. No condition for loop is weird, but it's what is needed. (or a while(1), but I really don't like that either). PSX: https://decomp.me/scratch/r7VMm PSP: https://decomp.me/scratch/zX0Ly	2024-10-31 20:34:48 +00:00
Jonathan Hohle	74960176e9	Add Include Guards for All Headers (#1855) ... This is part of the `game.h` refactor from a few months ago. I'm parting those changes out into discrete PRs.	2024-10-31 20:27:49 +00:00
H.M. Burger	b481dc211f	tt_002 func_us_80175730 and func_us_80175A78 (#1854) ... These are essentially dupes of each other, but uses a slightly different offset for a u8 counter and params for the create factory and event functions. PSX: https://decomp.me/scratch/ghT05 PSP: https://decomp.me/scratch/lts6D	2024-10-31 19:27:20 +00:00
Josh Schreuder	43a75ee47c	Add linter for g_Player.status (#1849)	2024-10-30 21:02:00 +00:00
AlChar	7e052648cd	decompile func_us_801D7C20 (#1848) ... This is my first PR to this project, started with a small function	2024-10-30 09:33:30 -07:00
H.M. Burger	24d70e9823	decompiling func_us_80177AC4 (#1847) ... Full match both PSP and PSX PSX: https://decomp.me/scratch/iF9Ax PSP: https://decomp.me/scratch/bA5Ta I made a comment in the code that it looks like the extension used by this entity is wrong, but I don't have enough context to build a "correct" one yet. We'll have a better idea as we get more functions decompiled (especially the functions that spawn these sub entities).	2024-10-29 21:41:21 -07: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
H.M. Burger	7d285b6d5e	Decompile tt_002 func_us_80174998 (#1846) ... Weird issue with this one. The explicit casts for CalculateAngleToEntity and GetTargetPositionWithDistanceBuffer are required. Decomp.me will compile to the correct code without the casts, but the bit shifts to clear the high side get compiled out with the actual build. PSX: https://decomp.me/scratch/K1ruf PSP: https://decomp.me/scratch/x5w17	2024-10-29 22:14:30 +00:00
H.M. Burger	35ffeb8314	Decompiling function func_us_80173BD0 (#1843) ... The 2nd argument to func_us_80173994 is probably either some flags or needs to be an enum. But I am not sure what they are yet. I'll come back to clean them up once I get that function decompiled.	2024-10-29 09:28:17 -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
Aleksandr Shabelnikov	09f48e6f0c	RBO3 st_common deduplication (#1842)	2024-10-28 22:21:19 +00:00
Aleksandr Shabelnikov	c5046ebf2b	Some RBO3 deduplications (#1841)	2024-10-28 20:05:47 +00:00
Jonathan Hohle	07081331b8	Decompile rbo3 func_us_801923DC and func_us_80192D64 (#1839)	2024-10-28 11:37:35 -07:00