Hello Mr. Lotter,

I guess the manual page concerning fixed(float) isn't correct.

http://www.conitec.net/beta/afixed.htm

The functions name should be "fixv", not "fixed", right? At least that's what the example on that page suggests and what actually compiles. Using "fixed" results in an compile time error.

The type of the parameter should also be float, not var.

This macro is certainly confusing, even to programmers, so I've written the description a little more clearly. You can see in its #define in acknex.h what it does. And yes, the name is indeed 'fixv' and not 'fixed'.

I can only speak for myself here, but for me the changes you did have not made the description any clearer. Especially the term "'real' var" might confuse beginners even more. In the end it comes down to a format conversion from the IEEE floating point format to the fixed format gamestudio uses, right?

Maybe you could cure my curiosity and explain how this monstrum works:

Casting the address of the var to float* and dereferencing it again does not make sense on a first glance to me. ^^ I had expected something like

That's what I feared - fixv() and floatv() are really hard to explain and to understand because they go against the 'normal' C use. C freaks will know the methods, but in scripts they are fortunately very, very rarely used, so if you do not understand them, you'll certainly never need them. Anyway I try again:

floatv() stores a float in the memory space of a var.

fixv() converts a float stored in the memory space of a var to a var. The fixv macro is needed to tell the compiler that the var is in fact a float, not a var.

That explanation is probably not much better, but the only example I know that uses floatv and fixv is the water.c script.

This explanation is perfectly fine for me. So, more precisely it is not a conversion that takes place but instead a hint to the compiler concerning the actual number representation format the number is encoded in, isn't it?

The scenario in water.c corresponds exactly to my use case with the exception that I use material skills instead of entity skills.

Thanks for taking the time to explain. Your patience is highly appreciated.

Correct, that's why a simple cast ala ((float)x) won't work here, because then the compiler would attempt to convert the variable into a float, which it already is. By taking the address of the variable and casting it to a float pointer, no conversion is done, and dereferencing a float pointer won't do any conversion either.

imho this is pretty dirty since it actively tries to "outsmart" the compilers typesystem. Wouldn't it be better to make at least the material skills float by default and then use an implicit type cast? (As far as I can see, they are expected to be float anyways)


It should be noted that there is no actual conversion happening (with the exception being var -> float), but instead that the functions are used to force a float into a var without any implicit conversion that would occur if one would just type 'x = y'

It is indeed a dirty method, resulting from WDL legacy. WDL had only one variable type, so when floats were needed they had to be stored in the memory space of vars.

hmm what about changing the type of the material skills to float?
you won't brake old code if the fixv, floatv defines will be changed to just
#define fixv(x) x

You will since the invocation of fixv() and floatv() isn't guaranteed to be exclusive for material skills.

@JustSid: Thanks, your posts are always helpful.

@MasterQ32: I don't think that this is a good suggestion. Tons of code might break with this change. Apart from that: there is no need to change. The discussion we're doing here is very interesting for me. But you don't need to understand a word of what's being written here in order to successfully apply the concept.

@jcl: In the end it can be brought down to: Use floatv when you want to pass something to a shader, use fixv for the inverse operation. I'm the living proof for that as I applied the technique correctly without even knowing fixv was a macro and how it worked. I guess this is even the most important message for the manual page. I don't know if the background information about memory space and casting is really required there. If however you want to include advanced info the JustSid is absolutely right with:

The example provided on the manual page does not do a good job from my point of view. Just showing the inverse function does not make the purpose or the usage of the function any clearer. It's quite the opposite for. When there are two functions and one reverses the other you might expect that both of them do a conversion.