unregistered wrote:1.) If my sister decides to change something on a screen, long lines of text would be easier to change than a binary file.
But doesn't she find it hard to find what exactly needs to be changed in these huge strings? If the screens are made of metatiles in a grid, she should at least consider to have one hex string for each row, as opposed to one the entire screen. It'll be easier to edit and will not cause problems doe to the emulator's maximum line length.
2.) Takes over twice the space before the game is assembled bc a text hex code consists of 2 bytes/characters and a binary byte takes only 1 byte?
Yes. Not that this is a big deal considering today's typical storage capacity, but still.
And it takes longer to parse while assembling the game because the data is twice as big?
It takes longer because the data is twice as big, and it's read as text, meaning it has to be converted to byte values before they can be written to the output. Again, not a big deal considering today's typical processing power, but still.
the .hex text format will run just well as the binary format inside the NES game (bc they'll both end up in binary format).
Yes, whether you use
.hex,
.db or
.incbin has no impact on the final binary.
Anyway, just consider breaking the giant hex strings into smaller units, such as parts representing rows of metatiles. It will be much more readable and easier to edit by hand. I don't think it's even good programming practice to have insanely huge lines of code in your source files.