Axmol-v3 Roadmap

[halx99]

• ISO c++23 standard
• Implement d3d12 RHI
• Implement d3d11 RHI(experimental)
• Implement vulkan RHI(experimental)
• Add experimental VR render (Migrated from cocos2d-x-3.17.2 but with improvements, new cmake option: AX_ENABLE_VR, by default OFF in cmake)
• Add linux wayland support with new cmake option AX_ENABLE_WAYLAND
• Add high DPI support windows and linux
• Add high DPI support for WebAssembly
• Texture resource improvment, add texture array support, remove CPU array implement since all graphics API support texture array
• Remove sampler from Texture, implement texture sampler object and cache it, since GLES3/OGL-3.3, mtl, d3d support sampler object
• Update lua to 5.5.x
• Remove the default pixel format, fix rendering of grayscale PNGs by @j-jorge in Remove the default pixel format, fix rendering of grayscale PNGs #2573
• 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
• 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: r23 => latest LTS release r27
• 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
• Remove Color3B
• Remove deprecated StringUtils::format
• drop GLES 2.0 support since all Android 5.1+ devices support opengl-es-3.0
• Improve axslcc preprocessors, remove METAL, GLES2, then add AXSLC_TARGET_[GLSL,HLSL,MSL,GLES]
• Improve VertexLayout management
• Improve sampler2D texs[4] support, 2.x only support OpenGL, now support all RHI: d3d11, metal, opengl(es)
• Reimplement core/physics with box2d v3, not all API compatible with axmol-2.x (incomplete)
  • basic functionals
  • Rename PhysicsJointXXX::construct => PhysicsJointXXX::instantiate
  • b2ContactListener
• Follow simdjson 4.x
• Rewrite JsonWriter no longer depends on rapidjson
• drop tolua, looking other solution
• Choose shader for more render objects like Sprite
  • ParticleSystemQuad
• enum definitions rule: use PascalCase for non-abbreviation enums, and ALL_CAPS for abbreviation-based enums.

-------- Issues ------

• EsotericSoftware/spine-runtimes support (see also Errors that i found migrating my game to V3 (dev) #2808)
• see Errors that i found migrating my game to V3 (dev) #2808

[kiranb47]

@halx99 Any plans for Vulkan RHI?

[halx99]

@halx99 Any plans for Vulkan RHI?

Currently, there are no short-term plans to implement Vulkan RHI. It’s something we may consider in the future depending on priorities and resources.

[halx99]

@halx99 Any plans for Vulkan RHI?

Now, the vulkan RHI implementation in-progress.

[halx99]

@halx99 Any plans for Vulkan RHI?

Now, the vulkan RHI implementation in-progress.

The vulkan RHI PR was merged, 99% cpp-tests works as expected. windws/linux is well tested, and android also tested

[NgVThangBz]

how start with windows vulkan ?

[halx99]

refer to: https://github.com/axmolengine/axmol/blob/dev/.github/workflows/build.yml#L82

[paulocoutinhox]

Hi. Can i start a new project using physics for platform things and v3?

[halx99]

Hi. Can i start a new project using physics for platform things and v3?

The v3 physics 2d is not ready

[NgVThangBz]

@halx99 why need to remove AsyncTaskPool?
is there any problem if I add it myself and continue using it?

[halx99]

Yes, you can continue use it

[j-jorge]

Here are a couple of things I would love to have in Axmol. Maybe in v3, maybe later (or even before!). Take it as a wish list for discussion :)

• Shorter build times. Axmol takes forever to compile, so much that I refrained to contribute on multiple occasions :( Unity builds could help, I had already arranged some files for it and it made the compilation of a subset of Axmol twice faster (PR #1266). As a general observation I think too many files include too many things.
• The ability to allocate ax::Object and derived types on the stack, or as aggregated members in my classes. All ax::Object must be allocated dynamically. I can't even use a pool and placement new on any of these classes.
• The removal of reference counting. It makes the architecture harder to follow, as no part of the app is responsible of any object. Things may still be in memory even when the part that actually owns them is removed. Plus, it is inefficient and cumbersome. There should be a clear responsibility about who owns what, and the rest should use references or pointers. I believe managing the memory is part of the development and should not be let loose.

[grif-on]

• We have prebuilts workflow .
  My notes on setting up axmol - prebuild engine , VSCode and LUA debugging #1989
  Compile the engine once and all your game projects will compile in a few minutes .
  Sure it sucks to spend hour or two when you update your local repo with the engine .
  But you don't need to do this often - 2.x minor releases happen once per month +- .
  And your custom engine changes should be sped up by the local cache .
  The only downside is that the prebuilts workflow has only been tested to work on windows right now .
  If you want to help , you can implement and test the prebuilts workflow for linux/mac . Iirc linux already have some progress on this feature implementation .
• I'm not experienced enough to comment on the second one .
• Oh god .
  You doesn't even talk about replacement of manual reference counting with shared pointers (which will have it's own pros and cons) . As far as i can tell , you want to have raw pointers ...
  How game developers would track memory leaks then ?
  Right now , forgetting to release() some axmol resource is an error of the same severity as you would forget to delete some vanilla C++ resource . But the difference between release() and delete is that reference counting allows you to easily find a leaked resource with Object::printLeaks() (this function call are even already set up in main.cpp of windows/linux/mac , all you have to do is to change AX_OBJECT_LEAK_DETECTION macro) .
  The price is one simple varable increment/decriment (extremely fast when leak detection disabled) and manual "marking" that resource are needed or no longer needed by someone .
  I'm not the fan of this manual "markings" either (more specifically , the fact that there is implicit autoreleases) . But raw pointers are even worse for complex things like games .

[j-jorge]

Thanks for the reply. I am not interested in prebuilt libraries as I have a couple of patches to apply on each release. Plus I compile Axmol in debug, release+IPO, and also with AddressSanitizer and ThreadSanitizer. In other words, I intentionally build Axmol from source to get what I want. Moreover, I cannot emphasize this enough, this is a major pain to contribute to Axmol. This is compilation time we have to pay on all programmers' computers but also on the CI, and there's no benefit of having compilation taking longer than necessary.

Oh god.

Feel free not to participate in the discussion if your goal is to be contemptuous.

How game developers would track memory leaks then ?

LeakSanitizer is a thing, it works well and is enabled with AddressSanitizer by default. Valgrind is a thing, it works well too. Both are better than any leak detector integrated in Axmol. They will even find leaks for types not derived from ax::Object. Amazing.

std::unique_ptr is okay for ownership. Raw pointers are okay for non-owning pointers. std::shared_ptr is as problematic as current reference counting: unclear ownership, stuff floating around in memory because they are still referenced somewhere even if they should not be there. At least with std::shared_ptr we would not have to deal with those retain()/release() calls, and we would not need stuff like ax::Vector.

Plus, the solution you suggest with AX_OBJECT_LEAK_DETECTION is yet another build of Axmol. Please refer to the first point.

[NgVThangBz]

@halx99 can run pr with d3d12?

[halx99]

im try run that but: "Failed to create PSO" in RenderPipelineImpl::updateGraphicsPipeline im create new pr and run: axmol -p win32 -a x64 -xc '-DAX_RENDER_API=d3d12' -O0 to build debug, build OK but when run .exe or run in VS crash

Chould you try download artifacts from github ci to test does the cpp-tests.exe works?

https://github.com/axmolengine/axmol/actions/runs/19712820674/artifacts/4689600557

[NgVThangBz]

@halx99 im copy all dll form the link and paste to my folder, my exe will run ok
but during running, the crash rate is high, but the reason is unknown
I have the same problem with vulkan
but d3d11 works ok,

[aismann]

@NgVThangBz
I unzipped the artefacts and run the cpp-tests.exe without any problems.
Can you try the same on your side (start cpp-tests.exe from the unzipped artefacts folder)?

[aismann]

Update:
cpp-tests crashing on 30: Label => 61: Shrink content Test: Word Wrap

[halx99]

Update: cpp-tests crashing on 30: Label => 61: Shrink content Test: Word Wrap

It's a known issue, fixing in my local machine

[halx99]

I create a empty project with axmol new HelloCpp , then run axmol run -xc "-DAX_RENDER_API=d3d12" -O0, everything works fine:

[NgVThangBz]

Error: "Failed to create PSO"
Is it because of my device environment?
work ok with: Vulkan, d3d11, OpenGL
but d3d12 not work