2761 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
Josh Schreuder	2acea58d4b	Decompile some small no0 functions (#1840)	2024-10-28 11:25:27 -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
bismurphy	27b9e1fc80	Decompile ST0 EntityClockTower3D (#1837) ... This uses a few separated elements of its Ext; I suspect this corresponds to this Ext being shared across the entities in this file, but that kind of consolidation can be something we do in the future when they're all done. Anyway, another GTE-heavy function completed!	2024-10-27 13:33:57 -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
Josh Schreuder	09782810dc	Refactor some common skeleton bone throw code for clarity (#1834) ... Thanks to sozud for the suggestion Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>	2024-10-26 16:04:57 -07: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
H.M. Burger	d774a146f4	Decompiling tt_002 func_us_801739D0 (#1829) ... PSX: https://decomp.me/scratch/e2PlK PSP: https://decomp.me/scratch/ien4a PSP is close, but has a register swap going on starting at ASM 134-148. v0 and v1 get flipped. I couldn't get that to fix I had to add a 2nd Ext for this overlay as in another function 0x7C is an Entity* and in this function 0x7E is an s16 set to an entity_id. This leads me to believe that this is an update function used for a sub entity.	2024-10-26 11:41:55 +01:00
bismurphy	5d68662c27	Name FLAG_BLINK for entities (#1828) ... This came up a little while ago, I discovered the purpose of this entity flag and we agreed in Discord that FLAG_BLINK would be the best name. This entire PR was a single find-and-replace operation; doesn't seem to have caught any false matches :)	2024-10-26 11:40:16 +01:00
bismurphy	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
H.M. Burger	e690f00952	Decompiling tt_002 func_us_80176B6C (#1826) ... The only hacky/questionable thing I did here was I made a struct for the array. It may just be a multi dimensional s16 array. But having it as a struct allows us to give the values meaningful names. PSX: https://decomp.me/scratch/vKcYn PSP: https://decomp.me/scratch/8RAYb	2024-10-25 07:38:38 +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	8dcb2f130a	Eliminate generic.unk7E with other cleanups (#1822) ... Generic is almost gone! As usual, eliminating those uses also ended up leading me to seeing other functions that needed some cleanup, so I did those too. The common stuff like using Entity* self, making PSP compatible, using proper extensions (lots of RIC was using a fake extension called 80161FF0), and more. Also did a little bit of labeling on the blueprints to hopefully make them more readable. This ended up being lots of changes, but as usual, they're almost all cosmetic.	2024-10-24 18:27:22 +01:00
Josh Schreuder	285cee6c36	Decompile a few no0 functions (#1820) ... Some stuff here I suspect is probably the long clock hallway in Marble Gallery? * `func_us_801C2A34` * PSX: https://decomp.me/scratch/j0986 * PSP: https://decomp.me/scratch/5ARTt * `func_us_801C2B24` * PSX: https://decomp.me/scratch/CI2Sl * PSP: https://decomp.me/scratch/HJY5n ~~(nonmatching - was struggling with the bitmasking here)~~ incorporated Xeeynamo's match And also a function to activate a lever * `func_us_801C2CD8` * PSX: https://decomp.me/scratch/ZtSYV * PSP: https://decomp.me/scratch/YQg6v	2024-10-23 23:54:55 +01: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	64a4a25e60	Decompile no0 func_us_801C27A4 elevator function (#1819) ... Decompiled matching both PSP and PSX PSX: https://decomp.me/scratch/mSJ5k PSP: https://decomp.me/scratch/z05Dt ~~Had to do some rather ugly conditionals for `SetStep` related stuff, if someone can work out a better method that matches both that would be good, I tried a whole bunch of stuff like ternery but no luck~~	2024-10-23 18:01:17 +01:00
bismurphy	5bc549223e	Tweak the handling of the LayoutEntity files created by sotn-assets (#1817) ... This changes the formatting of the generated layout entities in order to make the files (in my opinion) more readable. We do the following: 1. change the types in e_laydef to make the offsets make more sense and reduce casts 2. Break up e_layout into blocks to more easily see where the boundaries between each room's data are 3. Add comments between those boundaries with the offsets, to easily cross-reference e_laydef and e_layout 4. Implement reading of the EntityIDs enum so that entities are listed by ID in e_layout.c to make it easier to identify them 5. Include the overlay's .h file rather than common.h, to allow access to the EntityIDs enum. Sounds like we want to make changes here to move this stuff up to the JSON, so I'll mark this as a draft while we determine the long-term desired functionality. Also, just a heads-up that this is my first time working with Go, so I might have done some bad code practices.	2024-10-23 17:36:31 +01:00
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	7ae3b7fcaf	STNO0 func_us_801CC9B4 decompile (#1818)	2024-10-21 23:32:30 +01: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