Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sonic 3 is hard to work with due to lack of space #27

Open
TorutheRedFox opened this issue Nov 24, 2019 · 11 comments
Open

Sonic 3 is hard to work with due to lack of space #27

TorutheRedFox opened this issue Nov 24, 2019 · 11 comments

Comments

@TorutheRedFox
Copy link

there should be some way to quickly and easily remove unnecessary padding and unused data to make space, or just extend the amount of space available to the game from 2MB to 4MB

@InfernoGear
Copy link
Contributor

Changing org $200000, which is right before EndOfRom to org $400000 gives 4 MB of space.

@TorutheRedFox
Copy link
Author

problem is, Sonic 3 doesn't read anything beyond $200000 anyways

@Chainspike
Copy link

I can also confirm that this is a problem, regardless of whether the EndOfRom pointer is $400000.

@TorutheRedFox
Copy link
Author

it seems to be an issue with cartram
but idk what exactly causes it to behave differently from S3K

@MainMemory
Copy link
Member

I haven't looked at the code, but does S3 ever turn the SRAM access flag off? If you don't turn it off, then the data at $200000+ will always be mapped to SRAM, not ROM.

@TorutheRedFox
Copy link
Author

I don't think it does
hmm

@TorutheRedFox
Copy link
Author

I tried implementing the SRAM access flag switching, but it makes the game crash on file select
but it does make reading past $200000 possible

@Awuwunya
Copy link
Contributor

Maybe we should have an assembly option to enable these SRAM switches just like how S&K does it?

@TorutheRedFox
Copy link
Author

probably
and also make the SRAM switches not make the data select menu freak out

@vladikcomper
Copy link
Contributor

The Data select menu was glitching out due to some code pointers in its objects misrepresented as data. This was fixed in pull-request #28. You may also want to check #29, which fixes even more pointer issues for various in-game objects.

@InfernoGear
Copy link
Contributor

Even with the above pull-requests, there are still two remaining lines of code that break when data is shifted. These lines of code are within 2 of the 4 competition game modes. I've already submitted pull request #30 to fix this issue, so, even though it is not merged yet, I'd recommend applying the changes if you are hacking S3A. Once these are fixed, there should be no more issues with data shifting. All that remains after that as potential issues are the lack of a sound driver disasm and the already mentioned SRAM issues. The SRAM would be the core of this issue, and it should be easily fixable once the data-shifting errors are entirely fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants