#6 few things related to the sc68 source from trunk

[waker]

Hi Ben

Your email specified in the sources and on the web is not working, so writing here.

I'm in the process of adding sc68 lib support to my player (it's
called deadbeef, http://deadbeef.sf.net).

I got the lib to build from trunk, as the latest stable release seems
to be dated 2003.

The problems that I encountered:

• automake 1.14 requirement for bootstrapping -- would be nice to
  replace with 1.11, cause it works, and makes the lib buildable on
  ubuntu 12.04 (it's hard to get latest automake on older stable
  distros)

• even if I have the automake, build still fails on some texinfo stuff
  (even if I have it installed), but I guess it can be worked-around by
  using some configure flag, like --disable-docs.

• The file trap68.h doesn't generate correctly on OSX, the values are
  correct, but there are no commas in the file, it looks like "96 16 8
  56 0 3 250 ....", so I had to generate it on linux. Would be nice if
  all such files are included in the source control, so that the stuff
  is buildable on non-linux OSes.

• In the end I got the stuff running, I can load and play the files
  but I can't figure out the data68 folder. I found how to specify its
  location in the stable sc68 lib (via SC68_DATA environment variable),
  but can't find how to do it on trunk. Is it still needed at runtime?

• Another thing I can't figure out is seeking. It seems like it's not implemented, but I'm not sure. Can you confirm?

• Any plans on switching to git and maybe moving the repo to github? I'd like to send few patches back when I'm done with it, but subversion is a PITA to work with.

Thanks a lot for the continued development.

[Ben G. Han]

Hi

Thank you for the report.

• automake - I don't remember if there was a good reason for me to enforce >= 1.14. I can definitively go back to 1.11 worst case scenario it won't work.
• doc - Unfortunately the documentation was kind of a work in progress that got put on hold. I thought I'd disable everything that cause problems but I might have forgotten some (or may be it's not committed yet, I'll have a look). Would have been helpful to have a little more details on the problem though.
• trap68.h - I'll have a look. The script to transform is awful anyway I had in mind to rewrite it. Do you mind if I send you a version ? I'm currently mostly working with cygwin and I have no easy to test on macOS.
• sc68-data - What is the problem exactly ? Is the default location not good enough with MacOS ? Anyway there is quiet a few ways you can consider.
  • Not using them (it's mostly the replays) by settings --enable-replay-rom (makes the binary larger by including the replays into libsc68).
  • you can set the value at run time either by calling rsc68_set_share() (file68_rsc.h), but it's outside the main API call.
  • Alternatively you can hook the resource loader rsc68_set_handler(), but I would not advice to do that. It should work but I haven't tested it for a long time.
  • Force a path in the command-line in the sc68_init_t::argc/argv. Roughly:

init.argv[x++]="--sc68-share-path";
init.argv[x++]=ourpath;
sc68_init(&init);

* Last and best use the new sc68_cntl() function. It should work that way, but it's pretty much untested. Please tell me if it works or not :)

sc68_cntl(0,SC68_SET_OPT_STR,"share-path",ourpath);

• seeking: I confirm seeking has been disabled. It was never really a thing as it is hard/impossible to seek into a program. It was just a fast forward really. I think it's best implemented outside the library at the moment.
• I did not plan any version-ing platform switch in a near future. However I'm working with git-svn on local. I'm pretty sure we can make things work this way. Any help contribution is greatly appreciated.

I hope it helps. I'll try to work thess things ASAP.