Unable to compile an AviSynth C++ DLL

[StainlessS]

Originally Posted by Forensic

error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?

In VC6 New Project, I generally choose Win32 Dynamic-Link Library, with Location
set to my Projects directory and Win32 box ticked. Give it a Project name eg 'Sin'.

I next step, I always select 'An Empty DLL Project' (avoids that stdafx stuff).

In FilesView
Add avisynth.h (and any other of your self made headers) to the Header Files
Add Sin.cpp to the Source Files.

Sin.CPP (From SDK NON-ClipSample)

#include <windows.h>        // from compiler/SDK include dir
#include <math.h>           // from compiler/SDK include dir
#include "avisynth.h"       // In your project dir

AVSValue Sin(AVSValue args, void* user_data, IScriptEnvironment* env) {
    return sin(args[0].AsFloat());
}

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
    env->AddFunction("sin", "f", Sin, 0);
    return "sin";
}

About as simple as it gets.

By The Way, this is how I have my Menu/Tools/Options/Directories set for VS6 + ToolKit 2003 + SDK:

Executable Files:::
C:\Program Files\Microsoft SDK\bin
C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin
C:\Program Files\Microsoft Visual Studio\VC98\BIN
C:\Program Files\Microsoft SDK\bin\winnt
C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS
C:\Program Files\Microsoft Visual Studio\COMMON\MSDev98\Bin
C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS\WINNT
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Intel\DMIX
C:\WINDOWS\system32\WindowsPowerShell\v1.0
C:\Program Files\Support Tools

Include Files:::
C:\Program Files\Microsoft SDK\include
C:\Program Files\Microsoft Visual C++ Toolkit 2003\include
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE

Library Files:::
C:\Program Files\Microsoft SDK\lib
C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib
C:\Program Files\Microsoft Visual Studio\VC98\LIB
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

Only first 3 files of each section really relevent, I put VC98 entries above Toolkit 2003 normally
(and for debugging as ToolKit 2003 has no debugging), and for final, switch TK2003 above VC98.

Hopefully not too dissimilar to VC2012.

PS, you might find the Avisynth Compiled Help With SDK (CHM) File for v2.6 useful (MediaFire in sig), stick it on a hot-Key.

[Gavino]

Originally Posted by StainlessS

Avisynth.h is part of your project and should be in same directory as your source files,
included with

#include "Avisynth.h"

rather than

#include <Avisynth.h>

which includes from the compiler include paths.

That's not necessary.
Rather than have a copy of avisynth.h in every project source file directory, I prefer just to add the containing folder (eg C:\Program Files\AviSynth 2.5\FilterSDK\include) to the list of include directories for the project. I then use #include <avisynth.h>.

[StainlessS]

Arh but, I frequently use Avisynth.h, Avisynth25.h, Avisynth26.h, and like them when I can get at them easily (and the correct ones) when copying source files for zip.

[Forensic]

In VS12, I went to (NEW - Visual C++ Win32 Project - DLL Empty project) and got:



I also tried to get to the finish line with "C:\Program Files\Microsoft Visual Studio\Common\IDE\IDE98\MSE.EXE" but that behaves as just a text editor.

I also have "Visual C++ Toolkit 2003 Command Prompt" but have not yet figured how to use that, if that is the correct solution.

[jackoneill]

#include <math.h>

[JEEB]

C/C++ basics, you include and link (if needed) the things you are using from the standard libraries.

Some reference.

Basically include cmath or math.h (the "C++ way" is the first, and the second is the C way -- both should lead to the same result), and the compiler should stop complaining. If the linker complains about not finding the actual implementation, you link the according standard library library.

Also make sure you actually need that windows.h header, don't just include it blindly :P .

[Gavino]

Originally Posted by JEEB

C/C++ basics, you include and link (if needed) the things you are using from the standard libraries.

Some reference.

Also, if you need to use constants like pi, e, etc, in your code, add the following line before including cmath or math.h:

#define _USE_MATH_DEFINES

See http://msdn.microsoft.com/en-us/library/4hwaceh6.aspx.

In my view, this is better than defining them yourself like JEEB's reference does.
For one thing, it saves you looking up the exact value and possibly mistyping the numbers.

[JEEB]

Yes, naturally. My intention was to just bring to his knowledge that he should look into how the language and its standard library work in general.

[StainlessS]

Sorry Forensic, my fault, should have included the "#include <math.h>" line.

[Forensic]

#define _USE_MATH_DEFINES
#include <math.h>
Adding those two lines eliminated the errors and gave me my first successful AviSynth DLL (now I just have to ask StainlessS how I test his mini-creation). Recompiling other people's valid source code provides a means for me to test how modifications affect the results. That is how I expedited my understanding of AviSynth scripting. I am extremely appreciative of everyone's assistance, and willingness to do so. I realize that my C++ floundering can border on being both comical and a bit pathetic. There are a lot of structural and syntax rules to learn about C++, especially as they relate to building Avisynth 2.58 compliant DLLs. Made tougher by the fact that the last "real" programming languages I used were Cobol, integer basic and 6502 assembly (all from the 1970s). I am incredibly appreciative of everyone's feedback and apologize if my Deer in the headlights comments ever imply anything else. My ONLY goal at this point, is to create useful Avisynth compliant DLLs so I can contribute to my forensic peers and the Doom9 community.

[Gavino]

Originally Posted by JEEB

Yes, naturally. My intention was to just bring to his knowledge that he should look into how the language and its standard library work in general.

I realise that, I was just adding more information to supplement your already helpful post.

However, I'm not so sure about this part:

Originally Posted by JEEB

Also make sure you actually need that windows.h header, don't just include it blindly :P .

In my experience, windows.h is always needed before including avisynth.h. Otherwise, you get loads of errors from other windows-related header files that would probably be incomprehensible to a newbie.

[StainlessS]

Nothing wrong with trying out the simplest test dll just to see if the setup works, indeed quite logical.

colorbars
q=PI/4.0
s= Sin(q)
Subtitle("Sin(" + String(q) + ")" + " = " + String(s))
return last

Now to get to the filter type dll's. (Dont forget to remove dll from plugins)

[Forensic]

StainlessS, thank you. Now I know that I can successfully compile something (anything) that works!!! Yea. Mission #1 done. Now that my compiler works, back to filters.

[Groucho2004]

Originally Posted by Forensic

Now that my compiler works, back to filters.

Next exercise ():
Make a DLL out of this code and figure out what it does:

#include <windows.h>
#include "avisynth.h"

class Invert : public GenericVideoFilter
{
public:
 Invert(PClip _child) : GenericVideoFilter(_child) {}
 PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
private:
 const BYTE* srcpY;
 const BYTE* srcpU;
 const BYTE* srcpV;
};

AVSValue __cdecl Create_Invert(AVSValue args, void* user_data, IScriptEnvironment* env)
{
 return new Invert(args[0].AsClip());
}

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env)
{
 env->AddFunction("Invert", "c", Create_Invert, 0);
 return "Invert plugin";
}

PVideoFrame __stdcall Invert::GetFrame(int n, IScriptEnvironment* env)
{
 PVideoFrame src = child->GetFrame(n, env);
 PVideoFrame dst = env->NewVideoFrame(vi);

 srcpY = src->GetReadPtr(PLANAR_Y);
 srcpU = src->GetReadPtr(PLANAR_U);
 srcpV = src->GetReadPtr(PLANAR_V);

 BYTE* dstpY = dst->GetWritePtr(PLANAR_Y);
 BYTE* dstpU = dst->GetWritePtr(PLANAR_U);
 BYTE* dstpV = dst->GetWritePtr(PLANAR_V);

 const int src_pitchY = src->GetPitch(PLANAR_Y);
 const int src_pitchUV = src->GetPitch(PLANAR_V);
 const int dst_pitchY = dst->GetPitch(PLANAR_Y);
 const int dst_pitchUV = dst->GetPitch(PLANAR_U);

 const int row_sizeY = dst->GetRowSize(PLANAR_Y);
 const int row_sizeUV = dst->GetRowSize(PLANAR_U);

 const int heightY = dst->GetHeight(PLANAR_Y);
 const int heightUV = dst->GetHeight(PLANAR_U);

 int y, x;

 for (y = 0; y < heightY; y++)
 {
  for (int x = 0; x < row_sizeY; x++)
   dstpY[x] = srcpY[x] ^ 0xFF;

  srcpY += src_pitchY;
  dstpY += dst_pitchY;
 }

 for (y = 0; y < heightUV; y++)
 {
  for (int x = 0; x < row_sizeUV; x++)
  {
   dstpU[x] = srcpU[x] ^ 0xFF;
   dstpV[x] = srcpV[x] ^ 0xFF;
  }

  srcpU += src_pitchUV;
  dstpU += dst_pitchUV;
  srcpV += src_pitchUV;
  dstpV += dst_pitchUV;
 }

 return dst;
}

[Gavino]

Originally Posted by Groucho2004

Make a DLL out of this code and figure out what it does

For bonus points, explain why it is not thread-safe, and how that can be fixed.
Hint:

class Invert : public GenericVideoFilter
{
 ...
 const BYTE* srcpY;
 const BYTE* srcpU;
 const BYTE* srcpV;
};

[Forensic]

Groucho2004. That is so awesome that you are doing this for me. Hopefully, all of the newbies will benefit from this too. Compiling and loading the DLL was easy enough and my best guess of your code is that it shifts the U&V pixel values in a linear fashion with each successive frame. The part stumping me is the function call. Reading your code, I thought the call (using colorbars for the test) was colorbars.PVideoFrame or colorbars.Invert
The first one fails to be recognized and the second is an internal call. So I admit my stupidity....what is the function call?

[StainlessS]

Argument is clip only, source clip Planar, Colorbars().ConvertToYV12().Invert(),
dont forget to copy dll to plugins, else will use built-in Invert().
Remove dll afterwards.

Below tells avisynth about the plugin name and args.

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env)
{
 env->AddFunction("Invert", "c", Create_Invert, 0);
 return "Invert plugin";
}

This is (TwoFiveInvert) sample from SDK. http://avisynth.nl/index.php/Filter_SDK
also in Avisynth 2.6 + SDK compressed helpfile as previously posted (MediaFire in sig).
EDIT: Not TwoFiveInvert, but very similar.

EDIT: This is the bit that does invert (on Y)

dstpY[x] = srcpY[x] ^ 0xFF;

the '^' is XOR, XOR with $FF makes eg 0->FF and FF->0. (Copying from source, XOR, to Dest)

To call another built-in or external function (you need to know it exists) see Invoke. http://avisynth.nl/index.php/Cplusplus_API
(Most filters do the hard work themselves and do not call built-in/external filters)

[Forensic]

I did not realize the DLL worked because its functionality was indistinguishable fromo the internal "Invert" function. So...I recompiled it after changing all instances of "Invert" to "InvertX", just to be sure, and everything worked. Best of all, everything is being done in VC++ 2012 Express. I will now manipulate this code, and other plug-in source codes, along with reading two very large C++ books. As for Gavino's bonus question on thread-safe coding; my best guess is that the noted constants are being defined as public variable that potentially conflict with other functions wanting to load, or overload, the same variable names. But that is just my instinctual guess...not from understanding C++.

[StainlessS]

Methinks that the Gavino Bonus Points were aimed at Grouchy.

[Groucho2004]

Originally Posted by Gavino

For bonus points, explain why it is not thread-safe, and how that can be fixed.
Hint:

class Invert : public GenericVideoFilter
{
 ...
 const BYTE* srcpY;
 const BYTE* srcpU;
 const BYTE* srcpV;
};

Damn, didn't realize that was still there. I was playing around with this a long time ago. I should really look at the code before posting...
Yes, these 3 const BYTE* should be local in ::GetFrame() just as the "BYTE* dstp" vars.