2777 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Luciano Ciccariello	e883d78be3	libgpu sys functions (#1932) ... `D_8002C26C` is the GPU type. zero is the retail GPU from the first PSX model. Non-zero values is used for arcade boards that have 2MB of VRAM instead of 1MB. It is a bit hard to rename the symbols. Normally I would mark them as `static` and give them the original names. But on `main` the `.data` section is shuffled due to some linker silliness . I removed the various `extern const char []` as those strings are now migrated to the functions that owns them.	2024-11-22 19:56:17 +00:00
Aleksandr Shabelnikov	e79cb4eb87	RBO3 create_entity.c dedupe (#1931)	2024-11-22 17:56:49 +00:00
AlChar	ad98d3dd72	Decompile no0 func_us_801D44A0 (#1929) ... PSX : https://decomp.me/scratch/Lv8ln PSP : https://decomp.me/scratch/CACNi This is the update function for Platelord + 3, the entity referenced multiple times in `func_us_801D2A64`	2024-11-22 17:54:32 +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
AlChar	2244619e83	Decompile no0 func_us_801D2A64 (#1925) ... PSX : https://decomp.me/scratch/P02IW PSP: https://decomp.me/scratch/LURHt (not a full match) This was the largest function that hadn't been decompiled, A few things I've noticed: - I had to update `func_us_801D2424` to take `Point32*`s instead of `Entity*`s, making me think that Entity position is probably a Point32 - Point32 probably uses `f32`s instead of `s32`s - `self + 3` is referenced a lot and seems to use a separate extension struct. I named it `ET_UnkPlatelordPlus3` - I made `ET_PlateLord` `unk88` and `unk9C` a separate inlined struct because they are often passed as an argument to other functions.	2024-11-21 19:37:36 +00:00
H.M. Burger	33e3776558	deompiling tt_003 func_us_80172DC4 (#1924) ... Small function. Getting the starts to the demon extension	2024-11-21 15:19:28 +01:00
Jonathan Hohle	286183e5e3	Fix Global g_api References (#1927) ... Struct access instead of global symbols.	2024-11-21 14:38:33 +01: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
Luciano Ciccariello	3809ebf679	Remove Faerie data #ifdef (#1922) ... Simple follow-up to #1913. The `s32*` type (or any pointer type) already aligns with the targeted architecture. So there is no need for a `#ifdef` cc. @Onenutmcgee	2024-11-21 06:51:24 +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
Jonathan Hohle	249cd2ae7c	Support Servants in make-config.py (#1917) ... Adds match targets for servants.	2024-11-19 19:36:37 +00: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
H.M. Burger	a3678181dc	Changing PLAYER_STATUS_UNK40000 to PLAYER_STATUS_ZERO_HP (#1911) ... Simple change. Figured out that UNK40000 is either "Player has Zero HP" or "Player is dead", which is largely the same I think. The Faerie "Life Apple" ability triggers off of this status. Touches a lot of files so I didn't want to put it in my Faerie refactor. Also a small renaming in Faerie that I realized I forgot in my refactor	2024-11-19 05:58:31 +01:00
Josh Schreuder	9927a518b9	Decompile no0 Ctulhu shockwave attack (#1912) ... Planning on doing a cleanup pass over this whole enemy file next and importing data / documenting PSX: https://decomp.me/scratch/0jcyg PSP: https://decomp.me/scratch/n4vUq Thanks to Xeeynamo for help with the UV pointer array	2024-11-18 21:08:39 +00:00
H.M. Burger	d9bd6a6e4d	Finishing refactor of Faerie (#1909) ... For the most part, I think I've got this code all figured out as to what does what and how it functions. The only thing I need to do some more research on is how the animations for using items and how the animation for the Life Apple work. I straight up don't remember how items look when they are being used look and I don't think I've ever actually seen the Life Apple animation. This is probably where I'll leave the refactor for now, but I may come back again and try to figure out some of the animation frames.	2024-11-16 06:18:09 +01:00
Josh Schreuder	00399edda7	Decompile no0 Ctulhu fireball attack entity (#1910) ... `func_us_801DA488` / `EntityCtulhuFireball` PSX: https://decomp.me/scratch/aCOVv PSP: https://decomp.me/scratch/QYpzQ	2024-11-16 05:00:29 +01:00
Josh Schreuder	d646cd1a17	Decompile no0 EntityCtulhuDeath (#1907) ... Little'un PSX: https://decomp.me/scratch/qOMdH PSP: https://decomp.me/scratch/wgU6e	2024-11-16 00:05:06 +00:00
Josh Schreuder	fa08821104	Import no0 Skelerang data (#1906)	2024-11-15 19:49:10 +00:00
H.M. Burger	2503ab71fb	Refactor and cleanup for TT_002 (#1904) ... This is mostly just the low hanging fruit that I kind of already had a good handle on. The rest of the refactoring is going to take a little more digging in and probably some running the game in a debugger to figure out what's going on. I think the update for D8 and D9 are for the "hidden path" mode where the Faerie tells you to try to destroy a wall. DA,DB, and DC i think are actually yousi code for performing the "song". But I'm not sure on any of that. DD and DF are for the sub entities created when using an Item. I think they should use a different extension, but still need to dig into that more.	2024-11-15 19:37:13 +00:00
AlChar	17aa8803e7	Decompile no0 func_us_801C2E7C (#1905) ... PSX: https://decomp.me/scratch/GI3l2 PSP: https://decomp.me/scratch/lZzxL Thanks to @bismurphy for help getting a match on PSP	2024-11-15 19:17:08 +00:00
Luciano Ciccariello	b14f6dbbf4	Disable i686 from CI (#1908) ... Temporarily get rid of the following error triggered by the current Ubuntu 24.04 agent: ``` The following packages have unmet dependencies: libglib2.0-dev:i[38](https://github.com/Xeeynamo/sotn-decomp/actions/runs/11857786607/job/33047039313#step:3:39)6 : Depends: libglib2.0-dev-bin:i386 (= 2.80.0-6ubuntu3.1) Depends: libglib2.0-dev-bin-linux:i386 (= 2.80.0-6ubuntu3.1) E: Unable to correct problems, you have held broken packages. ```	2024-11-15 19:16:30 +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
AlChar	fe8c58f3a1	Decompile no0 func_us_801CCAAC (#1903) ... PSX : https://decomp.me/scratch/ATsZa I started off with @JoshSchreuder first attempt : https://decomp.me/scratch/Cji94 While I was at it I also updated the conditions in `UpdateBirdcages` to make them clearer	2024-11-14 20:22:20 +00: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	755b0f7e21	Decompile no0 func_us_801D7DAC (#1901) ... PSX : https://decomp.me/scratch/WCc3T PSP: https://decomp.me/scratch/9Um4e I had to convert `Entity.attackElement` to u16 to get a match and it didnt break anything. Let me know if I should revert that and find another solution	2024-11-14 20:10:54 +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
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