Skip to content
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

Make data formats friendlier to external editors #375

Open
kemenaran opened this issue May 24, 2021 · 2 comments
Open

Make data formats friendlier to external editors #375

kemenaran opened this issue May 24, 2021 · 2 comments

Comments

@kemenaran
Copy link
Collaborator

External data editor (like level editors) may need to edit a data file, or even replace it completely. For this reason, data files should be easy to edit programmatically.

I think the project should favor simple assembly for data files (over complicated constants and macros). Richer details can be inserted as comments, which keeps the file readable while making it easier to edit.

For instances, the entities definitions for each room could move from:

Overworld00Entities::
  entity $6, $7, ENTITY_MINI_MOLDORM
  entity $2, $4, ENTITY_HEART_PIECE
  entity $2, $6, ENTITY_CROW
  entities_end

Overworld01Entities::
; snip…

to

Overworld00Entities::
  db $76, $23 ; ENTITY_MINI_MOLDORM, x:6, y:7 
  db $42, $35 ; ENTITY_HEART_PIECE, x:2, y:4
  db $62, $7A ; ENTITY_CROW, x:2, y:6
  db $FF      ; end of list

Overworld01Entities::
; snip…
@Rangi42
Copy link
Contributor

Rangi42 commented Dec 8, 2023

In my experience with Polished Map, high-level macro data files are easier to programatically read and write than raw hex dbs with comments, especially if you want to keep the comments in sync with edited data. Like in your example, a entities_end line would be easier to parse than looking for db $FF (or equivalents db $ff, or db 255, or db -1). (You would at least some parsing, to extract hex/decimal/binary numbers and ignore comments, and at that point you may as well be recognizing custom macros like entity.)

@Xkeeper0
Copy link
Collaborator

Xkeeper0 commented Dec 8, 2023

The other unstated problem with this approach of "just use hex values" is that your editor still has to understand what those hex values mean.

Like, yes, a naïve editor might have an easier time parsing "14 58" than "entity 1, 4, ENTITY_DOORSTOP", but it also now needs to know that 58 = a doorstopper (and also keep that in sync).

iirc the NoDice Super Mario Bros. 3 editor works directly off of the disassembled files (and even includes a built-in assembler for its level renderer). so yeah, probably not the best of ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants