So I ended up mostly killing control flow in the function documentation. Yeah kind of upset how much time I wasted but hindsight is 20/20. I realized that I was spending too much time trying to write control flow when honestly its redundant, the code already explains the how. The point of the separate documentation is to explain the what and the why, something you learn from experience I guess. So from now on I will only add a control flow section when the code is genuinely hard to follow cough cdlib_manager cough.
Moving on from that I think I figured out more stuff about the CD system. So previously I called it a CD API but a more accurate term would be the CD library. Honestly the separation of concerns here was terrible, many game state functions reaching in and doing stuff manually or cd library functions touching the game state themselves. Because I was thinking of a clean CD API I assumed the asset loaders were part of the game manager functions and they just made calls to the CD API to load files. But nope that was the wrong assumption it seems the asset loaders ARE part of CD library and have been renamed accordingly. The library also has functions that loads executables (minigames) and those functions save and restore the game state. I’m not really criticizing though more function calls mean more overhead and more instructions going back and forth from the instruction cache. I just wanted to point out the dichotomy of what I expected vs what I found.
From the library there are 32 functions, 7 of them still have to be properly named, though I appeneded cdlib to their name. For some reason SetPriority which is definitely a Sony library function got put in the CD library boundary, I cant find anything about it in the Sony documentation though so it must be used internally by the SDK.
I have more documentation to work through but with killing control flow I’m hoping it will be faster to get through. One other thing I need to look into is CD XA streaming, specifically the audio streaming done through cdlib_queue_adpcm_play and managed through cdlib_xa_manager that’s really the big CD stuff I’m interested in doing right now. The remaining CD library stuff wont be figured out until I look at the functions for the game state itself. For example It seems like we do pre seeks when near any “doors” that take us to another zone in a level. While I have the seek function reverse engineered there are other functions called by the seek caller beforehand that are in the library that I haven’t reversed engineered. I would need to decompile FUN_8005d100 to figure out the exact mechanism of how it works and that is out of scope for now. I guess I could throw it at Fable 5 since its back side eye. I’m kidding that would suck the fun out of the project.
I also started thinking I may not do the sound engine next after all. Although cool, its a dead end that wont really unlock any non sound related secrets, instead since I reverse engineered how the game loads assets and have the individual files marked to their index in the lookup table I can figure out so much more that hasn’t been documented, like what is the model format ape escape uses, animation format? For example, when an idle animation starts playing pcsx-redux logs a cd read location, I can take that location to find the file then go through the asset table and find in what places it gets loaded and finally what functions consume it. So list of tasks are as of right now:
- Reverse engineer and document CD XA play
- Document asset loading and extract the asset table entries into a csv.
- Do a quick architectural overview of the CD library
- Begin reverse engineering animation format.