Add support for SVG

[Lpsd]

Currently, the only way to render an SVG is by creating a transparent CEF browser and loading the SVG through the browser.

I think it would be useful to have SVG support built-in to MTA, which would most likely need less resources than creating a CEF instance just to display a single SVG.

I propose a function that returns an xmlnode (since we already have XML parsing built in) but wrapped as a custom type to identify that it's an svg (something like svgnode)

svgnode svgCreate(string rawData / filePath) -- Further parameters may be added for important options

Since an SVG is essentially just XML data, and the svgnode type is basically just an alias/wrapper for xmlnode, it would be compatible with most of the existing xml* functions (such as xmlNodeSetAttribute).

Would it be better for code readability to again wrap/alias the existing xml functions with an svg prefix instead? (e.g: xmlNodeSetAttribute -> svgNodeSetAttribute).

As for actually displaying the SVG, a function would be provided to get the SVG texture as a render target (which would be automatically updated if the SVG data is changed at all) - such as:

svgGetTexture(svgnode svgRootNode)

I'd like some other input on this, as you may have some better ideas. I do plan to implement this myself, however.

[quiret]

I suggest not svgGetTexture but svgGetPixels in the known format so that the pixels can be applied to a render-target. But I am not experienced with SVG at all. Could we discuss the scope of this issue/suggestion? What kind of complexity would be coming toward MTA? Why not implement it as MTA resource instead of natively? Do you have a specific library in mind? Is hardware-acceleration desired?

Personally as a scripter, I would greatly appreciate the ability to draw shapes onto render targets, but there is already a lot of capability with the dx functions. Do you think that SVG would be easy to implement with the existing function set?

[qaisjp]

svg support is definitely non-trivial both API wise and implementation wise.

can you find any 'game engines' that support this? it would give a good idea on what our API could provide, but also whether the entire feature is practical/feasible. i checked two 'engines' and one doesn't support it (love2d) and the other will import svgs but convert to 2d sprites (unity).

[dmi7ry]

Very fast rasterizer — Blend2D, although I don't know is it possible to use with MTA or not.

Actually it would be very useful to get support of vector graphics (radar/F11 map, HUD, interfaces, etc)

P.S. It's not a SVG engine, but 2D vector graphics engine. If you want exactly SVG then check AmanithSVG (works over OpenCV, AFAIR)

[CrosRoad95]

if someone has premake file for blend2d or other project which has premake inside, i could try add it into mta ( i don't want to waste time of figuring out how to make premake from cmake )

[qaisjp]

If you want to quickly try it out without bothering with making a premake5.lua file, you can try doing this premake/premake-core#658

[Lpsd]

lunasvg branch based on this fork (to add support for premake and dllexport) -> https://github.com/Lpsd/mtasa-blue/tree/lunasvg

Current problem is here, can't work out why the bitmap data is NULL

I've also created a branch which adds plutosvg (same author as lunasvg) to handle the rendering/bitmap output (instead of lunasvg doing it directly), but it has the exact same issue. Not sure if problem with vendor or something I'm doing.

Feel free to investigate 😄

[sammycage]

I'm interested in this issue. lunasvg::Bitmap::data becomes NULL when SVGDocument::documentHeight or SVGDocument::documentWidth is zero. I need an SVG file or data for further research.

[Lpsd]

Hi @sammycage - you can see how I'm initializing the document here: https://github.com/Lpsd/mtasa-blue/blob/3cc4015858efeccfbe4c15438c9cea035d18e929/Client/mods/deathmatch/logic/CClientVectorGraphic.cpp#L31

That's the only place where I currently create, or edit the document.

[Lpsd]

I've debugged the SVGDocumentImpl::documentWidth and SVGDocumentImpl::documentHeight return values, they seem fine.

Also, here's how the Bitmap instance looks.

[Lpsd]

I debugged right the way through to SVGGeometryElement::render (after calling SVGDocument::renderToBitmap) and you can see the values of the canvas after drawing (they look like garbage to me?)

[Lpsd]

SVGDocument::toString also returns valid SVG data (tested by running in browser)

[sammycage]

is sourceData NULL?. Because from the screenshots above, everything seems fine

[Lpsd]

sourceData isn't NULL, however I assumed the data it did contain was garbage. Does that look right?