Conversation
Report for Shield (00bdde3 - fe3bad7)📈 1 improvement in an unmatched item
Report for RZDJ01 (00bdde3 - fe3bad7)No changesReport for RZDP01 (00bdde3 - fe3bad7)No changesReport for GZ2J01 (00bdde3 - fe3bad7)No changesReport for DZDE01 (00bdde3 - fe3bad7)No changesReport for GZ2P01 (00bdde3 - fe3bad7)No changesReport for GZ2E01 (00bdde3 - fe3bad7)No changesReport for RZDE01_00 (00bdde3 - fe3bad7)No changesReport for ShieldD (00bdde3 - fe3bad7)No changesReport for RZDE01_02 (00bdde3 - fe3bad7)No changes |
|
As a thought, instead of all these macros, I could instead replace the macros with typedefs, something like |
|
i prefer the macros personally |
|
Do you think there are too many casts in this pr? I replaced all the |
| #define MULT_S32(x, y) MULT_VAR_CAST(x, y, s32) | ||
| #define MULT_U32(x, y) MULT_VAR_CAST(x, y, u32) | ||
|
|
||
| #define ADD_ANGLE(x, y) ADD_S16(x, y) |
There was a problem hiding this comment.
there's data in daObjProp_c::execute called ADD_ANGLE, so it might be better to use a different name to not conflict. what about ANGLE_ADD or ANGLE_INCR? and similarly ANGLE_SUB or ANGLE_DECR, and ANGLE_MULT
There was a problem hiding this comment.
I can do that, but there's no conflict currently. By defining the macro to take parameters, ADD_ANGLE[] does not become a macro and is instead resolved as a variable name.
There was a problem hiding this comment.
i think in general i just prefer the TYPE_METHOD naming style rather than opposite. but its just a personal preference
2 participants
I went through and cleaned up a lot of the s16 casts, but let me know if I went a little overboard. I tried to differentiate s16s from angles, don't know how necessary that was, but it was easier to fix as I went along.