Famitracker Plugins: sound driver + demo rom, text exporter
Moderator: Moderators
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Famitracker Plugins: sound driver + demo rom, text exporter
Not too long ago I added a feature to Famitracker which will allow you to write an exporter for your own sound engine that works with Famitracker. I also wrote an example sound driver and an example exporter DLL for that driver. It is based on concepts I learned from the Nerdy Nights sound tutorials (thanks MetalSlime!). I'm hoping some people out there might be able to use the example out of the box in their own games and then maybe improve it for their own use, or write exporters for other sound engines.
I wrote the feature mainly because I didn't need quite as much sophistication as the Famitracker driver had built in, I wanted a lightweight driver that would make sound effects easy to implement as well. And, more importantly, I wanted to still be able to use Famitracker to compose the music.
*edit* There have been lots of edits to this top post, but I wanted to keep it clean and not have too many links to old builds of stuff. The following will be updated as bug fixes and so on are added, until the next release of Famitracker is available.
Here is a new development snapshot, with some new features. The plugin interface is now a pure C function interface, so plugins can be written with non Microsoft compilers. I have included information in README.txt on how to compile an example plugin with g++ under Cygwin as an example. Also, a new function, GetExt, has been added to the interface, as per Shiru's request, so that plugins can suggest what extension is appropriate for its format.
*edit* A development snapshot, containing source, windows XP binaries, and a demo rom
Famitracker Development Snapshot, December 24th, 2010
*edit* A link to just the demo rom if you want to see the example sound engine in action
Example Sound Engine Demo
Here is a link posted by Shiru in General Music and Sound Solution to a plugin he wrote which can export in a parsable text format.
Parsable Text Exporting Plugin
Here is Shiru's thread about his new sound engine, FamiTone, that can be used with this plugin system: FamiTone.
I wrote the feature mainly because I didn't need quite as much sophistication as the Famitracker driver had built in, I wanted a lightweight driver that would make sound effects easy to implement as well. And, more importantly, I wanted to still be able to use Famitracker to compose the music.
*edit* There have been lots of edits to this top post, but I wanted to keep it clean and not have too many links to old builds of stuff. The following will be updated as bug fixes and so on are added, until the next release of Famitracker is available.
Here is a new development snapshot, with some new features. The plugin interface is now a pure C function interface, so plugins can be written with non Microsoft compilers. I have included information in README.txt on how to compile an example plugin with g++ under Cygwin as an example. Also, a new function, GetExt, has been added to the interface, as per Shiru's request, so that plugins can suggest what extension is appropriate for its format.
*edit* A development snapshot, containing source, windows XP binaries, and a demo rom
Famitracker Development Snapshot, December 24th, 2010
*edit* A link to just the demo rom if you want to see the example sound engine in action
Example Sound Engine Demo
Here is a link posted by Shiru in General Music and Sound Solution to a plugin he wrote which can export in a parsable text format.
Parsable Text Exporting Plugin
Here is Shiru's thread about his new sound engine, FamiTone, that can be used with this plugin system: FamiTone.
Last edited by GradualGames on Fri Dec 24, 2010 10:15 am, edited 14 times in total.
The example is now up here: exporterplugin.zip
It contains all details needed to write a plugin.
It contains all details needed to write a plugin.
Windows SDK: 1.5 GB download. Or does Microsoft make it available on DVD-ROM?In README.txt, Gradualore wrote:To build the example_exporter_plugin, you'll need an environment
that can build Famitracker (DirectX 9 I think, and the Platform
SDK).
So here's my humble feature request: an exporter that creates a text file containing all of the info in the FTM in a stable, fairly easy to parse format. Then people could pipe this text file into a filter written in Perl, Python, JScript, GNU C++, or whatever else might already be installed on the developer's machine.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Go to a friend's/relative's house, an internet cafe, a public library, or anywhere else where they might have a high-speed internet connection. Bring a USB stick with you that you can copy all the files to. Or a laptop/netbook if you've got one and the place provides WiFi access.Windows SDK: 1.5 GB download. Or does Microsoft make it available on DVD-ROM?
Problem solved
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
A text serialization of all info in the .ftm isolates exporter developers from not only MFC but also Win32 itself. NESICIDE, a Qt app, could call the exporter in FT and then parse the text that it generates. In theory, this would work even on a Linux machine that can run FT in Wine.Gradualore wrote:I had considered, while developing this system, finding a way to isolate exporter developers from MFC.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
The easiest way would probably be to isolate the interface classes, then only a compiler that can compile DLL files is needed (no MFC or SDKs).
Another thing I just tried was to manually declare all things needed by the internal header files and that appeared to work as well, this could be included as an optional header file.
Another thing I just tried was to manually declare all things needed by the internal header files and that appeared to work as well, this could be included as an optional header file.
- Hamtaro126
- Posts: 783
- Joined: Thu Jan 19, 2006 5:08 pm
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
I wouldn't mind sending a binary of the example plugin dll to anybody interested. Just send me a pm.
*edit* see the top post for dev snapshots, demo rom, and additional plugins. (there had been a link here to an old build of the example plugin)
*edit* see the top post for dev snapshots, demo rom, and additional plugins. (there had been a link here to an old build of the example plugin)
Last edited by GradualGames on Sun Dec 12, 2010 2:29 pm, edited 1 time in total.
This is good news to hear. This way you can use FT for making music and export in the format you want.
In the future, maybe all export from FT should be external (nsf, FT binary, raw text data etc). You would just be adding one new dll in the folder for some new functionality.
As for the dependencies, I would try to remove them since it doesn't make sense unless you need them inside the dll itself, which shouldn't be the case since you parse data only.
If possible, I would try to see how to make it a COM interface. I'm sure some people must be looking at me and thinking "what the hell are you thinking!? COM?! barf!" (etc, etc). There is one reason for this: if you make the plugin COM based you can make the DLL in any language that support COM. This mean: win32, vb6, .net etc. New light programming should be made in .net anyway and with the included framework, there is no reason to not do so.
In the future, maybe all export from FT should be external (nsf, FT binary, raw text data etc). You would just be adding one new dll in the folder for some new functionality.
As for the dependencies, I would try to remove them since it doesn't make sense unless you need them inside the dll itself, which shouldn't be the case since you parse data only.
If possible, I would try to see how to make it a COM interface. I'm sure some people must be looking at me and thinking "what the hell are you thinking!? COM?! barf!" (etc, etc). There is one reason for this: if you make the plugin COM based you can make the DLL in any language that support COM. This mean: win32, vb6, .net etc. New light programming should be made in .net anyway and with the included framework, there is no reason to not do so.