feat: 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. Now also supports older protocols.

[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.

[divinity76]

Just another nitpick, but it's something all C/C++ developers should use a little time to think about wrt coding style IMO,

While the choice between

char* str;

and

char *str;

is technically a personal preference thing, the latter is objectively better.

Take a look at this bugged code:

char* str1, str2;

Do you see the problem? It’s easy to miss. Now, let’s try it with the alternative style:

char *str1, str2;

See it now? It's easier to see the bug with style 2.
They declare str1 as pointer to char, and declare str2 as a single char... , when it was meant to be declare str1 as pointer to char, and declare str2 as a pointer to char

Fixing it, following coding style 1, it gets written as

char* str1, *str2;

that looks... strange, doesn't it? compare that to style 2,

char *str1, *str2;

looks much better imo,

and that is why, imo, we should all default to the style char *str instead of char* str :)

ChatGPT can probably explain it better than me:

(...) The * being next to the variable name emphasizes that the pointer is an attribute of the variable, not the char type itself. (...) it's immediately clear that the * applies to the variable, not the type. (...) So overall, I favor the char *str style for the same reasons you mentioned: readability, reducing confusion, and making the code less error-prone

(just a nitpick)

[gesior]

Just another nitpick, but it's something all C/C++ developers should use a little time to think about wrt coding style IMO,

Is this problem related to this MR or whole repository?

Can it be configured by .editorconfig (https://github.com/mehah/otclient/blob/main/.editorconfig) file somehow?

In PHP there is well known code-standard PSR-12 ( https://www.php-fig.org/psr/psr-12/ ), which replaces old standards PSR-1 ( https://www.php-fig.org/psr/psr-1/ ) and PSR-2 ( https://www.php-fig.org/psr/psr-2/ ).
PSR-12 fixes all possible problems (without forcing to reformat most of old code), so every PHP programmer uses it.

I've tried multiple C++ 'standards' in CLion:

but all of them forces something different than TFS code format and all these formats looks weird.

FYI default CLion format moves all * to attributes/parameters variables, not their types - same as you posted.

Anytime I post anything to 2020+ PHP project, I can press CTRL+ALT+L - auto formatting - in PHPStorm to make my PHP code compatible with project (PSR-x).
For every OTS/OTC C++ project. I have to mark just few lines I've edited. Format them and then fix formatting manually in CLion.

[OTArchive]

Compiling is now streamlined and also uses vcpkg.json, so no need to install dependencies with separate vcpkg commands. A proper cmake command is all that is needed.
Guide updated.

[gesior]

I think we can't keep this as PR forever. @OTArchive someday will get bored merging master over and over again and leave this branch unfinished.

If OTCR maintainers are not sure, if current version is stable enough/code is clean enough/build process is good enough (what about Lua 5.1/5.4/LuaJIT 2.1 compatibility on desktop version?), then maybe we can merge this branch into official branch browser or webclient?

Maybe then more people will test it, merge master, refactor code, simplify/document configuration.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud