Axmol-v3 Roadmap

[halx99]

• ISO c++23 standard
• Implement d3d12 RH(experimental)I
• 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]

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

[kiranb47]

Hey @halx99 We have tested V3 Vulkan version on Android devices, we are seeing improved perfomance in latest Samsung S23 series. But crashing in some of the old devices.

I have attached crash log.
solitaire_vulkan_crash.txt

[kiranb47]

Samsung s21 FE
Model: SM-G990E/DS
Android 15

[halx99]

@kiranb47 I don't have this device to reproduce the issue, from your crash traceback, it caused by VkCreateDevice fail.

[halx99]

I create an issue to track this crash problem: #2947

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

here is my log
log.txt

windows: 11 pro

[halx99]

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

And if you can build cpp-tests via visual studio, enable debugLayer like follow:

The driver will report more detail information why Failed to create PSO

seems some of your shader invalid:

D3D12 ERROR: ID3D12Device::CreateInputLayout: Input Signature in bytecode could not be parsed.  Data may be corrupt or in an unrecognizable format. [ STATE_CREATION ERROR #63: CREATEINPUTLAYOUT_UNPARSEABLEINPUTSIGNATURE]
D3D12 ERROR: ID3D12Device::CreateVertexShader: Vertex Shader is unsigned or a preview shader and experimental shader models are not enabled, or shader is otherwise corrupt. [ STATE_CREATION ERROR #67: CREATEVERTEXSHADER_INVALIDSHADERBYTECODE]
D3D12 ERROR: ID3D12Device::CreatePixelShader: Pixel Shader is unsigned or a preview shader and experimental shader models are not enabled, or shader is otherwise corrupt. [ STATE_CREATION ERROR #93: CREATEPIXELSHADER_INVALIDSHADERBYTECODE]

[halx99]

@NgVThangBz Please check your axslcc version >= 3.3 and rebuild all your shader for d3d12

[NgVThangBz]

@halx99
i update all, and retry, but same error:
log.txt

[halx99]

@NgVThangBz Hi, thanks for your report, I’ve opened a PR to address your issue: #2955
You can fetch and checkout the dynamic-detect-dxc branch to test it before the merge.
Please let me know whether it works for you.

[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 :)