High-res Art?

What's the best way to go about implementing animated high res art into construct 2? In construct classic the bone movement was ideal, but I'm not sure the best approach in C2.

Would using bone movement in an outside program and exporting it into .png images be too much? as far as vram and optimization goes?

Lucid's working on a program called spriter to make that easier. As far as I know, he's going to make it work with C2 as well.

lucid, care to answer?

thanks arima

Arima is correct. I am working on a program called spriter. I'll relink the thread, as I've just updated it to explain the basics of the software, and give the latest information. Expect much more information about what it can do and how it works upon release:

here's a link to the latest info thread

<img src="http://dl.dropbox.com/u/1013446/Spriter%20Releases/screen.png" border="0">

Also Spriter, is a outside program and export png sequences of frames.

But the question is ould using bone movement in an outside program and exporting it into .png images be too much? vs. construct classic bone movement ?

I know not construct classic , therefore I'm interested for a objectively answer to these question, too

Also Spriter, is a outside program and export png sequences of frames.

But the question is ould using bone movement in an outside program and exporting it into .png images be too much? vs. construct classic bone movement ?

I'm not completely clear on what you're asking, but I will try to provide a general answer in those areas. There will be a plugin for Construct Classic, and eventually C2, that will animate the character for you in real time so you don't need to use export to PNG unless it's for a platform that doesn't have a Spriter plugin yet.

   Like Bone Movement for Construct Classic, running it through the plugin instead of using exported PNGs would require much less VRAM. Spriter will cap off the VRAM usage with whatever the total size of all your images are, no matter how many frames of animation you have(with tweening you have effectively unlimited tween frames). Using the plugin, the vram usage won't increase with any amount of additional frames and animations.

   With export to png, or any traditional frame by frame solution, you could potentially fit an entire Spriter character's VRAM usage in the same space that a frame or two of normal images take. With each additional frame, you're using that same amount again. There's a huge tradeoff you have to make in either image size or animation smoothness - one of Spriter's goals is to alleviate this problem.

Did any of that answer your question?

I wish there was a way to check VRAM usage in Construct 2.

my english is not enought to understand .

I think You wrote , spriter is better solution for constuct 2 as a conventional png image sequence from another animation program ?

well to help Lucid explain it, basically for a typical walk cycle animation, for example like this one;,

<img src="http://atomicrobotdesign.com/blog_media/sprite_movement/images/gb_walk.png" border="0" />

If, we look at the top row, there's 6 frames to depict the "walking towards right animation".

Since every frame is a 'unique' piece of drawing, each will consume it's own space (ram or harddisk). If each is let's say 6 mb (not so big, just for comparison), the whole Walking "walking towards right animation" will take up to 6 x 6 = 36 mb, just for one animation!!

So if you need alot of animations, like jump and walk and run, the total of the space the animation will take will be enormous! And that's just for one character.

Lucid's Spriter basically solves this issues by instead of loading each unique frame of animation, the software and plugin will give each image a "Path" so to say, that it will follow. And this "Path" is much much lighter in size compared to traditional method.

Hope this help explain a little.

Sorry vidi, I thought I had responded to your last post already. but Yung is exactly right. Look at that pic again:

<img src="http://atomicrobotdesign.com/blog_media/sprite_movement/images/gb_walk.png" border="0" />

now this isn't completely scientific, but on disk that image takes up 168k. The next image is a rough example of the size of a cut up version of the character. If you made the images specifically for spriter, they would be in separate files, so you wouldn't even need to have that waster in between space.

<img src="http://dl.dropbox.com/u/1013446/Spriter%20Releases/spritered.png" border="0" />this image takes up 12k. I'm not sure how directly the disk space translates to VRAM space, but it should be a similar ratio.

There is some white space in the large version, but if you were to fill it with images, you'd have 18 frames worth of space. This means a sprite would use about 14 times as much vram, just to have 18 frames of animation, for this particular character. Want 36 frames, then the regular sprite would use about 28 times the space as the spriter version. The spriter version would still take up 12k of VRAM, even if you had a total of 1,000 frames. This will help not only VRAM usage, but eventually download size as well.