No longer use asm-processor

[Dragorn421]

Speeds up builds noticeably. time make RUN_CC_CHECK=0 is 20-25% faster for me

asm-processor is still there ready to be used if we ever have more GLOBAL_ASMs to use

Addresses #1719

Changes:

• update ZAPD (for Add option to extract cutscene floats as hex NEstelami/ZAPD#317 )
• ZAPD is passed --cs-float both (extract_assets.py)
• cutscene floats are now extracted as CS_FLOAT(0x42700000, 60.0f)
• z64cutscene_commands.h :

#ifdef __GNUC__
#define CS_FLOAT(ieee754bin, f) (f)
#define CMD_F(a) {.f = (a)}
#else
#define CS_FLOAT(ieee754bin, f) (ieee754bin)
#define CMD_F(a) {(a)}
#endif

• update csdis.py
• add csdis_re.py to reextract committed CutsceneData (using csdis.py)
• add reencode.sh to handle writing EUC-JP source for ido to process (could be done in the makefile directly but would look quite ugly. it is unfortunate ido cannot read source from stdin)
• add bss padding in z_collision_check.c (doesn't match without)

[cadmic]

Is this comment necessary? Hopefully people should not need to do this, and if someone was seriously thinking about re-introducing asm processor they could probably figure out how to invoke it (say by looking at git history)

[Dragorn421]

I didn't touch DEP_FILES which is part of asmproc Makefile logic, I don't want to completely pluck it out so I'd rather document explicitly asm_processor can be used

[cadmic]

Sorry, why don't you want to pluck out the asmproc.d stuff too? Are you expecting people to re-enable asm_processor locally only for dependency tracking?

I'm not sure I like the idea of only "half-heartedly" removing asm-processor, ideally we would delete it from the repo entirely to try to make things simpler. I personally don't think we'll need GLOBAL_ASM ever again, but if that's still an issue, maybe it's better to wait on this change than making the build system more complicated.

[Dragorn421]

This change is a noticeable performance boost for IDO builds so I don't want to post-pone it

I do think we could see GLOBAL_ASMs again in the repo, for example if/when I figure out how to build matching in a non-intrusive way maybe a single function in a file would resist matching and would be global_asm'd

maybe I refactor now which files to run asm-processor on? i.e. ASM_PROCESSOR_O_FILES :=

[fig02]

Not the biggest fan of this macro taking two numbers, its pretty confusing to see two numbers being passed into a macro and only one to be used depending on the context. I tbh would prefer if hex was used in all cases with comments to describe the float representation

I guess this is a solution to the "portability" problem that was mentioned before?

[Dragorn421]

Yeah we have the option to just write the hex as well rather than the macro

Personally I don't mind either

[fig02]

Yeah I mean, I'll take this over what we have now, and if it will be a compromise for those who want float representation to be used sometimes. But I don't think its ideal

[Dragorn421]

changed to "hex"

[fig02]

do the zapd cutscene files have the float representation as a comment? I see the non-zapd ones dont. feel like that is necessary at least for the the cam commands where the floats need to be intelligible

[Dragorn421]

They don't
I can probably PR another "hex-comment" option to ZAPD, sounds simple enough for me to do

[fig02]

alright
I feel like we may have not had enough input on this-- I like just hex, but the macro with dual input might be a good compromise for those who feel strongly about them being in float form

[Dragorn421]

FTR I don't mind changing back

It's not particularly difficult either:

• the macro definitions
• the zapd argument in extract_assets.py
• the similar hardcoded argument in csdis.py
• run csdis_re.py

[Dragorn421]

changed back to "both" (CS_FLOAT(hex, f) macro) after having too much trouble trying to have a tool encode floats on build like asm-processor did

[Dragorn421]

Ready for more review