Consider moving memory addresses to preprocessor macros.

[terry-au]

If it is not a problem with you. I may migrate all of the memory addresses to pre-processor macros so that the project can, at some stage be built for different versions. If you have any objections to this, could you please let me know as I won't begin any work porting your addresses to macros unless you are okay with it. If you'd like any specific naming conventions followed, please also inform me of them, thanks!

[glankk]

The intended purpose of the z64 header was indeed to keep all of the game's data structures and addresses in one place, and to facilitate multi-version support. However, since this project has exclusively targeted version 1.0, and also because of the rapid growth of the number of addresses used, that idea has been left behind. I am in favor of resurrecting the use of the z64 header as was originally intended, and of merging version ports with the master branch, with a few caveats; all development of new features will continue to target version 1.0 without any requirement of multi-version support, since that would hinder ongoing development. If there are volunteers willing to port new features to other versions when needed, support for those versions will be included in subsequent releases; otherwise it will not. For naming, just follow the convention that is already in place.

Let me know if you have any other questions or suggestions regarding this issue. Cheers!

[terry-au]

That seems reasonable.

Just one thing, how would you like to handle things such as items? Would you prefer the macro to define only the memory address, or would you like it to handle the mask and name as well? I think memory addresses will be suitable, I doubt the mask changed between versions, my guess is that it'd simply be offset.

Here's an example of what I have. This is probably the most readable as far as I can guess, having the name of the item hidden behind a preprocessor macro is probably not ideal.

#define z64_input_ptr_addr                       0x8011D730
#define z64_equip_addr_a                         0x8011A66C
#define z64_equip_addr_b                         0x8011A66D
#define z64_equip_addr_c                         0x8011A60E
static struct switch_info equipment_list[] =
{
  {"kokiri sword",          (void*)z64_equip_addr_b, 0b00000001},
  {"master sword",          (void*)z64_equip_addr_b, 0b00000010},
  {"giant's knife",         (void*)z64_equip_addr_b, 0b00000100},
  {"deku shield",           (void*)z64_equip_addr_b, 0b00010000},
  {"hylian shield",         (void*)z64_equip_addr_b, 0b00100000},
  {"mirror shield",         (void*)z64_equip_addr_b, 0b01000000},
  {"kokiri tunic",          (void*)z64_equip_addr_a, 0b00000001},
  {"goron tunic",           (void*)z64_equip_addr_a, 0b00000010},
  {"zora tunic",            (void*)z64_equip_addr_a, 0b00000100},
  {"kokiri boots",          (void*)z64_equip_addr_a, 0b00010000},
  {"iron boots",            (void*)z64_equip_addr_a, 0b00100000},
  {"hover boots",           (void*)z64_equip_addr_a, 0b01000000},
  {"broken giant's knife",  (void*)z64_equip_addr_b, 0b00001000},
  {"biggoron's sword",      (void*)z64_equip_addr_c, 0b00000001},
};

On another note, I think it would be better to have the z64 header included in gz as opposed to the n64 toolchain, mostly because it might mean the toolchain will break gz but also it means that changes must simultaneously be committed and merged in both projects.

[glankk]

Addresses only will suffice for the time being. Your example code looks good. And yes, with the increased use of the z64 header, having it reside in another repository could be problematic. It should be moved to the gz repo.