Guevara-chan/Raylib-Forever

Collision between some procs in raymath module

Skaruts opened this issue · 2 comments

raymath.nim(105, 6) Error: overloaded 'Zero' leads to ambiguous calls

The same is true for One and Identity because they don't take any parameters. It might be worthwhile to keep the original prefixes.

Um... Line 105 is proc Vector3Zero*(): Vector3 {.RMDEF, importc: "Vector3Zero".}, AFAIR. What could it possibly overload ?

Hmm... I don't remember having removed the prefixes myself, but... I did... :S
Sorry about that.

I found a few other issues though (I can place them in their own issue thread(s) if you want):

1 - I get these errors when I try to use these procs (others work fine -- only tested Vector2 stuff):

Error: Couldn't importc Vector2Multiply
Error: Couldn't importc Vector2AddValue
Error: Couldn't importc Vector2SubtractValue

2 - The definition of PI is missing in raylib.nim.

3 - There's a type mismatch (int32 vs uint32) between
converter ConfigFlag2int32* (self: ConfigFlag): int32 = self.int32
and
proc SetConfigFlags*(flags: uint32)

4 - I had a bit of trouble with these templates, when using them inside my own templates (they seem to work fine inside procs):

template DEG2RAD*(): auto = (PI/180.0f)
template RAD2DEG*(): auto = (180.0f/PI)

When I used it like 90*DEG2RAD inside a template, I got this error:

	Error: type mismatch: got <int literal(90), template (): untyped>
	but expected one of:
	proc `*`(x, y: float): float
	first type mismatch at position: 2
	Required type for y: float
	but expression 'DEG2RAD' is of type: template (): untyped
        # etc...

Also may happen with MAX_TOUCH_POINTS and some other templates that were derived from C #defines. Perhaps they ought to just be const in Nim (as per c2nim)?