during the last week, I had C-91 around () and obviously, we did some fractal work together During this, we needed to create some ad-hoc plugins to do the things we wanted to do. Well - not that it's something new for me because I kinda do this all the time but it gave me the idea that maybe I should write up how you actually create the plugins with x86 / x64 processor architecture support. I'm well aware that it's not very well documented so I try to fill this gap now with this little guide.
First off, I don't like to call it a "new" way to create plugins. You still create them with the same interface you had before when JoelFaber (afaik, it was him) set up the plugin infrastructure. But I felt maybe since Apo is sort of bound to Microsoft Windows and Visual Studio is a super comfortable development environment every professional Windows developer has at hand anyway, I could use VS and C++ to create them instead of a random GNU-C environment which is always somehow incomplete and bulky to me personally.
Yeah, I know. GNU-C is the way and blah. But as said, this way came up through a personal need of mine and I'm in no way saying that you can't compile x64-plugins without VS. Pretty much all you have to do is set the architecture in MinGW and alter some pointer lengths and you got it.
Anyway. Here is what you need to do to create plugins the way I publish them - in x86-, x64- and legacy*)-versions
*) the "legacy"-version is always the plugin compiled with MinGW under Windows so it doesn't depend on the MSVC++ redistributable. It's sort of a requirement to allow the plugin to be used under some older WINE-environments for OSX and Linux computers
I'm assuming you work under Windows. Otherwise, I don't know how you think you will get VS to run heh heh
So first, you need a working installation of Microsoft Visual Studio. And no, the (free) express editions won't do. You need the Professional/Premium or Ultimate 2012 or 2013 version. I highly recommend 2012 unless you feel like converting the plugin projects and want your users to require a newer runtime. I know it is super expensive but this guide requires it. But feel free to make it work for VS Express - it's not that it's impossible. Just that I didn't do it yet
Once you have downloaded and installed it, you can can download the Apophysis plugin SDK and extract it to any folder. This folder will become your new working path for any plugin you do with it. So maybe put it somewhere you remember it and preferably not right on your desktop. You can see that I use the same thing so I'm pretty sure it works as it is because I've got the whole thing in subversion and check it out on "virgin" computers (who didn't even see Apo before and just got a fresh install of Visual Studio) regularily
Creating your plugin from scratch
To create a plugin from scratch, all you have to do is either:
- open create_plugin.cmd from explorer or
- open a command prompt in your working folder and enter create_plugin <name_of_plugin>
Then a new folder should appear named after what you just entered as the name of your plugin. In there, you find a .vcxproj-file for Visual Studio and a .cbp-file for CodeBlocks (a free IDE for MinGW) I recommend you edit your plugin in Visual Studio (also because this guide shows you how) so open the .vcxproj-file with Visual Studio.
You will find that your plugin is split into the files "variables.h" and "[your_plugin].h" - why I did the split is something I honestly don't remember but I didn't change the template yet. Either way, you just edit name and variables in variables.h and the calculations in the other file - your generated plugin project already has the name set right and some example variables you can either delete or change.
From there, it's up to you - maybe you want to read how to compile it for all architectures and legacy targets down below
Converting an old plugin project to VS-friendly structure
Simple as that - take your .c file (the source code of the plugin you want to convert) and drag it to update_plugin.cmd in the explorer. Alternatively, enter update_plugin <path_to_c_file> in the command prompt of your working folder.
A new folder should appear named after the .c file you just converted. From there, it's pretty much the same as the previous paragraph about creating a new plugin from scratch except that for this template, I've already undone the split into [name].h and variables.h - sorry for the inconsistency. I'll fix it later
Compiling your plugin project to all targets at once
Pretty much, you can set your target architecture in Visual Studio and compile in release mode and then copy your .dll from the bin-folder to the Apophysis plugin folder. But that's something which is kind of uncomfortable. Here is an easier way:
Simply drag the folder which one of the previous scripts generated onto the file build.cmd or enter build <name_of_plugin(_folder)> in the command prompt of your working folder. That's it, you should find all three versions of your plugin in the folder named ".output" ready for you to copy it anywhere.
If you want to build all plugins at once, you can run build_all.cmd from the explorer or run build_all from the command prompt of your working folder.
Testing plugins from Visual Studio
The project templates are already setup so that you can simply use the "Run" command in Visual Studio (usually F5) to start an instance of Apophysis with your plugin installed.
Alternatively, you can enter test <name_of_plugin(_folder)> in the command prompt of your working folder. Sorry, I didn't add drag-and-drop support for plugin folders to this script yet - didn't need it because you can test right from Visual Studio.
You can even set breakpoints and anything. But note that, of course, Apophysis will run A LOT slower when a debugger is attached.
If you want to start Apophysis with a test flame for your plugin loaded right away, you can save a flame as "test.flame" into the folder of your plugin. Visual Studio will pass this file to Apophysis when it's loaded. This way, you can start Apophysis with your plugin installed AND your test flame loaded when you hit F5 in Visual Studio. How comfortable!
I hope this helps you a bit. If you are against this workflow or environment, this guide was probably not the right thing for you to read and I apologize with the hint that the SDK generates CodeBlocks-projects for you as well