1195 Commits

Author	SHA1	Message	Date
Aleksandr Shabelnikov	e79cb4eb87	RBO3 create_entity.c dedupe (#1931)	2024-11-22 17:56:49 +00:00
Josh Schreuder	ff4e1baf0f	Decompile no0 EntityDiplocephalusFoot (#1928) ... PSX: https://decomp.me/scratch/4UL86 PSP: https://decomp.me/scratch/FAeQw	2024-11-21 20:09:56 +00:00
Luciano Ciccariello	fc91e63a90	Rename LoadClut2 to LoadClut (#1923) ... The function name is mislabeled. `LoadClut2` really exists and it was introduced in PSY-Q 3.5, but it only loads a row of 16 colors into the VRAM. The implementation we have at [src/main/psxsdk/libgpu/ext.c](https://github.com/Xeeynamo/sotn-decomp/blob/master/src/main/psxsdk/libgpu/ext.c#L31) loads 256 colors though, which matches the implementation of `LoadClut`. From `PSX/CHANGE_E.TXT` in the PlayStation Programmer Tool - Runtime Library Version 3.5: ``` LoadClut2 Loads Clut for 16 colors. Syntax u_short LoadClut2(u_long *clut, int x, int y) Arguments clut Starting address of the texture color x, y Destination frame buffer address Explanation This function loads the texture color data(CLUT) starting at the address specified by "clut" to the frame buffer(x, y) and then calculates CLUT ID for the texture CLUT just loaded. Return Value CLUT ID for loaded CLUT Remarks This function transfers the CLUT data of only 16 colors. ```	2024-11-21 13:51:50 +01:00
H.M. Burger	eee73de42a	Decompile tt_003 func_us_801744CC and func_us_80176564 (#1920) ... Very similar to a combination of the Faerie and the Bat.	2024-11-20 19:28:11 +00:00
H.M. Burger	287be8c61d	Remaining Dedupe for tt_003 (#1918) ... I think this is the last of the dedupes that are available right now.	2024-11-20 07:22:37 +01:00
bismurphy	b1c617a1dd	Finish a .c file for DRA PSP (#1914) ... More functions, lots of them are direct copies of the existing ones, or just tiny tweaks away. No de-duping at this stage since things are still pretty different.	2024-11-19 19:24:27 +00:00
H.M. Burger	1148580550	Adding Demon servant overlay (#1915)	2024-11-19 18:29:23 +01:00
H.M. Burger	ceb671f716	Adding Faerie to CMakeLists (#1913) ... Adding Faerie to CMakeLists Seems like SFX not working, but Faerie at least loads. ~~Possibly also an issue with with the g_Entities array as the wings should occupy g_Entities[5] (set up in line 550 of Faerie.c), but they don't seem to either load or update (unsure which).~~ Seems this was either a graphical bug or something transient as the wings seem to work now... I'm not particularly interested in debugging this issue at this time, so if you'd rather I abandon the PR, I can do that too. There wasn't a lot of change.	2024-11-19 15:23:05 +01:00
Josh Schreuder	fa08821104	Import no0 Skelerang data (#1906)	2024-11-15 19:49:10 +00:00
Josh Schreuder	dfea3429ae	Decompile no0 Skelerang entities (#1900) ... ~~Planning on giving this a tidy up when I import data and do some analysis in debugger so I'll fix up some of the naming then unless there's something glaring that sticks out here.~~ `func_us_801D191C` / `EntitySkelerangUnknown` was previous decompiled but slightly updated here for PSP match: https://decomp.me/scratch/8lEH0 `func_us_801D20A4` / `EntitySkelerangBoomerang` matching both PSX: https://decomp.me/scratch/SMgwb PSP: https://decomp.me/scratch/WFD0w `func_us_801D191C` / `EntitySkelerang` matching both PSX: https://decomp.me/scratch/BUkq2 PSP: https://decomp.me/scratch/OYg4D Thanks to Discord gang for helping with some PSP stuff here ^	2024-11-15 02:57:00 +01:00
bismurphy	0729f18d0b	Next funcs on psp DRA (#1902) ... I noticed that my previous function, `DebugShowWaitInfo`, is actually the first function in the C for ps1. To me, this suggests that all the prior code in PSP (there is a pretty large amount of it, about 0x18000 bytes) is PSP-exclusive. Therefore, I adjusted the file splits to start a file on that function. Then I did the next function, `DebugInputWait`. After that is a bunch of debug screen capturing functions. These appear to be unused (presumably used in development but not in the final game code) and therefore I assume they are missing due to deadstripping. Since we know that's an issue on PSP, I decided to make a dedicated macro to flag that code is being removed due to deadstripping - this way, if we get deadstripping to work as intended, we don't have to look through every VERSION_PSP usage to identify what is dead code, versus altered code. We can just find all the uses of `PSP_DEADSTRIP` and eliminate them. Leaving it there for now, will continue working through DRA in future PRs.	2024-11-14 20:14:40 +00:00
AlChar	dd2fca6d6d	Import no0 e_init data (#1898) ... This is my first time importing data.	2024-11-14 14:56:26 +01: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
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
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
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
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	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
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
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
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
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
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
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
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
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
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	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
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
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
bismurphy	1554483f24	Decompile ST0 EntityBackgroundVortex (#1838) ... Another one down! In terms of the sequence of functions, this is the last function in the ROM for ST0. The split between C and BSS was off by one (the NOP after the RA for this function was being pulled in as part of the 00 bytes in BSS), so I had to make some small BSS fixes to get a match. All good now! I believe this leaves only a single ST0 function remaining.	2024-10-27 14:32:20 -07:00
Josh Schreuder	4e9a6c22d1	Decompile a couple of no0 funcs + minor cleanup (#1835) ... Fixed a rodata split in one of the `no0` files Decompiled a couple of small functions While working on this I was having trouble getting a match, looked like `abs` but as usual I was having trouble getting it to work. Turns out I was using `--no-builtin` on decomp.me which breaks `abs` and is why I also had issues on my earlier scratches. So I've cleaned up the `ABS()` macro I added for those as it is not necessary on PSX	2024-10-27 20:02:54 +00:00
bismurphy	d97142f0f7	Decompile ST0 EntityCutscenePhotograph (#1833) ... Well. Oh my god. This function is finally done. It was brutal. I feel like the status bar face of the Doom Guy when he's at 1 HP. Anyway, it's decompiled! What a wild function. ST0 is coming to an end just as the other stages did before it. GTE continues to be a monster, but it's done.	2024-10-27 20:02:05 +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	59d4a40dd9	Decompile ST0 func_801BC5C0 (#1832) ... A very ugly one with a ton of GTE instructions that required fixing M2C errors to get it to work. Glad to have it done! Had to do a file split due to EntityCutscenePhotograph in the same file having rodata that isn't pulled in yet. This uses a few GTE macros which weren't being used before. While I'm at it, I reorganized the GTE macros file to match the order of the functions as used in the SDK's INLINE_C.H file. Doesn't really matter, but the file has some light organization so I figured we might as well match up with it.	2024-10-26 16:18:34 +01:00