Like the title says, the return value of :matmul, when passed true to indicate that the result should be stored in itself, is that same boolean value. This is inconvenient since it breaks method chaining. Here's a small repro as proof:
-- declare vector & metadata
local v = vec(1, 2, 3)
local m = userdata("f64", 3, 3)
m:set(0, 0,
1, 0, 0,
0, 1, 0,
0, 0, 1
)
-- ok, should return userdata
? "return type 1: "..type(v:matmul(m))
-- ok, stores result in copy
local vcopy = v:copy()
? "return type 2: "..type(vcopy:matmul(m, vcopy))
-- prints boolean, breaks chaining
local vcopy = v:copy()
? "return type 3: "..type(vcopy:matmul(m, true)) |
While working on a DOOM style 3D game, I came across what I'm fairly confident now is a bug in how tline3d uses the w0 and w1 parameters. To illustrate the issue (and because explaining what's happening is fairly difficult, I'm not certain myself exactly what's happening) I've created a reproduction cart which also contains an implementation of what I would have expected tline3d to do.
Press Enter or Start to toggle between the builtin implementation and my own.

DOOM clone (WIP)
Early WIP of a DOOM-like 3D game, which I've simply named "DOOM clone" for now.
Controls
Primary stick: Move
Secondary stick: Look (also mouse)
Left/Right Bumper: Cycle through video modes
P: Toggle CPU usage
Changelog
Revision 2 (July 9th 2025)
Added ability to draw models made of textured triangles.
Revision 1 (June 27th 2025)
Added floors and ceilings and a performance counter.
Initial release
Walls & basic movement are in, no collision yet.
Plans
I'm not sure what I want to do with this tech yet, but I knew the first step was to actually make a few functions that can draw the required 3D primitives. The engine can so far draw dots, bars, and walls in 3D space. The walls are perspective correct and get clipped by the near plane so there's no glitching when looking at walls from close up or at acute angles or anything. Primitives that are completely behind the camera even get culled.

Maybe a bit of a niche feature request, but it would be nice if we had memset variants for blocks of values that take up multiple bytes, like how peek & poke now have variants for i16, i32, and i64 with peek2/poke2, peek4/poke4, and peek8/poke8 respectively. As it stands, initializing/filling a memory-mapped block of n values of anything other than bytes requires n instructions plus the cost of a for loop, so having the ability to reduce that to a single function call would be a great boon!






0 comments