On 32-bit platforms, full-lightuserdata is always supported since their pointer fits entirely in 2^48 limitation that LuaJIT had in older version.
Also suppress warning about key > 0x20000000000000ULL is always false on enet.cpp when compiling on 32-bit platforms.
When a fused löve executable is signed with codesign on Windows some
data is appended to the executable, preventing physfs from finding the
zip file at the end of the file.
To help physfs out a bit, we try to find the zip ourselves in the case
of regular mount failure by looking for it's characteristic end of
central directory record and, once found, pretend to physfs that the
file is shorter than it actually is and ends at the end of the zip file.
Apparently geting alignment right pre-C++17 is not easy.
Well, 2^32 fits entirely in Lua "double" 2^53 so it's fine
to assume alignment of 1.
Fixes#1916.
love.graphics.newVertexBuffer and newIndexBuffer don't do enough to justify their existence since love.graphics.newBuffer already covers all buffer creation functionality.
1-based indices in newIndexBuffer versus 0-based indices in newBuffer(..., {index=true}) was also confusing.
They don't do what most people might assume they do (they happen at the same time as the user completes a drag-and-drop operation and they surround the dropfile events, instead of starting when the user initiates the operation). Also their functionality can be replicated without needing dedicated love event callbacks.
It was being set all the time because of a code bug, but also documentation recommends using it very sparingly - partly because systems have a hard limit on the number of individual allocations (and they can also be a lot slower).
We might want to revisit more selective use of the flag in the future.
There is little to no performance gain, with a lot of burden
to maintenance of the extra path. It's better to unify the code
with the other render pass logic.
Sasha Szpakowski
ImagicTheCat
Miku AuahDark
Joel Schumacher
EngineerSmith
scurest
Klonan
niki