RE: OpenGL vs _MAPTRIANGLE: OpenGL is (obviously) more powerful. However, the way I have seen OpenGL used by people in QB64 is heavily reliant on the fixed OpenGL pipelines and lighting found in OpenGL 1 which was all deprecated in OpenGL 2. Mobile devices do not support OpenGL 1. If QB64 ever did support mobile devices that code will simply not work. _MAPTRIANGLE was written to be fully compatible with OpenGL 2+ so it would work.
RE: _MOUSEMOVEMENTX & _MOUSEMOVEMENTY: Very broken ATM which means you cannot make first person mouse navigated content in the latest versions of QB64.
If I wanted to implement lighting using _MAPTRIANGLE I might do something like this in the code by MasterGy.
This code was a quick hack just to see what was possible and it may have flaws but the underlying concept should be sound enough.
Note that if the triangles are too big (like the floor from the code provided) it will be dark because all corners are a long way away from the player. Breaking the floor into multiple triangles would fix this problem. Performing SQR math on each triangle vertex is computationally expensive and a lookup table of SQR results may improve performance.
Add this code to MasterGy's code to see how this concept works:
somewhere in the init phase...
b = x / 2
h = b + n
l = b - n
Change _MAPTRIANGLE (sx1, sy1)-(sx2, sy2)-(sx3, sy3), pictri(triangles(actual_triangle, 3)) TO(wx1, wy1, wz1)-(wx2, wy2, wz2)-(wx3, wy3, wz3), , _SMOOTH to...
_MAPTRIANGLE (sx1
, sy1
)-(sx2
, sy2
)-(sx3
, sy3
), pictri
(triangles
(actual_triangle
, 3)) TO(wx1
, wy1
, wz1
)-(wx2
, wy2
, wz2
)-(wx3
, wy3
, wz3
), , _SMOOTH
d1
= SQR(wx1
* wx1
+ wy1
* wy1
+ wz1
* wz1
) d2
= SQR(wx2
* wx2
+ wy2
* wy2
+ wz2
* wz2
) d3
= SQR(wx3
* wx3
+ wy3
* wy3
+ wz3
* wz3
)
b1 = d1 / 3
b2 = d2 / 3
b3 = d3 / 3
b3 = b3 - ((b1 + b2) / 2) + 256
b1 = b1 * 2
b2 = b2 * 2
_MAPTRIANGLE (b1
, 256)-(b2
, 256)-((b1
+ b2
) / 2, b3
), lightmap33
TO(wx1
, wy1
, wz1
)-(wx2
, wy2
, wz2
)-(wx3
, wy3
, wz3
), , _SMOOTH