-
Notifications
You must be signed in to change notification settings - Fork 817
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
pokecrystal using hardware.inc
#943
Conversation
Using the latest RGBDS master, this builds a ROM perfectly fine and matches up |
Co-authored-by: Rangi <[email protected]>
@ISSOtm Comments added for the changed constants, you're welcome to give it another look |
But does it build with rgbds 0.5.2? Also, I don't think hardware.inc should be a submodule. We used to have one for the |
Couldn't updating hardware.inc be automated using GitHub Actions to prevent those issues? Because it is a submodule it can be updated per-commit to remove those issues @Rangi42 |
@Rangi42 hardware.inc has been directly inserted into the repo, as a sideeffect fixing GitHub Actions' build which uses v0.5.2 so yes, it does build with 0.5.2 |
@ISSOtm Anything else I should do before this is considered complete? |
@coltongit How would you feel about re-adding the constants that were removed and putting them in their own constants file. Possibly |
Using |
Maybe in a |
I'm working on the next iteration getting some of those constants addressed and the new extra constants file completed, two of the unknown registers get names thanks to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Rangi that a lot of the symbols shouldn't have turned into constants; I have pointed out some of the corresponding symbols hardware.inc
provides, but didn't outline them all in a web interface. (A couple of regexes should take care of them.)
The MBC3-specific constants are not provided by hardware.inc
, and this is an important omission that should be corrected upstream; I will open a PR there regarding those.
Finally, hardware.inc
provides not only *B_*
constants containing bit indices, but also *F_*
ones containing the corresponding 1 << *B_*
for convenience. This should significantly reduce the size of many lines (find * -name '*.asm' -exec sed -Ei 's/1 << ([A-Z]+)B_/\1F_/g' {} +
, then maybe a find * -name '*.asm' -exec sed -Ei 's/\(([A-Za-z_][A-Za-z0-9_@#]*)\)//g'
to clean up the leftover (LCDCF_BGON) | (LCDCF_OBJON)
etc. parens).
So the constants have been added in, yet I'm not sure what's causing the build to not match here |
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Please use the "add this suggestion to batch" button, at least. |
…o hardware.inc-gbdev
Co-authored-by: Eldred Habert <[email protected]>
Much better, I'm gonna have to get used to the batch option real quick |
…ecrystal into hardware.inc-gbdev
Closing this since hardware.inc itself is being actively revised, and it's still unclear whether we'll want to use it. |
What's there is already published, I'm not sure how this warrants closing this PR. |
Depends on if |
It won't be "wanted" because the status quo "works fine", but that PR has never been about whether it's wanted, but about harmonization. |
Also simultaneously the reason why it can be reopened if and when it's decided it's actually wanted |
And there we go! gbdev/hardware.inc@23eaa16 This can be re-opened now. |
This draft PR shows what pokecrystal would look like if it was using hardware.inc instead of it's present constants file.This PR now aims to convert pokecrystal to using hardware.inc above what it uses now for constants.
Resolves #914