HUmmmm I wonder if there is any difference in the super sonic behaviour or something more left over in the japanese sa1 or even in the debug sa 1 for GC
Second option. Disassembled sonic.exe, programmed the code in C++, converted the code to ASM, inserted the converted asm code in the end of the program, made the memory call points and branches to the routine in the end of the program, reassembled sonic.exe. It is nothing if an achievement, since SADX was never hacked in a such a way before, up to this point. I aways could, but never saw any potential in hacking SADX if not to just make Super Sonic playable. Since the opportunity arose, might as well show what can be done in SADX. It is an one hour programming. No wonder it isn't perfect. Things will get fixed over time. However, I fixed the "trying to fall through the water" problem as soon as I finished uploading the video, by simply setting the Y speed to 0 when on water.
Me too, but I've always wanted to be able to do that - I had an idea for fully custom level designs that way by having sadx look for extra dlls and then add them to the level list. One could de-compile a stage like the adventure field or chao garden and then add their own level geometry into it, re-compile and then have sadx load the new dll file
I don't know if THIS is possible, but you can definitely copy a pre-existing level, exchange the internal data to insert your own 3d data, or whatever, re-compile, and make the game load for this new data. I'm with the idea to make a program, like, a virtual machine, to run in the background, as you play the game. So to create functions and routines with more freedom, a freedom that actually hacking into the game don't deliver.
The hardest part of custom level geometry would probably be exporting the data into the proper format, as we don't have sega's export tools. edit @ azu: one of my life goals is to make an entire suite of sadx tools.
no, sanik found the docs that outlined the model formats, he also wrote the vt ripper. My contributions are the object lists, the collision and level header data, instanced objects, visibility stuff and the camera format. The model format is fully documented, so one could write an exporter, just not me.
Correct me if I'm wrong, but don't we have the model exporters for multiple programs? I know I have ninja model exporters for lightwave and 3dsmax sitting on my hardrive from the DC devkit.
What version of 3dsmax? Cuz um they might not work perfectly but I'm sure some of the output data could be usable
No importer, only an exporter. It comes with exporter for 3DS Max 2.5 and 3. And whatever version Lightwave was at the time. Also, Dude, you already knew about these at one point, because I remember you asking for a link to those versions of Max on SCARZ years ago. You must have forgot. The way these exporters work, is they export to .NJA. .NJA is Ninja Ascii format. Ninja ascii get's compiled into .NJ. Here's an example file. Link.
Not so much that I forgot, I wrote them off because I don't have 3dsmax 3, and finding it would probably be impossible.
I'm gonna try to find it some time. Also, unrelated, but reading the readme's more, the dev team for the PVR tools are really hard workers. This is the todo.txt.
Well I think sometimes the address jumps around but the technique I used to find the value is to go into a level, scan for 'unknown initial value', then gain some speed to where the camera's FOV goes up, then scan for 'increased value'. Then I'd stop, scan for 'decreased value', then do a spindash and quickly scan for 'increased value' again. I just kept doing that till I found it.
