-
Notifications
You must be signed in to change notification settings - Fork 48
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
Match and fix all(?) SpriteOAM functions #308
Conversation
} | ||
|
||
// Hacky way of matching functions in menu_input.c AddMenuCursorSprite_, sub_801332C sub_8013470 | ||
#define SpriteSetX_MatrixNumSize0(spritePtr, _x) \ |
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.
Probably can name this one like SetX
(only x is set) and the other funcs can be like "ModifyMatrixNum", "ModifyX" etc (only the relevant bits are modified)
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.
Not a fan of this, because these names wouldn't be clear enough. Especially for someone who is not familiar with these, it may be confusing why there are two sets, and why SetX
modifies also MatrixNum
and X
Seems good |
It's happened. All(or almost all) functions which were non-matching or using registers are finally matching, with easy to follow code.
Note that these have to be macros(which is not ideal, but nothing can be done about it I guess), for this particular case static inlines won't work.
What's interesting is these macros sometimes unroll to code like this
(&sp)->attribX &= ;
which generates different asm(and in this case that's the matching asm) thansp.attribX &=
.