Skip to content
This repository has been archived by the owner on Apr 5, 2024. It is now read-only.

Document dumb_*_mod* restrict_ parameter more thoroughly and avoid magic numbers #53

Open
Rondom opened this issue Sep 17, 2017 · 9 comments

Comments

@Rondom
Copy link
Contributor

Rondom commented Sep 17, 2017

The restrict_ parameter could be documented better and one should probably avoid magic numbers and instead either define an enum or preprocessor-constants for the two values.

/* dumb_*_mod*: restrict_ |= 1-Don't read 15 sample files / 2-Use old pattern counting method */
DUH *dumb_load_mod(const char *filename, int restrict_);
DUH *dumb_read_mod(DUMBFILE *f, int restrict_);
DUH *dumb_load_mod_quick(const char *filename, int restrict_);
DUH *dumb_read_mod_quick(DUMBFILE *f, int restrict_);

DUH *dumb_read_any_quick(DUMBFILE *f, int restrict_, int subsong);
DUH *dumb_read_any(DUMBFILE *f, int restrict_, int subsong);
DUH *dumb_load_any_quick(const char *filename, int restrict_, int subsong);
DUH *dumb_load_any(const char *filename, int restrict_, int subsong);
@kode54
Copy link
Owner

kode54 commented Sep 17, 2017

I've added enum parameters for this.

@SimonN
Copy link
Contributor

SimonN commented Sep 18, 2017

What should we pass as restrict_ when we have no idea what specific .mod file we are going to get? I've experimented with a handful of .mod files, and passing 0 seemed best to me.

The old pattern counting looks like backwards compatibility for uncommon .mod files that DUMB can't detect on its own.

@kode54
Copy link
Owner

kode54 commented Sep 18, 2017

0 is fine as long as you're okay with possibly invalid data being treated as a NST module, which has no identifying signature. I tend to write frontend software so it only tries MOD without that flag if the file has one of the known MOD filename extensions.

@SimonN
Copy link
Contributor

SimonN commented Sep 18, 2017

Thanks!

Allegro 5 has always dispatched by filename extension even before calling DUMB. That's because Allegro 5 must decide which library to call in the first place. I've keep this behavior of calling different dumb_*() in Allegro 5 depending on extension, and call dumb_*_mod*() only for .mod, and always with restrict_ = 0. Is that reasonable or should I prefer restrict_ = DUMB_MOD_RESTRICT_NO_15_SAMPLE here?

Do NST files always have .nst as an extension and never .mod? I'm then considering to let Allegro 5 dispatch .nst files to DUMB too, and call dumb_*_mod*() with restrict_ = 0.

@kode54
Copy link
Owner

kode54 commented Sep 19, 2017

NST have unknown extensions, sometimes .MOD. Feel free to use restrict_ = 0 in any case.

I only do not, since I have encountered renamed modules before, and in one case, a module that was packed in an LHA archive.

@SimonN
Copy link
Contributor

SimonN commented Sep 19, 2017

Okay, I'll use 0 then for both .mod and .nst.

Interesting that the naming didn't standardize. Then yeah, you have to offer this choice to guarantee optimal playback, because not even a default can catch all cases. (On first sight, it looked like restrict_ asked its caller to make a decision that DUMB should make itself.)

Thanks for the insight!

@kode54
Copy link
Owner

kode54 commented Sep 19, 2017

Note that the any reader passes anything that fails the other reader checks into the MOD reader. Just in case something proves to be a false positive for the other signature checks. Too many possible signatures to check for MOD files.

@Rondom
Copy link
Contributor Author

Rondom commented Sep 26, 2017

I suggest to leave this open until we have some of the content of those comments here as documentation in the code as well.

@SimonN
Copy link
Contributor

SimonN commented Sep 27, 2017

Yes, this restrict_ needs public documentation: Explain exactly why we should choose 0 as a default. Also we need a minimal example of DUMB-using code. The example programs are nice, but they already do too much (parsing arguments etc.) to be minimal.

Maybe even define default arguments in DUMB 2.1? Ideally, the lib decides everything for you unless you explicitly want more control.

dos1 added a commit to dos1/opensludge that referenced this issue Sep 16, 2018
dumb_read_mod_quick has gained a new argument "restrict".
See kode54/dumb#53 for more details.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants