PDA

View Full Version : Avisynth 2.6 plugin development hurfing and durfing thread


TheFluff
7th August 2011, 01:15
So I had a look at developing native Avisynth 2.6 plugins. Now I have a lot of questions.

Is the intention for everyone to compile their own interface.cpp, or are you supposed to link against some externally provided Avisynth import lib that pulls in the functionality from avisynth.dll? I assume it's the latter, since a) all the unbaking would be sort of pointless if not, and b) interface.cpp uses precompiled headers from the rest of the Avisynth project.

If the intention is the latter above: shouldn't you really also consider exporting a whole lot of function pointers in some nice clean way (so plugin ways can have their way with the internals if it is necessary)?

If the intention was to break compatibility with 2.5 and use a new interface, why not make the changes more obvious and, say, use a new entry point instead of reusing Ye Olde AvisynthPluginInit2? At least that way it'd be easier for plugin authors to tell if they were running under 2.5 or 2.6 and have separate code paths in the same DLL. The way it's done at the moment the interface is almost-but-not-quite compatible, which is arguably more annoying than having to deal with a completely new interface.

Why is avisynth.h suddenly vanilla GPL without the exception?


I reserve the right to hurf a further durf later.

kemuri-_9
7th August 2011, 04:57
there's not particularly a need to deprecate AvisynthPluginInit2 for another function to differentiate 2.5 from 2.6:

you can determine what version of avisynth is running by something along the lines of

bool is_version_x = false;
try
{
env->CheckVersion( version_x );
is_version_x = true;
}
catch( AvisynthError err )
{}

where 'version_x' is the interface version you're looking for: AVS 2.5 is primarily 2, and AVS 2.6 is 5
admittedly though, this is a bit clunky in the C++ version compared to the equivalent function in the C version which more simply returns 0/-1.


but yes, overall the baked code that was removed and placed into interface.cpp needs to be exposed in some useful manner, which yet hasn't occurred.