Working in-progress v3

[halx99]

Describe your changes

Previous working PR #2204 was closed due to branch name renamed from 3.x to wip-v3

• Remove all deprecated stubs
• Implement drawArraysInstanced and make instanced draw more common use
• box2d-3.x
  • Make Box2dTest of cpp-tests works on box2d v3
  • Make Box2dTestBed of cpp-tests works on box2d v3
• Remove chipmunk
  • Remove core/physics based on chipmunk
  • Remove ChipmunkTest from cpp-tests
  • Remove ChipmuniTestbed from cpp-tests
• Change underlaying color type to Color4F aka ax::Color
• Improve DrawNode, don't create backend::Buffer always
• Upgrade iOS deploy target: 12.0 ==> 13.0
• Upgrade android minsdk: 17(Android 4.2) ==> 21(Android 5.1)
• Upgrade android ndk: r23d ==> r27c
• Due to android,ios toolchain update to support c++20 full features, std::views::split can be use to improve performance
• Remove 3rdparty ghc filesystem, since both ios13 and android5.1 support std::filesystem
• Build and run wasm64 support, current need enable chrome flag: chrome://flags/#enable-webassembly-memory64
• Color4B ==> Color32
• Reimplement core/physics with box2d v3, not all API compatible with axmol-2.x (in-progress)
• re-select json lib: yyjson > boost.json > rapidjson
  simdjson for parse only and simdjson build in-progress: https://github.com/simdjson/experimental_json_builder
  finally solution: yyjson + simdjson
• drop rapidjson
• Remove Color3B
• drop tolua, use sol2

Issue ticket number and link

Checklist before requesting a review

For each PR

• Add Copyright if it missed:
  - "Copyright (c) 2019-present Axmol Engine contributors (see AUTHORS.md)."

• I have performed a self-review of my code.

  Optional:

  • I have checked readme and add important infos to this PR.
  • I have added/adapted some tests too.

For core/new feature PR

• I have checked readme and add important infos to this PR.
• I have added thorough tests.

[paulocoutinhox]

Version 3 don't will be published with PhysicsBody replacement?

[halx99]

version 3 still in early status, and should contains physics2d when publish.

[paulocoutinhox]

Will be nice if we have a single json library easy to use, like nlohmann/json instead of two.

[halx99]

Will be nice if we have a single json library easy to use, like nlohmann/json instead of two.

The nlohmann/json easy to use, but performance not good.

[danialias]

I need rapidjson performance as well, please do not remove 😅

[paulocoutinhox]

I don't understand how a JSON lib in a game engine needs such an absurd performance, since things like that are used in few moments, like loading or saving things at specific times.

In our app (Ubook) that uses JSON all the time and processes thousands of JSON data with thousands of records, the processing is instantaneous, even in huge JSON data and we use nloman/json. Before we used rapid, but it doesn't have as many features, requiring other libs to be used and more things to be maintained, decreasing efficiency in exchange for NOTHING.

For me, it would make sense to keep a single lib that is easy to use and that for our scenario here at Axmol, will not affect anything in practice.

Here is my opinion based on my reality as someone who uses this in practice and in large volumes, both on Android and iOS, as well as on Apple Watch and Apple TV and also on the desktop.

[rh101]

I need rapidjson performance as well, please do not remove 😅

If it is removed from Axmol, then you can easily add it into your own projects with a few lines of CMake code, and nothing else has to change in your projects.

[rh101]

I don't understand how a JSON lib in a game engine needs such an absurd performance, since things like that are used in few moments, like loading or saving things at specific times.

Your projects may not require the speed of libraries like rapidjson, but that may not apply to projects by others, since they may have completely different requirements.

In our app (Ubook) that uses JSON all the time and processes thousands of JSON data with thousands of records, the processing is instantaneous, even in huge JSON data and we use nloman/json. Before we used rapid, but it doesn't have as many features, requiring other libs to be used and more things to be maintained, decreasing efficiency in exchange for NOTHING.

There are cases where the speed of parsing needs to be as quick as possible, such as in event handlers, comms response handlers, etc. etc.. In these cases, speed definitely does matter, and it is quite noticeable if the parsing takes too long.

For me, it would make sense to keep a single lib that is easy to use and that for our scenario here at Axmol, will not affect anything in practice.

That may be the case for your own projects, but again, it may not apply to projects by others. Also, just because a specific library works for you, it doesn't mean that it is appropriate for it to be used in Axmol.

Here is my opinion based on my reality as someone who uses this in practice and in large volumes, both on Android and iOS, as well as on Apple Watch and Apple TV and also on the desktop.

That's all well and good, and as you stated, your opinion is based on the requirements of your own projects, but it's not really appropriate to make statements about what other developer should or shouldn't use in their projects, because you really don't know what their requirements are.

The engine should bundle whatever json library (or libraries) it requires, but that in no way forces the developers using Axmol to also use those libraries. Developers are free to use whatever library they want to use.

On a side note, many developers who use Axmol for their released projects have never posted on this discussion board, and may not even read these threads, so unfortunately, it would be hard to get their feedback on such things.

[halx99]

Finally, maybe yyjson, speed fast and support read/write and dom style APIs, axmol can make a thin c++ wrapper

[iAndyHD3]

The problem with nlohman/json is not only its lack of runtime speed but it's also a huge >10k thousand long header only library, making compilation also slower. its really one of the worst options you can choose. In modern C++ there is a clear new winner in my opinion: glaze is a modern C++ json library with automatic serialization/deserialization, making it really convenient for simple use cases. The performance is on par with simdjson. For non reflection uses, there is generic json which is similar to nlohman in that regard.

There are a few cons, thought:
it only supports c++23
Needs recent compiler versions
Not sure if it has been tested in platforms like wasm, ios

[paulocoutinhox]

Hi,

Glaze is nice too. Their syntax is like nlohman/json and is easy to use.

My concern is always to keep the engine as easy as possible for people to use. It's better to use Glaze, which already does everything, than to have to adopt several libraries and increase complexity, lowering the barrier to entry.

[halx99]

I tried glaze, but compile fails
EDIT: seems it fix msvc compile issues recently