Plugin request/idea: Sprite Group?

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

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">

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.

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.

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.

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

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.

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

"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

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.

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.

"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...

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.

Im talking about a exe you make on your own, one that saves the x, y, angle, and some reference to each object in an array. You would then import that info into your game to tell your assets where to go.

I'm not sure what you mean by every single asset, as it usually designed to reuse events.

You would however have to add a few events to the game to parse the array.

I have an s plugin example that rotates several sprites together like this. it let's you drag and drop them into place, which drops each one into an array. then you can rotate and move them all with a single action.

this is all I do to move it. it's just one more command over a regular sprite:

<img src="http://dl.dropbox.com/u/1013446/allmovements.JPG">

if you're not a fan of regular programming though, s is probably pretty weird. I'm planning on eventually making a free plugin for cclassic, and c2, when I have some free time that'll be much simpler. it'll be a suite of plugins that will eventually be able to do everything s can, but be super minimalist and easy to understand. can't give any timeline on it,just eventually. but i digress.

the part that relates to what you're saying is the objectarray plugin. it would be just like a regular array, except you'd put actual objects in there. it would have alot of uses, but this is one of them.

it would be two actions to set up:

--Take spacial snapshot

//this would tell the objectarray the objects locations, angles, and size in relationship to the objectarray itself. basically telling it that you're ready, and the sprites are in their proper positions to look like one big thing

then you just move your objectarray like a regular object, put platform behavior on it if you want. rotate, resize, move. even destroy.

then you use a single action

--apply spacial info

// this would update all the sprites' locations, angles, and sizes as if it were one object

it would also be simple to put it in "autoupdate" mode so you just do

--Set autoapply to true

at the beginning of your cap to automatically apply spacial info, so you don't have to call the action manually. also to make it autosnapshot if an object is moved outside of the plugin.

One thing to take note of:

It's not enough that you take a big picture and cut it up into smaller chunks. When you put the chunks back together, it still makes a big picture.

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.

Just a general FYI, I've seen people make this mistake a few times before, and I thought it was worth spelling out plainly.