Checklist for me when I inevitably delve into EA source code in the future to make it basically omnipotent (it’s pretty close as is)
Read data from the rom, or dump it, or something. Save it for future use
Notably, implement repointing through this. Implement through __rom__ definition and external tools
Push current offset onto a stack that can be retrieved later Use of labels in ORG? Or currentOffset? (a la ORG (currentOffset-#0x4 )) Use of labels/CURRENTOFFSET in predefined macros e.g. Signum() Inline text parsing
or at least string literals it already was a feature – String(stuff here)
#incbin to natively use BYTE so the CODE hax is not necessary.
#incbin , but for maps
Spell scripting? idk how it works though Can basically be done with incext; maybe just have runext in the future.
Portraits? #incext PortraitFormatter
when loading a raw, also load an overloaded version of _0xits id Type declaration for disassembling (0xf = Ephraim etc) (but type theory is hard :<)
incpatch: apply ups patches when assembling CUPS
Allow for redefinitions to be warnings rather than errors? Fix that including a file doesn’t close it. Fix ifndef with _FE6_, _FE7_, and _FE8_ automatic definitions.
#namespace / #endnamespace preproc command
Change >> to lsr and make >>> asr Change disassembly to resolve all goto’s before ending at an ENDA/B/etc
_ROM_ defined consstant that passes path to rom.
Get the EAStdLib I put out >.>
(Implicitly, EA should be up to date)
Okay, note to self, when loading a raw, also load an overloaded version of _0xits id.
1 Like
You know Alfred you could just open up your EA and change it from _0x1620 to SOUN yourself, make life a bit easier on you
Or the other way around, I think is what he wants. or make a copy that’s the old code.
TODO: Figure out why FE8 events sometime break when TURN is used a number of times, but then sometimes it doesn’t
(ALIGN 32 issues?)
Seems like Character Based Events in FE8 have to be 8-aligned.
It… it lives… it breathes.
2 Likes
Let’s get to squashing those bugs! Should be fixed.
Thoughts on a suggestion cam gave, for final implementation:
#inctool tool-name-or-mnemonic <param> <param> (etc)
Searches ./Tools for the name or mnemonic in definitions somewhere? Then passes all subsequent parameters on commandline. Writes to the ROM whatever is written to stdout by the tool.
Possibly automatically adds the --to-stdout flag to the program?
Directory traversal might be a bit tricky, depending on how EA is written now.
Guys should we just reprogram bash in EA?
Miiiiiiight be fixed but needs testing
CT075
July 8, 2016, 5:00am
14
personally i far prefer #incext for “include external”
Okay, folks, seems like the source version provided is a bit old. So we may have to fix some bugs that were previously already fixed. Namely:
Used free space starts at 0xE80000
But I have a working version with a few key bugs fixed, as noted before. I may have to apply some optimizations/quality of life performance, but at this rate I can get a holdoff before cheap EA knockoffs written in, idk, python or haskell, emerge.
Next up on the list to add:
Crazycolorz5:
#inctool tool-name-or-mnemonic <param> <param> (etc)
Searches ./Tools for the name or mnemonic in definitions somewhere? Then passes all subsequent parameters on commandline. Writes to the ROM whatever is written to stdout by the tool.
I might decompile the current core.exe and re-edit starting from there. Otherwise we stand to lose quite a few months of NL’s updates to EA, esp since he doesn’t really respond to requests to post source?
edit: reimplemented
Should be added.
Working on adding _0xCODE automcatically for each code loaded.
Things are so lit right now.
1 Like
_0x codes are now automatically included for all raws defined. If you like referring to your codes that way for some reason. (glares at @AlfredKamon )
2 Likes
Good to know I’ll be able to use it as well.
