Axmol-v3 Roadmap

[halx99]

• ISO c++23 standard
• Integarte OpenXR to support PC VR HMD devices, see PR: Add OpenXR-backed VR scene composition and XR controller input #3220
• Switch 3d physics backend from BulletPhysics to JoltPhysics, see PR: Refactor physics modules and migrate 3D physics from Bullet to Jolt #3124
• Enhance Text Rendering with Apple HVF (PingFangUI.ttc) support, see PR: Enhance Text Rendering with Apple HVF (PingFangUI.ttc) support #3118
• Implement d3d12 RH(experimental)
• Implement d3d11 RHI(experimental)
• Implement vulkan RHI(experimental)
• Implement Dynamic RHI (1/6/2026)
• Add linux arm64 build support
• Add windows arm64 build support
• Make the ImGui extension work on all axmol supported platforms
• 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 ChipmunkTestbed 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
• Unify Input control: ui::TextField, TextFieldTTF, ui::TextFieldEx, see issue Refactor InputSystem #3168
• 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]

@kiranb47 I’ve created a branch diag-android-vk with additional logging for device creation failures. Do you have access to that device locally to build and run it for more detailed logs?

[halx99]

@kiranb47 I’ve created a branch diag-android-vk with additional logging for device creation failures. Do you have access to that device locally to build and run it for more detailed logs?

I plan to improve vulkan compatibility, you can track to PR #2967

[kiranb47]

Hey @halx99 We have tested diag-android-vk branch.
crash_vk_samsung_s23_ultra.txt
crash_vk_samsung_s21_fe.txt
crash_vk_samsung_s25.txt

Now crashing in all devices.

See attached.

[kiranb47]

Happy to test more

[halx99]

Happy to test more

Thanks, let's discuss at #2967

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

[grif-on]

Alright , now i see why you struggle with compilation time so much .
Such pipeline setup is sure quite complex and resource intensive . And way beyond my skill level .
You should have started from this .

And i never heard about LeakSanitizer .
Even though last time when i used /fsanitize=address in Visual Studio there were no leak detection functionality iirc . Maybe VS22 is too old for this .
UPD - Lol , i just rechecked AdressSanitizer in my Visual Studio , and it is really just doesn't have LeakSanitizer , which is even not my fault https://developercommunity.visualstudio.com/t/support-leaksanitizer/826620 .
I guess my view on a raw pointers are outdated .
But look at this from such perspective - you thought that knowing about LeakSanitizer is a common knowledge , which doesn't even deserve mentioning , and you even keep thinking like that judging by how you point out my blindness .
But here i am , being an example of otherwise . With my 4 years of casual C++ self learning and knowledge about some really bizarre debugging tools , like TTD , but not about LeakSanitizer .

>"Oh god" used in the discussion
>Go out here with this
I'm just didn't though of better way how to describe confusion , which your initial comment caused in me .

And you know what .
All that info which you provide now would be so much helpful in your initial comment .
Because i honestly was been shocked from idea "let's remove 15 years old core feature of this game engine , because it is cumbersome , while raw pointers are better for code readability" . The feature which from my perspective (and i guess many others) , were still useful as heck .
If your initial comment had at least mentioning of your pipeline and LeakSanitizer , i would learn something new for me without posting comment that leads to this awkward "no your advice is not professional enough" situation .

[halx99]

Well, actually, I'm developing a generic memory leak detection tool personal:

[UltraLeakDetector] ==== Memory Leaks (1) ====
[Leak] ptr=000001FF3B783480 size=128 thread=14156 type=NORMAL
  0>C:\Program Files (x86)\Windows Kits\10\Source\10.0.26100.0\ucrt\heap\malloc.cpp(27): ((malloc)+0x1f)        0000000401070ACF
  1>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\heap\new_scalar.cpp(36): ((operator new)+0x13) 00007FF76067D1A3
  2>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\heap\new_array.cpp(30): ((operator new[])+0x13)        00007FF76067E253
  3>D:\dev\simdsoft\axmol3\tests\lua-tests\proj.win32\main.cpp(40): ((axmol_main)+0x41) 00007FF75E81AE81
  4>D:\dev\simdsoft\axmol3\tests\lua-tests\proj.win32\main.cpp(64): ((main)+0x1e)       00007FF75E81AF1E
  5>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): ((invoke_main)+0x39)       00007FF76067E199
  6>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): ((__scrt_common_main_seh)+0x132)  00007FF76067E082
  7>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): ((__scrt_common_main)+0xe)        00007FF76067DF3E
  8>D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): ((mainCRTStartup)+0xe)       00007FF76067E22E
  9>((BaseThreadInitThunk)+0x17)        00007FFE4A2CE8D7
  10>((RtlUserThreadStart)+0x2c)        00007FFE4BAAC53C

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

@halx99 The app opens the first time, but after 1-2 minutes of use, it crashes.

D3D12: Removing Device.
Assert failed: SwapChain Present failed
Assertion failed!

[halx99]

Assertion

The code will print reason number, so what's the reason number?

[halx99]

@NgVThangBz could you also enable debug layer, and upload full debug output?

[halx99]

I also install same driver version with you, but still can't reproduce your issue:

I/[2025-12-21 23:23:42.444][PID:3bec][TID:2584]
{
	axmol.build_type: DEBUG
	shader: HLSL Shader Model 6.0 (DXC)
	axmol.testcpp.autorun: false
	supports_OES_depth24: true
	max_texture_size: 2048
	axmol.texture.pvrv2_has_alpha_premultiplied: false
	supports_BGRA8888: true
	supports_ETC1: false
	max_vertex_attributes: 32
	supports_vertex_array_object: true
	axmol.3d.animate_quality: 2
	axmol.3d.max_spot_light_in_shader: 1
	max_texture_units: 128
	supports_discard_framebuffer: false
	supports_S3TC: true
	version: D3D12-32.0.15.6094
	axmol.3d.max_point_light_in_shader: 1
	supports_OES_map_buffer: false
	supports_OES_packed_depth_stencil: true
	axmol.compiled_with_profiler: false
	renderer: NVIDIA GeForce RTX 2060 SUPER D3D12 DXC SM6.0
	window.platform: Win32
	supports_ASTC: false
	axmol.gl.projection: 3d
	max_samples_allowed: 8
	axmol.version: 3.0.0-88f7e82
	supports_ETC2: false
	vendor: NVIDIA
	axmol.texture.pixel_format_for_png: rgba8888
	supports_NPOT: true
	supports_ATITC: false
	axmol.fps: 60
	supports_PVRTC: false
	axmol.compiled_with_gl_state_cache: true
	axmol.3d.max_dir_light_in_shader: 1
	axmol.simd: SSE41
	axmol.display_fps: true
}

[halx99]

I also create an issue: #2965 for this problem.

[NgVThangBz]

d3d11 cant resize window,
if change size windows content inside will deviated

[halx99]

d3d11 cant resize window, if change size windows content inside will deviated

Fixed by d2d75c1

[aismann]

d3d11 cant resize window, if change size windows content inside will deviated

Fixed by d2d75c1

Tested! Resize works correct.

[solan-solan]

@j-jorge

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.

But autorelease/retain/release is part of engine architecture. And it could not be just discard without effecting customer code.
The idea that there is no pointer owner as such. For example:

1. I create some object and keep its pointer as Scene derived class child
2. One time this pointer is passed to the Action derived class which run for another object
3. The created object is deleted from the Scene
4. The Action object try access to the invalid pointer inside its destructor for example

Anyway similar cases can be very frequent. And there should be mechanic to process it in the engine. Why not to use this one which exists already

[grif-on]

Thanks .
This is essentially what i tried to say (about affecting engine's end users and frequent cases when refference counting or something more than raw pointer are actually required) , but failed to do so 😅

[solan-solan]

To simplify understanding of this approach it is useful to remember just one : you have one reference after object creation. The object will be destroyed if it would not be assign to some parent after creation through autorelease. If you assign it to some engine object via appropriate api than the engine is responsible for reference counting. If you assign it to some own class object with your own api, than you are responsible for reference counting

[j-jorge]

I get how it works but I believe it's over complex. Some nodes have to survive their owner and may be legitimately floating around until something happens, but it is only some nodes, not all nodes. Actually, what percentage of the objects in any given app require shared ownership? I believe in my app it's close to zero. In Axmol and Cocos2d-x everything goes into this mechanism, I think it should be an opt-in :)