2749 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AlChar	dd2fca6d6d	Import no0 e_init data (#1898) ... This is my first time importing data.	2024-11-14 14:56:26 +01:00
AlChar	a01de6c4a9	Decompile no0 StoneRose seed functions (#1897) ... Decompile smaller StoneRose seed functions func_us_801D7D00: https://decomp.me/scratch/YtL8I func_us_801D8DF0: https://decomp.me/scratch/APfvh func_us_801D8FFC: https://decomp.me/scratch/21YNJ	2024-11-14 00:29:02 +00:00
bismurphy	45bfe61037	Decompile PSP DebugShowWaitInfo (#1899) ... Mostly an inconsequential function, but we can learn a whole lot from this one. 1. Lots more symbols added to PSP. This function touches a lot of previously-unseen things in PSP. 2. This is the first PSP function to print a string. Importantly, PSP puts strings in `data`, not `rodata`! Luckily, the process of pulling them in is simple and easy, as demonstrated here. 3. I modified the Makefile for the -O4 stuff. At this point I think DRA is `O4` and all the overlays are `O0`. We can always make the logic more complicated later if we need to. 4. We discovered a discrepancy in the size of DR_ENV on PSP. I suspect we will have more SDK differences, but we will find them function by function. I decided to set the size in a variable so that we can put all the version differences at the top of the file, instead of them being more scattered. I think that's it!	2024-11-13 18:06:22 +00:00
H.M. Burger	a91c2acd3c	Data Import tt_002 (#1896) ... Importing the remaining data for tt_002 Importing sbss data Adjusting the data files The data except for the servant_events data is all unique to the faerie. I suppose all the data could be put in 1 file, but I had it split up because ghost and bat shared a significant amount of data. ~~D_us_801724CC[] should actually be an array of Unkstruct_801724CC; however, that doesn't match because it's on a 2 byte barrier and the compiler wants to align it to 4 bytes. I tried #pragma pack and __attributed__((packed)) and a few other things with no avail. So that and the cast to Unkstruct_801724CC in func_us_80177F84 are just going to have to be wonky.~~ This issue was figured out by @Xeeynamo I didn't really do any refactoring beyond what I needed to in order to get the data in. I'll work on that next.	2024-11-13 15:41:34 +01:00
bismurphy	e10458d4b8	Working code-sharing for a file of PSP DRA and main DRA (#1895) ... Had to tweak some file splits, but ultimately I managed to decompile all of the functions in a PSP file, and then line up the two DRA codebases so that PSP could pull from the existing one. Of course, some of the functions also needed tweaking to end up matching on PSP. Glad to be able to prove this is possible in DRA!	2024-11-11 23:53:30 +00:00
Josh Schreuder	6146ed08cd	Split more no0 enemy entities for Ctulhu and Stone Rose (#1893) ... This should be all of the enemies identified and split for no0 now I think. Also fixed an incorrect split for Slinger	2024-11-11 23:50:48 +00:00
Mark Street	38fb2600ef	Migrate rodata for dra_psp (update mwccgap) (#1894)	2024-11-11 20:16:36 +00:00
AlChar	4fa94a2862	Decompile no0 func_us_801D2424 (#1892) ... PSX : https://decomp.me/scratch/gg59Z PSP : https://decomp.me/scratch/KWgo1	2024-11-11 18:24:31 +01:00
Josh Schreuder	319eed124b	Split no0 Diplocephalus / Plate Lord / Skelerang entities (#1891) ... Researched this via debugger I think splitting these out in advance should hopefully make the decompilation efforts more straightforward later wrt naming / working out what code is doing	2024-11-10 21:48:37 +00:00
AlChar	e95e97c1b0	Decompile no0 func_us_801D8150 (#1888) ... PSX : https://decomp.me/scratch/RAzGU	2024-11-10 10:50:08 +01:00
Jonathan Hohle	b48d12ac5a	Decompile TT_002 func_us_80177380 (#1885) ... While this is a pretty straight forward function, `unkA4` appears to be either a pointer to a `s16[3]` or a struct. It's more self-documenting for it to be a struct, but there is one case where it behaves like an array. A cast resolves the match.	2024-11-10 10:40:41 +01: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
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