fatal error: 'sound/sequences_offsets.inc.c' file not found #include "sound/sequences_offsets.inc.c"

[ThePlayerRolo]

as in title

happens whenever I try to manualy compile it for my intel Mac on Macos 10.15.7

Expected to fully compile it with no issues.

Desktop (please complete the following information):

• OS: MacOS X
• Browser: Chrome
• Version: 10.15.7
  I did all the steps on this: https://github.com/coop-deluxe/sm64coopdx/wiki/Compiling-(macOS-Intel)

[AgentXLP]

Did you clone the repo fresh or did you git pull the changes?

[ThePlayerRolo]

I used the commands: git clone https://github.com/coop-deluxe/sm64coopdx.git
cd sm64coopdx

[ThePlayerRolo]

is there something else I had to do?

[ThePlayerRolo]

I'll try downloading the zip.

[ThePlayerRolo]

I downloaded the zip and used that but it still didn't work with the same error

[ThePlayerRolo]

followed this btw: https://github.com/coop-deluxe/sm64coopdx/wiki/Compiling-(macOS-Intel)
Haven't done libjuice bc I don't know how to get that file.

[ThePlayerRolo]

I tried all three avaible main/stable versions and none of them worked.

[AgentXLP]

I used the commands: git clone https://github.com/coop-deluxe/sm64coopdx.git cd sm64coopdx

I see. @EmeraldLoc do you have any mac wisdom here?

[Flower35]

Hi. I've had the same problem both on MSYS2 (environment targeting Windows) and on Linux (targeting Linux or cross-compiling for Windows).

I think there is some bug in the Makefile with how the dependencies are listed for 'sound/sequences.bin' and for 'sound/sequences_offsets.inc.c', but I could not quite figure it out yet.

---

As I mentioned in a similar issue before:
#162 (comment)

My workaround was to enter this in to the shell:

$ make build/us_pc/sound/sequences.bin

which resolves the issue with sound/sequences_offsets.inc.c.

then you can go back to the regular project building process:

$ make

[robertkirkman]

Compare for reference Dominicentek's runtime vanilla ROM sounds extraction implementation which, while not absolutely perfect (readability issues, but within the realm of what I consider to be open source), is completely unaffected by this type of problem.

I also consider it possible, with careful enough refactoring, to isolate his sounds extraction method's code from the rest of his code and merge that into any sm64ex fork, without interfering with the extraction methods used for anything else that isn't sound.

[Isaac0-dev]

@robertkirkman are you sure this implementation you sent actually does extract sound correctly? it seems this implementation doesn't fully extract all sm64 assets from the rom, and in some cases (like the sm64 demo data) its simply disabled as a solution

[robertkirkman]

@robertkirkman are you sure this implementation you sent actually does extract sound correctly? it seems this implementation doesn't fully extract all sm64 assets from the rom, and in some cases (like the sm64 demo data) its simply disabled as a solution

I've been playing it in this and neither I nor other users have noticed any sounds missing. That is a good point though because it's true that Dominicentek's overall extractor missed several non-sound assets, like the demo data you mentioned but also a few textures, so it's hypothetically possible there could somehow be a sound missing from it that nobody has noticed yet. EDIT: not possible. Dominicentek's run-time code extracts identical sound asset files to those that vanilla sm64ex does at build-time. See below.

[Isaac0-dev]

if the sound assets aren't being extracted correctly, but do function correctly in game, that likely means the sound data is contained with the game binary, defeating the point of the sound extraction in the first place.
but my question is whether or not this implementation does actually extract the sound correctly.
from what i can see, this only extracts textures from the rom

[robertkirkman]

if the sound assets aren't being extracted correctly, but do function correctly in game, that likely means the sound data is contained with the game binary, defeating the point of the sound extraction in the first place. but my question is whether or not this implementation does actually extract the sound correctly. from what i can see, this only extracts textures from the rom

no, the sound data is not contained within the game binary, which careful review and testing of Dominicentek's source code can prove beyond all doubt.

The sound data is extracted from the ROM at this line which he added in a later commit. Sorry for not linking every single commit he made in the process of writing his implementation, but I don't blame you for being unable to identify on your own the fact that Dominicentek's binaries do not contain copyrighted sound data, due to the readability issues with the code.

In that line, the data array contains only ROM-originated data, and this function is not invoked until after the ROM is selected, and as you should be able to clearly see after spending enough time studying it, the only data this function can possibly return is data from offsets into the array that contains only ROM data.

The rest of the required proof is pretty obvious.

• ROM file is loaded from filesystem to the stream variable here
• stream variable is copied into the first data buffer here
• pieces of data are stored into an std::map mio0 here
• those pieces are retrieved from mio0 and stored in buf here
• buf is passed to file_processor_apply() and the returned pointer stored in out_data here
• The data pointed to by out_data is written to filesystem here

Note that while tracing the origin of the file_processor variable, you would encounter some extremely huge arrays, but the implementation of file_processor_apply() proves that file_processor is only used as indices into the data array that buf is passed to as the first argument to file_processor_apply() , and the stepthrough I outlined above proves that the data variable there contains purely ROM-originated data that isn't present prior to running the program.

The vector named assets, which you can see used during population of the std::map mio0 linked above, can be found in this large file, where you can see that it contains purely filenames and addresses of various files extracted during this process, including the sound files: sound_data.ctl, sound_data.tbl, sequences.bin and bank_sets, which are listed at the end of the vector definition.

[robertkirkman]

@robertkirkman are you sure this implementation you sent actually does extract sound correctly? it seems this implementation doesn't fully extract all sm64 assets from the rom, and in some cases (like the sm64 demo data) its simply disabled as a solution

What's more, not only that, but it can be objectively, conclusively proven that Dominicentek's code is not failing to extract any sounds that sm64ex's original build-time extractor isn't also missing, due to the resulting extracted files being identical. Observe:

$ git clone --recursive https://github.com/sm64pc/sm64ex.git sm64ex-orig
Cloning into 'sm64ex-orig'...
remote: Enumerating objects: 15365, done.
remote: Counting objects: 100% (5886/5886), done.
remote: Compressing objects: 100% (1787/1787), done.
remote: Total 15365 (delta 4474), reused 4100 (delta 4099), pack-reused 9479
Receiving objects: 100% (15365/15365), 19.99 MiB | 5.15 MiB/s, done.
Resolving deltas: 100% (7804/7804), done.
$ cp baserom.us.z64 sm64ex-orig/
$ cd sm64ex-orig/
sm64ex-orig $ EXTERNAL_DATA=1 make -j32 >/dev/null 2>&1
sm64ex-orig $ md5sum ~/.local/share/sm64ex/res/sound/* # extracted using Dominicentek's code
34dec325df1b21c27d5f5e219ac7b726  /home/tacokoneko/.local/share/sm64ex/res/sound/bank_sets
074f4d4f6696df28f6d7548f7fc4bb26  /home/tacokoneko/.local/share/sm64ex/res/sound/sequences.bin
60cf5c48e0f6c2a47690c13d2bb695c6  /home/tacokoneko/.local/share/sm64ex/res/sound/sound_data.ctl
3dd8b941b3a3c01ff2683d20a07b0223  /home/tacokoneko/.local/share/sm64ex/res/sound/sound_data.tbl
sm64ex-orig $ md5sum build/us_pc/sound/bank_sets # extracted by sm64ex's build-time extractor
34dec325df1b21c27d5f5e219ac7b726  build/us_pc/sound/bank_sets
sm64ex-orig $ md5sum build/us_pc/sound/sequences.bin # extracted by sm64ex's build-time extractor
074f4d4f6696df28f6d7548f7fc4bb26  build/us_pc/sound/sequences.bin
sm64ex-orig $ md5sum build/us_pc/sound/sound_data.ctl # extracted by sm64ex's build-time extractor
60cf5c48e0f6c2a47690c13d2bb695c6  build/us_pc/sound/sound_data.ctl
sm64ex-orig $ md5sum build/us_pc/sound/sound_data.tbl # extracted by sm64ex's build-time extractor
3dd8b941b3a3c01ff2683d20a07b0223  build/us_pc/sound/sound_data.tbl
sm64ex-orig $ 

Note that, at least to me, the EXTERNAL_DATA=1 codepath specific to audio appears to be trivial to separate cleanly into a standalone patch that could be paired with the EXTERNAL_DATA=0-based codepath that's used by this repository for everything non-audio, without interfering with any non-audio asset extraction.

[robertkirkman]

Oh and yeah my github actions build log objectively proving ROM wasn't used as a build-time input to my binary. Kinda might go well hand in hand with the above writeup.

[ThePlayerRolo]

Flower35's idea did work but now there is a new error: src/pc/pc_main.c:311:34: error: parameter name omitted
void* main_game_init(UNUSED void*) {

[ThePlayerRolo]

screenshot

[ThePlayerRolo]

I also tried singling out this for like the previous file with make build/us_pc/src/pc/pc_main.o but no evail same error.

[EmeraldLoc]

@motoo-tobbler Didn't you handle a lot of stuff with old versions of macOS? Can you also review my Makefile changes in the dev branch to ensure I didn't mess up anything with intel?

[ThePlayerRolo]

should I close this?

[AgentXLP]

Well does it compile fine now?

[ThePlayerRolo]

yeah