Init feature: Sprite from SVG files

[aismann]

Describe your changes

New Feature: Sprite from SVG files

History:

• Started with an own SVG parser/renderer
  => Aborted: To much effort and maintenance in the future of Axmol lifecircle
• Tested nanosvg (memononen/nanosvg: Simple stupid SVG parser)
  Good rendering but not all was as expected.
  => Aborted: This project is not actively maintained.
• plutosvg/plutovg:
  => Seems to be a good 3rdparty lib for feature “Sprite from SVG files”
  but we let it still experimental!

Issue ticket number and link

#3243

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.

Axmol 3.x ------------------------------------------------------------

For each 3.x PR

• Check the '#include "axmol.h"' and replace it with the needed headers.

[aismann]

/clang-format

[cla-assistant]

All committers have signed the CLA.

[aismann]

@halx99
Please check/edit the 3rdparty "cmake stuff" of plutosvg/plutovg (Im using the "orginal" but its to much there).
Thanks.

[aismann]

/clang-format

[aismann]

Add some SVG files to the axmol-sample-assets:
axmolengine/axmol-sample-assets#5
@halx99
Please merge it. Thanks.

[rh101]

Can this feature be optional, enabled by a cmake option? I just noticed the option(AX_WITH_SVG "Build with internal SVG support" ON)

I personally feel that it should be off by default, and if it becomes widely used, then that would be a reason to set it to on by default later.

Also, in Image.h/cpp, there should be a check if it is enabled in the cmake options. At the moment there doesn't seem to be any checks at all, so it will result in a build error if SVG is disabled. Also, it doesn't seem like a good idea to have to change both a cmake option and config.h; there should be only one place to enable and disable it.

[halx99]

Can this feature be optional, enabled by a cmake option? I just noticed the option(AX_WITH_SVG "Build with internal SVG support" ON)

I personally feel that it should be off by default, and if it becomes widely used, then that would be a reason to set it to on by default later.

I agreed.

[halx99]

And I think SVG support should becomes an optional Axmol extension and is disabled by default.

[rh101]

And I think SVG support should becomes an optional Axmol extension and is disabled by default.

Having it as an extension would make more sense.

[aismann]

And I think SVG support should becomes an optional Axmol extension and is disabled by default.

Having it as an extension would make more sense.

I agree too!

[aismann]

Planned changes:

• plutsvg/plutovg be still part of the 3rdpary folder
  => But will be clipped on/off via settings (e.g. cmake or config.h)

• Axmol svg stuff will be add as extension
  => need some more redesign

Another, easier way! is to switch on/off via #defines like its used for platforms or other extensions:
e.g:

#if AX_ENABLE_EXT_IMGUI
...
#endif

=> No big changes needed (only hide SVG source snippet on class sprite/images/...)

#if AX_WITH_SVG ...  (or any other name like: AX_ENABLE_EXT_SVG)
 ...
#endif

@rh101 , @halx99
What are you think? I prefer for switch on/off via #defines

[rh101]

What are you think? I prefer for switch on/off via #defines

That won't stop the 3rd party SVG library from being built. The whole point is that we have a way to enable or disable the building of the library, otherwise it will take more time to build and wasted space in the final binary.

The cmake option to enable/disable the 3rd party SVG library should control everything. Enabling this should automatically add a define to enable the Axmol-specific SVG support in Image.h/cpp, cpp-tests etc. etc., which means a separate pre-processor definition isn't required in config.h. It is unlikely that a developer would enable the SVG library compilation and linking if they are not planning to use the SVG support in Axmol.

For example, in /3rdparty/CMakeLists.txt, something like:

if(AX_WITH_SVG)
  ax_add_3rd(plutovg)
  ax_add_3rd(plutosvg)
  target_compile_definitions(${_AX_CORE_LIB} PUBLIC AX_USE_SVG=1)
endif()

Does that make sense?

[aismann]

The cmake option to enable/disable the 3rd party SVG library should control everything. Enabling this should automatically add a define to enable the Axmol-specific SVG support in Image.h/cpp, cpp-tests etc. etc., which means a separate pre-processor definition isn't required in config.h. It is unlikely that a developer would enable the SVG library compilation and linking if they are not planning to use the SVG support in Axmol.

Does that make sense?

@rh101
Correct. Using one place only makes sense.
config.h changes will be removed.

[halx99]

AX_WITH_XXX options are internal and undocumented, and should not be used as user-facing feature switches. Third-party dependencies should instead be enabled automatically based on Axmol feature options such as AX_ENABLE_EXT_XXX.
Actually, I also plan to gradually remove the existing AX_WITH_XXX options over time.

[rh101]

@aismann I received a request for review notification, but I'm not sure why, since nothing has changed since the earlier conversation. Was the review request accidental?

[aismann]

@aismann I received a request for review notification, but I'm not sure why, since nothing has changed since the earlier conversation. Was the review request accidental?
@rh101
I only add you to the reviewer group. Thats often done before the review is starting.

[halx99]

/clang-format

[axmol-bot]

❌ Formatting failed. Please check the GitHub Actions logs for details.

[halx99]

/clang-format

[aismann]

@halx99
All core features should be enabled when building cpp-tests,
SVG support is not ON on cpp-tests:

[halx99]

I prefer implement svg support as extension feature currently.

[halx99]

This PR still needs to be redesigned to avoid unnecessary intrusion into and complication of the core architecture.

[aismann]

This PR still needs to be redesigned to avoid unnecessary intrusion into and complication of the core architecture.

The goal of this PR is/was to show an effektive way for the feature: create sprites from SVGs.
Axmol v3 has so much redesigns, thats only one more.
@halx99
Make the needed changes plz.
New features have often a redesign!
About the redesign:
Please think about gif (or any other movie frame) support too.
GIFs (or movie frames) can handle eg. like ax::SpriteFrame.

[halx99]

I kept this PR focused on its original goal: providing a practical way to create sprites from SVG files.

The latest commits eeps the SVG implementation isolated in the ax::ext namespace. SVG can be loaded explicitly with createSVGSprite() or loadSVGTexture(), while the Core remains unaware of SVG-specific details.

This keeps the feature focused and provides a clean foundation for SVG support in Axmol v3.

[halx99]

I’ve finished my work.

[aismann]

My point of view:

1. Its works

2. I miss the nice feature: ax::Sprite::create("aNiceSVGfile")
   => auto selection of the right encoder for 'svg' files like for 'bmp', 'png', '...' which use also only: ax::Sprite::create("...");

   => PR can be merged ;)

Another issue:
I switch also the 'AX_ENABLE_EXT_EFFEKSEER = ON'
and get this warning during build:

[halx99]

@aismann Thansk for you testing, @rh101 do you have any other suggestions?

[rh101]

@aismann Thansk for you testing, @rh101 do you have any other suggestions?

My original concern was the source code would be compiled in without a way to disable it, since it may not be a feature that is widely used. Having it as an extension makes sense, and doesn't seem to limit its usage in any way.