1168 Commits

Author	SHA1	Message	Date
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
Josh Schreuder	017f90e3cf	Decompile no0 Slinger functions (#1830) ... That's these guys in Marble Gallery  They share quite a bit in common with e_skeleton and e_bone_scimitar, but I decided not to deduplicate these ones at this stage	2024-10-26 11:45:01 +01:00
bismurphy	f05601f103	Eliminate ET_Generic, and ext.stub (#1825) ... The quest is done! This eliminates the ET_Generic, and as a bonus, stub, from the Entity struct. This means no future code will be able to use these as defaults and will have to choose a particular extension, which is nice. As usual, while doing these cleanups I found various duplications to solve and file splits to normalize. Overall the code becomes more and more readable.	2024-10-25 23:56:41 +01:00
Josh Schreuder	93a5c011db	Dedupe EntityExplosionPuffOpaque (#1824) ... A larger dedupe which spans `no0`, `no3`, `np3` and `nz0` I've renamed `AxeKnightDeath` to `CreateExplosionPuff` as it does not seem specific to axe knight. Similarly instead of this entity being named `EntityWargExplosionPuffOpaque` I've renamed to `EntityExplosionPuffOpaque` - this same entity appears to be used for axe knight and merman so far. Also renamed the associated entity extension.	2024-10-25 07:23:33 +01:00
H.M. Burger	13ffb36062	Decompile/decompile tt 002 func us 801746 e8 (#1823) ... PSX: https://decomp.me/scratch/tOtFJ PSP: https://decomp.me/scratch/L20c5 I believe PSP should match. Pretty standard init function. Small difference between PSP and PSX for how it checks the FGLayout flags that I couldn't reconcile together. ~~Line 130 is a hot mess. There is either another Entity appended to the Entity struct, or we have some sort of size mismatch, or this is an artifact of when the original devs may have just copied over a struct and modified it. Definitely building a sub entity. Sizing is very close to entity++, but not quite.~~	2024-10-24 12:51:46 -07:00
bismurphy	c094d3fa89	Decompile NO3 EntityFireWargWaveAttack (#1821) ... The final function in NO3, bringing it to 100%! Having this function required combining some files to remove a file split; I didn't touch those. The only changes to the C code are decompiling this function. Lots of weirdness in this one (`unk5Aplus3`???), but a match is a match, as always :)	2024-10-23 20:09:16 +01:00
Josh Schreuder	96194bad75	Decompile no0 func_us_801C2184 elevator function (#1815) ... Also split all elevator related functions into a separate file https://decomp.me/scratch/I6bgp	2024-10-21 21:31:49 -07:00
Jonathan Hohle	cde3353a32	Decompile RBO3 Functions (#1805) ... Decompiles `func_us_80191438`, `func_us_8019179C`, and `func_us_80192B38`. Imports `func_us_80192020` and `func_us_80192998` from #557.	2024-10-21 17:49:18 -07:00
Aleksandr Shabelnikov	a0449079b7	RBO3 st_update deduplication (#1816)	2024-10-21 19:50:46 +01:00
bismurphy	f47d71b6a4	Eliminate generic.unk80 (#1812) ... Another member of Generic is no longer used in the repo. As usual, I did some other small cleanups while I was doing these. One is that I noticed the Blood Skeleton (EntityBloodSkeleton) was in entity_bloody_skeleton.c (notice the **blood** versus **bloody**). I removed the "bloody" ones (which likely carried over from Bloody Zombie). Some weirdness with EntityOwl, so I marked that down in its Ext member for someone to study later. Otherwise, nothing very big in this one honestly.	2024-10-21 19:48:38 +01:00
Josh Schreuder	636d521c4f	Decompile a couple of no0 clock room functions (#1813)	2024-10-21 09:18:44 -07:00
Josh Schreuder	0699def0d3	Dedupe no0 clock room entities (#1808)	2024-10-19 15:27:44 -07:00
bismurphy	c0ced0bb2b	Eliminate ext.generic.modeS8 (#1806) ... More cleanup of removing uses of particular members of `ET_Generic` in order to avoid using Generic in the long term. We have some pretty obvious duplication between NO0 and CEN with the elevator that goes between the two stages (makes sense), but I think we will probably want to get NO0 decompiled through copy and pasting between the stages, and then see about proper dedupes. This PR is pretty small, not too many existing uses of this member :)	2024-10-18 20:36:47 +01:00
bismurphy	f2db23f5f9	Gigantic cleanup PR - remove generic.unk84; dedupe NO3/NP3 (#1802) ... This is a ton of material - my apologies. I started by removing uses of generic.unk84 from the repo, by either creating new `Ext` members, or making entities use the existing ones. Once I got to doing this on NO3 and NP3, I got frustrated by needing to make the same changes on both overlays, so I decided to de-duplicate them and then just remove generic.unk84 from the de-duplicated single set of code. This includes some importing of data, some changes to functions to make them match on PSP, etc. Lots of little changes to cleanup. But no new decompilation in this PR. All just cleanup to rewrite things to be more neat.	2024-10-18 19:16:10 +01: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
bismurphy	e95ccd89af	Decompile NO3 EntityWarg (#1792) ... Nice one to have finished! Ran into this in the middle of my current big project of unifying NO3 and NP3. Required a file split due to its weird rodata in the local "rect" variable. Big NO3/NP3 PR should be coming next, unless I run into another blocker like this one.	2024-10-17 20:02:21 +01: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
H.M. Burger	77cade4efe	Finishing refactor for tt_000 ET_Bat and updating game api call (#1793) ... updating global api function func_8011A3AC with a better name. It fetches the current familiar stats from the global game variables and will also fetch an attack descriptor if ID is provided. Refactoring names for ET_Bat that I forgot to update in my last PR. Remaining unkXX vars appear to be unused. Adding enum for g_SpellDefs table. Some familiar attacks appear to be in that table as well as Alucard's spells. Some do not such as the bat's fireball.	2024-10-16 11:26:54 -07:00
Josh Schreuder	ce0495570d	Dedupe no0 nz0 e_skeleton (#1790)	2024-10-15 11:32:20 -07:00
H.M. Burger	d9b594c0c5	Refactor/renaming in tt 000 part deux (#1789) ... Finished renaming tt_000. Code is actually pretty readable. I may have gotten a little verbose with some of the variable names, but there is a bit of redundancy/crossover between the different sub entities.	2024-10-15 11:21:51 -07:00
Josh Schreuder	eb9f367cc2	Dedupe no0 nz0 e_magically_sealed_door (#1788)	2024-10-14 09:23:18 -07:00
Luciano Ciccariello	19c3b482e4	Replace g_HeartDropArray with PrizeDrops (#1787) ... I discovered that `g_HeartDropArray` was always very weirdly used in overlays such as WRP, CEN and DRE where there are no prizes dropped from breakable objects. This lead me to discover that every overlay has a prize array that describes what items to drop. But for WRP CEN and DRE since the array has length zero, the symbol overlaps with what comes right after. The array is also different for every overlay. The array will be renamed as `OVL_EXPORT(PrizeDrops)`. This PR aims to adjust such array in all overlays: * [x] CEN * [x] DRE * [X] ~MAD~ cannot be moved * [x] NO0 * [x] NO3 * [x] NP3 * [x] NZ0 * [X] ~ST0~ not existent * [X] WRP * [X] RWRP * [x] MAR	2024-10-14 01:06:52 +01: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	56be6ef334	OVL_EXPORT RedDoorTiles (#1784)	2024-10-13 18:26:12 +01:00
Luciano Ciccariello	32615eafb7	Refactor entity init arrays (#1781) ... Standardize names, plus give proper names to almost all the imported EInit arrays	2024-10-13 12:42:25 +01:00
Josh Schreuder	771594c552	Dedupe no0 and nz0 EntityAxeKnight shared code (#1780) ... * Moved `entity_axe_knight` code from `nz0` into shared header * Dedupe `no0` with shared header * Split and extract `no0` axe knight data	2024-10-12 23:29:52 -07:00
H.M. Burger	73030b2b5b	Refactor/Naming for tt_000 (#1775) ... Refactoring tt_000 for naming functions and variables. May have to touch tt_001 for some bits as I come across similar patterns. This is about the half way point of refactoring tt_000. A lot of the pseudo-shared logic and variables between this and tt_001 are done. Most of what is left is bat entity specific behavior.	2024-10-12 21:48:13 +01:00
Luciano Ciccariello	f015a76577	Import w_037 data and normalize weapon palette (#1777) ... This PR also allows to being able to import the BSS section by tweaking the linker script	2024-10-11 18:36:59 +01:00