Hi guys! I would like to know how to use vector images in allegro, with a library for example and I think the best format is ".svg". Thank you!;D

Allegro doesn't support vector images. You'll have to render them to .png or another supported file type first. That means no run-time resizing. Otherwise, Aaron Bolyard has some code to work with SVG files and Allegro I believe.

But does not have a C ++ library that allows you to expand files supported by allegro?

SVG is a very complex image format, because of the way it deals with curves. There may be libraries out there that can convert SVG to raw RGBA data if you look. Allegro can use raw RGBA data when used with the locking mechanism for bitmaps.

Okay, it does not have to be SVG, I just need a way when the player to play my game he can resize the screen without the graphics losing image quality, as with vector images, and I think the only way to do it this is using a library.

Well, again, it depends on what you need.

If you truly need 100% resolution independence, going from a 90's phone, to an 8K TV, you'll need a vector format.

The easiest way, would be to simply use another library or (command line) tool to convert your SVG artwork, to whatever size (or range of sizes) you want. Either at first game startup (and save the cached versions), or (simpler) every time you start the game.

But 99.9% of cases don't actually need absolute resolution independence. 99.9% of games have a subset of target platforms. You're not running on an Nintendo NES from the 80's with a CRT TV. "Duh", you may think, but I'm striking a point. Your target market is less than the total set of "all computers ever." So your goal should be "What IS my subset of target platforms?" (The Steam hardware survey is a great starting point.)

Now that we've established that, it would be very helpful to have some typical cases / examples / previous games that can show us what you want to achieve. For example, you could render those SVG's to "mipmaps." You take the same image, render it at multiple sizes (256x256, 128x128, 64x64, ...) and then you either draw the smallest one that's bigger than your end size. So if you draw 200x200, you'd use 256x256 and shrink down. Or, if your particular artwork looks better this way, you'd use the 128x128 and scale UP.

You can also use many different scaling algorithms. The simplest being pixel-scaling (aka point sampling and "nearest neighbor"). Basically you just re-sample your source bitmap pixel for every relevant destination pixel with NO BLENDING. Bilinear blending can work fine. And since you're using mipmaps, TRILINEAR is also an option.

{"name":"6-18.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/11a8fe60b461e93758e83a86d568f213.gif","w":771,"h":371,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/11a8fe60b461e93758e83a86d568f213"}
We can give more detailed / applicable tips with some examples.

Most performant option is to generate a mesh from the SVG offline and use that. This is easy enough using GLU or some other tessellator. Outside of absurdly high zoom levels the curves will remain high quality and you can use MSAA to smooth everything.

You'll just have high poly counts but since you don't (hopefully) have textures you can batch things like crazy. MSAA is going to be the biggest performance bottleneck. Sorting by depth and using the depth buffer can help with fill rate issues.

Alternatively at runtime could you render the mesh to texture of the desired size (e.g., computed based on max zoom or screen resolution). You can even generate atlases dynamically to greatly improve performance (like how RuneScape does it) but that gets insane fast.

If performance isn't a concern, you can use Inkscape from the command line to produce your png's on the fly.

https://inkscape.org/en/doc/inkscape-man.html

inkscape -f scalable.svg -w 1024 -h 768 -e scaled.png

An Allegro library that reads in SVGs and translates them to draw instructions is entirely possible, but would probably be rather complex and wouldn't be able to fully realise the SVG specification. As Edgar said, it's a big spec.

If, however, you just wanted to draw solid (or possibly gradient-filled) shapes and lines accurately (which is what I'd imagine you'd be using it for):

• Get an XML parsing library

• Read in an SVG's points and colours. The latter wouldn't be easy - because you'll have to extract them from the CSS - but if the styles aren't too wacky this could probably be done with a regex or two.

• At render time, use al_calculate_spline (and other assorted trickery) to produce a joined-up list of vertices for the given draw scale for each path segment in the graphic

• Draw those vertices

Come to think of it, this may all become a lot easier if you're using one of Allegro's bindings. For instance, here's a ready-made SVG parser for Go.

Hmm I wrote an SVG parser/converter once with aid of Flex and Bison for a company I worked for. ( so I don't have or own any code)
It might be a nice idea to write an SVG import for allegro.. but that will take quite some time.. It is not that simple.

Supporting vectorgraphics in allegro should be possible I think..

https://github.com/memononen/nanosvg

Or use this svg parser as the base of your work ☺️

I might have to use that NanoSVG parser in my next SpeedHack...

😅😅

☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️
☺️         ☺️
☺️  ☺️   ☺️  ☺️
☺️    ☺️    ☺️
☺️ ☺️     ☺️ ☺️
☺️ ☺️☺️☺️☺️☺️☺️☺️ ☺️
☺️         ☺️
☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️

🐒

There is also http://www.antigrain.com/index.html which includes an example SVG viewer.

Note: https://www.labri.fr/perso/nrougier/news/2013/11/26/MaximShemanarev.html