News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Castlevania: Symphony Of The Night decompilation wanted  (Read 468 times)


  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Castlevania: Symphony Of The Night decompilation wanted
« on: December 20, 2019, 04:17:06 am »
Hello all and to anyone with a good grasp of C, assembly, decompilation, and an intimate knowledge of PSX or Saturn hardware (ahem... Gemini?)

I'm trying to link some technical information together...
My understanding is Esco had a lot of this work done with his GameMaker mod, but I lost that information a long time ago. If anyone could point me in the right direction to a list of ram addresses for player variables such as XY positions, equipment, button presses, enemy positions, etc... would be very much appreciated...

So in short, I would like to have a nice commented documentation of SOTN's game code and game data, preferably in a higher level format like C. Ideally I would like to be able to compile this code successfully back into binaries that can be used by the source systems, and also take some of these game functions in a higher level and put them into personal hobby projects of mine on different platforms. The idea is that I would be working with the game's decompiled source that is original from the game binary - so basically every piece of code that I can pull from this decompilation is original and faithful to the game, which can then be used to measure accuracy in other projects.

This is different from what Esco is doing in that he is recreating his own personal engine inspired from original code. I would like to have the original code documented and commented in an effort that it becomes archived and available for anyone interested in learning more about it or developing hacks for it.

My biggest problem is I'm pretty novice on the PSX and terrible at reading MIPS assembly and making sense of anything. So I am looking for someone who can walk me through some game functions, such as the connected dots between pressing X and beginning a jump, how the game stores your XY coordinates, how it renders your frames as you jump as I understand its actually all in 3d? Really just getting a grasp of the game's engine in general, and then converting each routine to its more readable C counterpart or some kind of IDL. I'm pretty motivated to do this just really overwhelmed on my own, so if you have some spare time you can devote to this send me a PM and I'll help put a castlevania style roast on your dinner table if its any incentive.

December 26, 2019, 06:24:21 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Well nothing new to report really, but because it's the holidays, and a special occasion for myself... For historical records purposes I wanted to make a long winded post tonight...

Eh now that I think about it maybe this should get moved to the off topic threads...?
You can just skip to the bottom if you don't want to read a lot. I don't try and make long posts a habit especially when they don't directly contribute to the subject, but today is a special occasion so here goes.

I just started playing SOTN again... For what its worth, I've known about the Saturn port for a long time, but never really bothered with a Saturn emulator or attempting to play the game. I've only played the Saturn a handful of times in life, it was pretty fun and the games were very memorable. Really amazing system, my understanding is it's even more powerful then the PSX despite being released earlier, and the first dual core console system to hit the market. I wish I had got to play more of it in the past, for some reason I just never got into it, I guess primarily because most of the good games are in Japanese!

Well anyway, for the Christmas holidays I finally decided to try SOTN for Saturn and boy what a great present and idea :D...

Really liked the port Konami did. I know everyone likes to bash it but I was definitely enjoying it. I feel they made a lot of Sega-centric style improvements. The graphics have great taste as they are noticeably different from its PSX counterpart, and with the emulator I was using the scaling seemed to stretch farther and the resolution seemed to be bigger. Watching holy water flames and the life up max potions swirl into existence was kind of a joke but I thought they had great personality and reminded me of what a souped up Genesis looked like. Also, being able to select any character right off the bat was a really welcome addition to someone who has played through SOTN on the PSX so many times that you get sick of having to unlock everything again and again.

Which brings me to Maria. Holy. Heck... Talk about over powered. I got mauled by wargs in the first room again and again only to watch my life bar barely decrease. I just tried to avoid this tonight on the PSP version and was killed twice on accident from only 3 hits both times. In fact I did a Richter run on the Saturn for fun a few days ago and almost no problems at all, went straight to Shaft, and Holy Water crash'ed everything in sight. I just quit the PSP port out of frustration from being killed so many times without saving lol. But I definitely like the differences between the 3 ports, wishing the PSX edition had something extra between the other 2 even if it was just TG16 Maria. I guess that's unfair to expect that though considering it was first released on the PSX. Anyway...

So I'd like to take this time to report my progress, or rather lack of... And give my first impressions of why it's been over 20 years without much progress on the subject matter.

First of... Before this week, I've only played the PSX version fully and the PSP version moderately. Never even beat the PSP version actually, and with how long I've had the emulator PPSSPP and considering I had the Dracula X Chronicles at launch, I have no excuses. Most of the PSX emulators lack a decent debugging system, or one that doesn't crash randomly or from lame reasons like loading save states. The best one I've seen so far is pSX 1.13, which is what I have been using sparingly for the past few years. I really wish pSX Author was able to finish on his emulator as its just really amazing, but I guess not every system has a Byuu who can write a fully functional emulator and debugger and also make it user friendly and bug free to the less talented chaps like myself. Then there is PSX Debugger Ver2. Very useful, but likes to crash often. I don't have the source for it, and its lacking a built in gui for vram support unlike pSX 1.13. I have about 10 different PSX emulators downloaded and while I haven't tried all of them yet, I don't know if any of them are really any good when it comes to solid debugging. Just getting a way to view active memory is a chore and I am having to resort to MemHack which is often unsuccessful in hooking into my system processes, which makes viewing live ram variables even more difficult. Could I improve the source code to some of these other emulators to include more solid debugging features? It's possible, but I'm no expert and it would take some ramp up time to really do it right. If getting any documentation on the PSX assembly is going to happen, I might have to consider this if none of these other 10 emulators can provide decent debugging support. But I've only been on the PSX side of this for less then a day, so I'll know where to go with that when I explore the rest of my options and programs.

Which brings me to PPSSPP. It's been a very stable, reliable, well designed PSP emulator for quite a while now... And it's totally lacking a decent debugger, at least in the Windows port. It has been released with a broken Qt or so I read... For about 3-4 years now. So while I can dump logs, break, and read mountains of confusing assembly, its GUI access to system and game memory... Is all but completely shot. Not even a legitimate search function... I could almost find out where what was stored in ram in pSX 1.13 and PSX_Debugger, eventually I'll be able to make slow progress with those emulators... But PPSSPP, despite being bigger, more robust, and with more emulator features... I couldn't even get started. If MemHack could have at least injected I could have used it's seemingly well designed debugger and found the variables I needed via MemHack, but of course that was total fail, so I'm at a loss for the PSP port right now, because there things I really want to tinker with and document, but it ain't happening unless I start making the changes into my own PPSSPP builds. Which I might have to do, if I can figure out how to at least fix the scrolling functions in the memory window and implement proper searching or cheat code searching functions.

Which finally, and very happily, brings me to Yabuse 0.9.15. I am SOO GLAAAD I decided to try this for Saturn! In addition to being superior in many ways, Yabuse also brings an amazing debugger to the table. I couldn't even get out of software rendering and at 2 cores my PC processor is maxed out only able to handle 50fps, while I can emulate with PPSSPP and only use 5/10% of my processor power, but I don't even care. It's beautiful. It's breathtaking. Yabuse, not even being a fully completed emulator, fully delivers on almost everything I want, with superior debugging. Yabuse actually tracks rendered frames as they are delivered onto the screen, and all the sprites used along with it. Technically pSX 1.13 does this also, but it doesn't give you an option to export the sprites in a BMP format, or deliver it in a bug free fast and efficient window handle that tells you all sorts of attributes on the sprites that are being displayed. And while the memory editor is perhaps a little lacking, it gets the job done and all without the need to use MemHack. I had fun giving Maria infinite summons and hearts in only a few minutes. And while I have yet to actually do any assembly for the SH1 or 2, Yabuse made it look very very easy to work with.

This is somewhat ironic, as I read the main reason behind the PlayStation's success back when it was launched was because it had such good support for it's developers, and rarely did they have to deal with any of their programming in assembly. Where as the Saturn was released with little to no developer support for their dual core system, which often required assembly experts to modify their code by hand to get the separate cores to play together nicely, resulting with many of the developers creating games that could only use one of the two cores on the Saturn.

So long story very short... efficient debugging for PSX emulation looks messy, efficient debugging with PSP emulation could be possible but could also be massive headache inducing to implement, and thank God for Yabuse! I really wanted this to center around the PSX port of the game, and build a usable code base around that, but it's really hard to not tackle this for the Saturn first and forget about the rest.

On a side note, wish they had ported MGS to the Saturn, that would of been awesome.
« Last Edit: December 26, 2019, 06:24:21 am by batshiftman »