Construct 3 idea- support vector graphics (SVG)

here is a quick idea, construct 3 should support vector graphics, thats all!.

I like vector graphics, they're great for anything that needs re-sizing. However, my experience with them is that they are very slow to draw compared to sprites in games. What kind of use would you have in mind for them?

(BTW, I think there is a document somewhere on the site where you can add official C3 feature requests. You might want to track that down, and see if this was already suggested.)

a vector image its pure code, a sprite its a png file that have a lot of weight. a game can end up with tons and tons of sprites files. but with vectors all is in the code.

I read somewhere there is a workaround for having svg's in your project. Use png images in your project but after export you replace them with Svg's. You may have to alter the code somewhere and change so that the svgs are loaded instead of the png's. Html5 supports vector graphics so i have no idea why this hasnt been implemented yet.

This would be a nice-to-see feature. Even as a seperate object, for ex.: Vector Sprite.

While in theory it seems like it would be awesome, I tried this with Gamemaker because it supports vector sprites in the form of .swf, I tried replacing all the sprites in one of my games with vector sprites, and how much it kills performance is insane, went from 60fps to unplayable, on mobile browsers at least.

There is a js library for vector graphics here http://paperjs.org/.

Some one just needs to make a plugin, which would be cool.

While in theory it seems like it would be awesome, I tried this with Gamemaker because it supports vector sprites in the form of .swf, I tried replacing all the sprites in one of my games with vector sprites, and how much it kills performance is insane, went from 60fps to unplayable, on mobile browsers at least.

I don't think that the whole game should be using vector graphics, but it can be helpful in some cases.

Like this?

https://dl.dropboxusercontent.com/u/139 ... anvas.capx

The problem is svg is software rendered. There is no hwa equivalent.

Its basically the same issue we have with the Canvas plug.

I could see using vector art for graphics that need to look good on large screens as well as small screens, such as maps. They get rendered to the screen with no expectation of movement after rendering.

There are a few problems with SVG support in C2:

• as people have mentioned, it can seriously degrade performance. Textured sprites are super fast to draw. Normal sprites are always a box with 4 vertices. A single SVG object could involve hundreds of vertices, having an equivalent performance impact as hundreds of sprites.
• there are not currently any good libraries for drawing SVG in WebGL, the main renderer for C2 games. Even browsers themselves have patchy support for rendering all the many features of SVG in web pages. Writing such a library when none exists is a significant project, and it's hard to justify it when it could take a great deal of work and end up slowing down games.

I think it's possible to render SVGs at a fixed size and then just use them as a WebGL texture, but this could still be slow when scaling objects gradually (every size change requires re-rendering the SVG then uploading a new WebGL texture to the GPU), and it would still use lots of memory (the same as if you just used a normal texture in the first place). I'm not sure that really has any benefits.

I think it's possible to render SVGs at a fixed size and then just use them as a WebGL texture, but this could still be slow when scaling objects gradually (every size change requires re-rendering the SVG then uploading a new WebGL texture to the GPU), and it would still use lots of memory (the same as if you just used a normal texture in the first place). I'm not sure that really has any benefits.

when thinking about using vector graphics i came to a related idea. One could use svg graphics in the project and when the exported game is loading (or after or before?) a "preloader/svg-to-pngexporter" checks for the resolution of the device where the game is loading and exports the svg's to png's accordingly to this resolution (or multiplied by some factor that you specify in the editor) then it clears storage and loads the game with these png's. Only happens at loading of the game (or before, etc.), not when the window size is changed. That way you could be sure to always have "crisp" graphics, no matter how big the resolution is and wouldnt waste memory on small resolutions. Only loading time should be affected. Does that make sense?

The engine doesn't know ahead of time what kind of scaling or zooming will be used. If they are only ever used small, it will waste memory preloading images which are too large, and if they are always scaled up a lot, they will still appear pixellated. Also any kind of image processing on startup could make the loading take far longer.

yeah i see desktop is a problem but it would still be a super cool feature for mobile export where you have tons of different resolutions and i think 99.9% of games exported for mobile run in fullscreen so you could just take the overall resolution as reference.