Closed jprjr closed 4 years ago
A simpler alternative might be to move the plugin code, NSF_TAG, and the subclassed NSFConfig w/ ini-loading into the same static library instead of separate ones. The common denominator is all those pieces are shared by the windows-only pieces. Like a xgm_win32
library, something like that.
Closing this, I went with the "minimum code changes" approach of moving all the windows-specific stuff into a separate library.
So - I just did a proof-of-concept locally where I stripped out Windows/plugin specific code and produced a command-line decoder on Linux/Unix 🎉
Really excited about the idea, since right now Linux/Unix is limited to libgme, it'll be so nice to have an alternative (that frankly, is the best-sounding, most-accurate NSF player).
My proof-of-concept was pretty fast/sloppy though, so I'm going back and trying to thoughtfully reorganize the pieces. This is the overall idea I have:
xgm::NSFConfig
for constructing the default config, create a new class that allows loading/saving config to ini files (maybe into a separate ini library?) that'll be used by in_yansf, kbmedia, nsfplay, etc.NSF_TAG
somewhere out ofxgm
, not sure whereThat was basically all that was involved in my proof of concept, along with writing a Makefile + a nsf2wav cli app.
So that said, here's a pull request where I moved
winamp2
into a separatexgm_wa2
static lib.I know you had mentioned not wanting to get a lot of code that'll just be thrown away, but I'm really interested in getting
xgm
running on linux/unix, and all my changes will be around code organization, not a whole lot of actual changes.I totally understand that a lot of this will get thrown out in the rewrite -- but it's something I'd really like to try doing, can likely pull off in a week or two, and I can keep the impact pretty low.
Let me know what you think!