Print Page - Not sure if it's possible to make other plugins

Title: Not sure if it's possible to make other plugins
Post by: simon.snake on February 25, 2013, 03:30:32 PM

I like the ability to add plugins to Fractal eXtreme and welcome the work of panzerboy in creating the myriad of extra fractals that have given the program a new lease of life.

I'm trying to understand the type of fractals that this program can create and as far as I can tell the program leans toward m-like fractals only.

Is it possible to create any other type of fractal in this program. I suppose that any fractal that requires some information on the colouring of neighbouring points wouldn't work as that information isn't available.

Is it possible to create, for example, kali sets, etc.?

Maybe some method of allowing the user to enter a formula (obviously without the trig functions etc.) would be possible? That way, it would allow us to play a little but I still feel it would be of limited use. Any ideas?

Simon

Title: Re: Not sure if it's possible to make other plugins
Post by: panzerboy on February 26, 2013, 10:54:51 AM

The only real limitation is that Fractal Extreme provides a coordinate pair (and constant coordinate if Julia) and needs a count returned.

If you don't need deep zooms you can use any math functions in a FX plugin.
So Kalisets would be possible, not sure how z=abs(z^-1)+c translates into c code though.
As far as the floating point routines go, they are plain c code.

If you download the source of my latest plugin.
http://sourceforge.net/projects/simon30afxplgn/files/Simon30aSource.zip/download

I've #defined the inner iterations in the CustomFX.h file eg.

Code:

#define S30AMNDFLOATITER\
	zi = zr * zi * 2.0 + JuliaI2;\
	zr = zrsqr - zisqr + JuliaR2;\
	zisqr = zi * zi;\
	zrsqr = zr * zr;

Then used this macro three times in the calc.cpp file.
Firstly in the iteration loop.

Code:

	int count = 0;
	switch(EquationID)
	{
	case FT_S30aMand:
	case FT_S30aMndSmth:
		for (/**/; count < MaxIters && (zisqr+zrsqr) < OverFlowPoint; count++)
		{
			S30AMNDFLOATITER
		}
		break;

And then twice if its a smooth shaded version.

Code:

	} else if(smooth)
	{	if (count == MaxIters)
		{	count = pParams->MaxIters;
		} else if(EquationID>=FT_S30aMndSmth) 
		{
			count<<=8;
			switch (EquationID)
			{
			case FT_S30aMndSmth:
//				two more iterations to decrease the error term			
				S30AMNDFLOATITER
				S30AMNDFLOATITER
				break;

C purests probably blanch at my using a #define in this way rather than call a function but the overhead of calling a function would be slower (however slight).

So the process of creating your own plugin would be to change the math in the "#define S30AMNDFLOATITER" in CustomFX.h.
Then Change the Fractal Type

Code:

enum FractalTypes
{
	FT_S30aMand,
	FT_S30aBship,
	FT_S30aCltc,
	FT_S30aBffl,
	FT_S30aMndSmth,
	FT_S30aBshipSmth,
	FT_S30aCltcSmth,
	FT_S30aBfflSmth
};

eg change FT_S30aMand to be FT_MyFormula and FT_S30aMndSmth to FT_MyFrmlSmth
Note that all 'smoothed' fractal types are in a bunch after the non-smoothed.
This is because of the previous test "if(EquationID>=FT_S30aMndSmth)" which runs the smoothing logic.
If the smoothed fractal types were mixed in with the other types I'd have needed to write...
"If(EquationID==FT_S30aMndSmth || EquationID==FT_S30aBshipSmth || EquationID==FT_S30aCltcSmth || EquationID==FT_S30aBfflSmth)"
Which is be more bulletproof code, but again is ever so slightly slower.

Do a global replace on the fractal type(s) in calc.cpp

Search for the your new fractal type and change the label in calc.cpp

Code:

FXEXPORT const char *GetEquationLabel(int EquationID)
{
	switch (EquationID)
	{
	case FT_S30aMand:
		return "S30AMand";
	case FT_S30aMndSmth:
		return "S30AMandSmth";

Change the Fractal Name

Code:

FXEXPORT const char *GetFractalName(int EquationID)
{
	switch (EquationID)
	{
	case FT_S30aMand:
		return "Snake30A Mandelbrot";
	case FT_S30aMndSmth:
		return "Snake30A Mandelbrot Smooth Shaded";

change the description

Code:

FXEXPORT const char *GetFractalDescription(int EquationID)
{
	switch (EquationID)
	{
	case FT_S30aMand:
		return "Simon Snake's 30A Mandelbrot\r\n\n"
			"zi = zr * zi * 2.0 + 2*JuliaI\r\n"
			"zr = zrsqr - zisqr + 2*JuliaR\r\n";
	case FT_S30aMndSmth:
		return "Smooth Shaded Simon Snake's 30A Mandelbrot\r\n\n"
			"zi = zr * zi * 2.0 + 2*JuliaI\r\n"
			"zr = zrsqr - zisqr + 2*JuliaR\r\n\n"
			"Returns 256 fake iteration values between the real iterations\r\n"
			"Use an iteration count greater than 16383 to activate\r\n"
			"Set Bailout to 4, Colour mapping speed to 30";

To be nice you should change the #define name from S30AMNDFLOATITER in CustomFX.h and global replace it in calc.cpp
to "#define MYFORMULAFLOATITER" perhaps?

Then delete any unused Fractal Types, making sure the last fractal type has no "," at the end of the line.
Go through calc.cpp and remove all code associated with the unused Fractal Types (Visual Studio will highlight these).

If the calc_fixed.cpp source file is ommitted from the build then the plugin will be floating point only.
It is not required to define the high precision fixed point functions.
You may want to go through CustomFX.h and remove any unused #defines like "#define S30AMNDHPRECITER\..." to be tidy.

For further reference check fxplugins.h for comments on the functions needed to create a floating point plugin.

Title: Re: Not sure if it's possible to make other plugins
Post by: simon.snake on February 26, 2013, 02:21:13 PM

What about the possibility of using a complex number library to calculate the iterations?

Does one exist that can simply be included in the source?

Hadn't thought much about it but wouldn't it make your life easier programming the calculations?

So many questions (glad I'm curious)...

Title: Re: Not sure if it's possible to make other plugins
Post by: panzerboy on February 27, 2013, 09:10:33 AM

No reason a complex library wouldn't work but...
I would think a complex library would slow things down.
There's an overhead to calling a function, parameters are placed on the stack, auto variables initialised on the stack.
Complex variables are often defined as structs, which are passed as pointers, so there's an extra level of indirection (extra cycles) before you get to the data.

There are suggestions you can make to the compiler, like declaring register variables or functions as inline.
There are different calling conventions that may be lighter or heavier on stack usage.
With full optimisation turned on the compiler (linker?) may be smart enough to pass variables in registers, but no guarantee.
A lot of complication, that can be avoided by being more complicated with the arithmetic.
Its a old programming trade-off, easier to use usually means less efficient.

The function calling overhead matters less for more complicated formula.
Using logs or trig are iterative processes that take far longer then the function call/return stack manipulation.

Welcome to Fractal Forums

Fractal Software => Plugins => Topic started by: simon.snake on February 25, 2013, 03:30:32 PM