Add browser support

[OTArchive]

Description

Support compiling to javascript and webassembly using Emscripten.

Compiling guide (PT-BR): Guia ‐ OTClient Redemption Web

Notes:

• Changed some .lua files encoding from UTF8-BOM to UTF8 (incompatible with browsers);
• Lua 5.1 is back (only when using emscripten), Luajit is incompatible with browsers;
• Changed .bit operations to a lua implementation (Lua 5.1 incompatible); Now using bitlib;
• Fixed some file names causing case-sensitivity issues (incompatible with browsers and unix systems).
• Currently only works with protocols that use http login servers

[gesior]

@OTArchive
It's the best merge into OTClient since OTCv8 source went public (otcv8-dev).
It should be merged as soon as possible (fix Builds).
We can drop LuaJIT and Lua 5.1+ features just to get client being able to run on website. It can change Tibia and OTSes forever.

[divinity76]

Great job!
do you actually have a functional test build?

Edit: damn yes seems so: https://demo.otarchive.com/

[divinity76]

The tibia protocol is a custom binary protocol not compatible with the socket APIs available in javascript (webSocket, XMLHttpRequest, fetch) ... do you have a plan for dealing with that? A websocket<->TCP proxy could work.. (but it will be able to steal all usernames/passwords of tibia 7.6 and older clients, possibly newer protocols too, soooo there's that)

[OTArchive]

The tibia protocol is a custom binary protocol not compatible with the socket APIs available in javascript (webSocket, XMLHttpRequest, fetch) ... do you have a plan for dealing with that? A websocket<->TCP proxy could work.. (but it will be able to steal all usernames/passwords of tibia 7.6 and older clients, possibly newer protocols too, soooo there's that)

It's already mentioned in the guide, but in Portuguese: yes, we can use proxies. I've setup my testing server using websockify.
Check out this video showing the demo and then the modular version connecting to my server:
https://www.youtube.com/watch?v=sGuYmr728eY

[conde2]

Amazing contribution, here is my short.review

Would be better to have the bit implementations to be C++ binds instead of this Lua class, and only fallback to those C++ implementations when not using LuaJit

[divinity76]

Amazing contribution, here is my short.review

Would be better to have the bit implementations to be C++ binds instead of this Lua class, and only fallback to those class when not using LuaJit

why do you care? are you worried about performance?

not really sure why we're using the bit library anyway tho, quoting https://www.lua.org/manual/5.3/manual.html#3.4.2

 Lua supports the following bitwise operators:
    &: bitwise AND
    |: bitwise OR
    ~: bitwise exclusive OR
    >>: right shift
    <<: left shift
    ~: unary bitwise NOT

seems lua support the standard bitwise operators,

so does that mean

return Bit.operation(g_window.getKeyboardModifiers(), KeyboardCtrlModifier, Bit.AND) ~= 0

is better than

return (g_window.getKeyboardModifiers() & KeyboardCtrlModifier) ~= 0;

or

local bitsChanged = Bit.operation(now, old, Bit.XOR)

is better than

local bitsChanged = now & ~old;

? is it easier to read? more maintainable?

[conde2]

Some operations are very limited or not possible to implement in LUA only.

Moreover the project can only use Lua 5.1 because os the env system that is not present in other Lua versions.

So for making the bit operations more reliable it should be implemented as a C++ to Lua bind

[OTArchive]

@conde2 @divinity76

• I've implemented bitlib so we have the same bit operations as Luajit;
• Removed a few includes from the original bitlib code so I've also added the lib files in the commit;
• Restored .lua files to their original usage of bit operations.

Should we also include Lua 5.1 code and precompiled lib in the repo, as it is not available in vcpkg?

[conde2]

That's look a good solution, we also avoid new contributors to be confused why to not use default lib functions.

About including Lua 5.1 what other options we have? Nonetheless I will leave this decision to @mehah and others contributors.