xordev/gml_shaders

GML functions brought to GLSL

GML+GLSL

Today I ported the GML math functions to GLSL. Common functions like point_distance, dcos, angle_difference and even irandom. See the code here.

gml_shaders's Issues

Are you sure you copied functions from GML (Graph Modelling Language) and not GLM (OpenGL Mathematics)?

It seems like repository contains functions from GLM while the repository title and README states they are taken from GML, which is probably not true.

GML

GLM

Many macros are unusable outside bracket-enclosed use cases

All macros that do not enclose every input parameter in brackets will not work with any somewhat complex values passed to them.
Same goes for macros that use exposed operands.

Module-local variable `seed` blocks commonly used variable name

There is a strict taboo on the word seed used as a function, variable or structure name in any project that uses this module.

That's because the name seed is already used in your module as a global variable. On top of that, there is no indication that the float variable seed is crucial for your random system and, therefore, should not be modifiable by the user of this library. Many C libraries that do use such variable tend to name them accordingly, all-caps with leading underlines (as opposed to snake case used for local variables).

Suggestion: why not make all the macros inline-ish functions?

There is no reason for any of these macros to be functions, especially considering they will most likely be in-placed by the compiler.

Making them functions will also increase their performance, as their parameters will not be recalculated for every use. Speaking of recalculations, there are also cases where macros like these are unusable no matter their bracket enclosure (any impure function will break if passed as any multi-use parameter of any macro).