Sprite ribbon might work pretty good here.

Ill try to make an example.

Thanks newt

Hello everyone!

So, I have this character with a scarf and would like it to have the kind of behavior you see in Aquaria character's cape.

Does anyone knows how achieve that in construct? I'm really bad with distortion maps and ribbons :p

Can anyone submit a cap?

Thanks a lot

if you look at those ray man pictures, the backgrounds aren't pixel crisp. In fact they're FAR from it.

You're right.

Thanks a lot for the feedback guys

What you need are tiles. Repeatable chunks. That way you can reuse the same chunk ten or twelve different times over when making your picture. It's that repeated use that helps out... if you have twelve of the same tile on the screen it only stores one of those tiles in vram.

I already do that, look at the Yokai images. What I'm asking here is a way of managing several images as one.

"Now they give me the same value, but it's 1,50mb."

I downloaded your cap ( 1.00mb vram ) when run.

Resized the sprite, and it was ( 0.06mb vram ) and the sprite still looked ok?

<img src="http://dl.dropbox.com/u/22173473/rocksmall.png">

http://dl.dropbox.com/u/22173473/smallrock.cap

Hum..., I don't think the sprite looks ok...

It should be relatively easy to create an editor that does the grouping for you using Lucid's S plug.

It allows you to create array's that remember x, y, and angle, and it has a function to create image points on the fly.

Yes, but that way I would have to make event's for evey single art asset. That's what this idea is for, to avoid all that wok in a simple way.

If you only want to save VRAM, it would be better to simply add proper non-power-of-two texture support to Classic, like C2 already has with OpenGL. I can't remember if DirectX 9 supports it though. With non-power-of-two support, images take up exactly their size in VRAM, no more, no less, nothing to be saved by slicing up.

That would be great! But also grouping the spites hierarchically like I mentioned would also be awsome

pyteo, I would love to investigate your caps, but I don't have Construct for a while. Whatever it is, there's something wrong with the sizes. Not only in theory but practically 4 256x256 textures consume the same texture memory as 1 512x512 texture.

I once made an example for effective slicing, where I could prove that a bunch of sprites with totally different sizes (1x2, 256x32, 512x512, etc.) formed a picture of the size 700x700. A picture of that size needs 1960000 bytes of texture memory (1.87 MB), and all the sprites combined used exactly that size of texture memory.

Here is the link to that post: http://www.scirra.com/forum/viewtopic.php?f=8&t=7786&p=60406&hilit=vram#p60406

A 256x256 texture takes up 256 kB of texture memory.

A 512x512 texture takes up 1 MB of texture memory.

If you are experiencing other values (like 1.5 MB for 4 256x256 textures, or 3.5 MB for the 512x512 one) then there is something wrong. Graphic card reporting wrong sizes, driver issue, not exactly cut images, Construct reporting wrong sizes, I really don't know...

It would be interesting to find out what is going wrong in your cap, maybe someone else could check it.

You're right,

Now they give me the same value, but it's 1,50mb.

Just uploaded the caps and images here: http://www.box.net/shared/krqmarh21l

I know what you are saying, but the backgrounds are...just backgrounds? They dont need to be massive images anyway. With a decent image editor you can create resized images, then enlarge them in Construct without Distortion affecting them?

Sorry if i am not understanding the original post.

The plugin would accelerate the work flow a lot, and also save a lot of vram. Sorry for saying backrounds, I mean all the art assets in the game. In short, it makes possible a HD game. Right now it would take forever to make just a simple level.

The Rayman games graphics were created with 'UbiArt Framework'

http://ubi-art.uk.ubi.com/category/developpement/

"The idea behind our animation system is to be able to animate any kind of image. The image may be a 3D rendering, an India ink drawing, a modelling clay background, an image drawn on a graphics tablet or a scanned image, and so on. In fact, any visual source can be used. We put the focus on freedom and simplicity, to make it easy to start a project and add content without much hassle.

Once the drawing is ready, an in-house tool lets us add the skeleton and determines which part of the drawing will move and how. Then all the animator has to do is design the animation poses, and the tool takes care of the image deformation.

1, Create an image for the level.

2, Cut it up into pieces.

3, Add a bone to each element, to compose the skeleton.

4, Bring it to life by animating it? It?s that simple.

If you?re into the technical stuff, we use 2D patches to contort sections of the image with a level of complexity that can adapt to the potential needs of the final rendering and the target machine. This technique adapts remarkably well to this type of animation and gives excellent performances in a real-time context."

<img src="http://dl.dropbox.com/u/22173473/main%20layer.png">

<img src="http://dl.dropbox.com/u/22173473/All%20layers.png">

(The green dots are bone connection points)

Construct has all the tools needed to make a game along these lines. (layers, transparency, bone behaviour....etc)

You're right. But you're talking about the animation.

I'm talking about backgrounds:

<img src="http://www.xboxliveaddicts.co.uk/forums/uploads/7ed1da9a80a135bbb581f920de892207.jpg">

<img src="http://fastcache.gawkerassets.com/assets/images/9/2011/06/raymanorigins_pree3_hd_boss.jpg">

<img src="http://gameonly.pl/wp-content/uploads/2011/05/rayman3.jpg">

And yes, it is relatively easy to act on a group of objects with containers or families at runtime in Construct, but the basic functionality of altering the scale and rotation in relation to one another isn't as easy, and it's not possible to do in the layout editor, which is why this would be handy.

Probably way too late for this sort of functionality to be added to CC though. It would be a pretty drastic change to the interface.

Too bad

I always wanted to make a 1080p 2d game. Well, I guess I'll have to wait for Ubiart framework

I thought the point was the convenience of having the objects grouped together rather than to save VRAM?

This way you could have large art assets composed by small images, saving lot's of vram, with the simplicity of heaving only one object...