Plugin request/idea: Sprite Group?

Hello guys,

Please take a look at these images from Rayman Origins:

http://www.thetanooki.com/wp-content/uploads/2011/06/RaymanOrigins_PreE3_HD_Fakir.jpg

http://www.thetanooki.com/wp-content/uploads/2011/06/RaymanOrigins_PreE3_HD_Underwater.jpg

That's the native resolution of the game, and as you can see , there are no tiles, and they're using huge art assets.

Of course we all know that the art assets are made using sliced sprites of a bigger image. It's possible to achieve this result in construct, but it would take forever to place all small chunks in the right place in something this complex. This is when I had this idea for a plugin, more specifically, an object.

What if construct had an object in which you could specify a grid of sprites (128x128 for example)horizontally and vertically, then import a single image to each space of the grid? The advantage would be to move, rotate and scale the object like if it was a single sprite.

Take a look at the example. Am I the only one who finds this very useful?

<img src="http://img41.imageshack.us/img41/8995/constructplugin2.jpg">

<img src="http://img806.imageshack.us/img806/7394/constructplugin1.jpg">

And it doesn't look so complicated to create as a plugin... I think

Have you seen the Panel object? Is that what you mean?

Have you seen the Panel object? Is that what you mean?

Panel object?

Let me check that...

Have you seen the Panel object? Is that what you mean?

In the panel object you can only import one image, right?

I mean import several small images to make a big one...

You can define nine cells of the panel object, but I realise that's more for stretching and UI. I guess you want a sort of "composite object", which is made out of other objects but acts like one?

I think what he's wanting is a plug that would automatically align sprites based on a center objects imagepoints from within the editor... doable without a plug via imagepoints, pv's, and set angle, at runtime.

But here's the kicker, if said sprites are all power of two, there's really no gain in splitting the image up into smaller pieces.

I think what he's wanting is a plug that would automatically align sprites based on a center objects imagepoints from within the editor... doable without a plug via imagepoints, pv's, and set angle, at runtime.

But here's the kicker, if said sprites are all power of two, there's really no gain in splitting the image up into smaller pieces.

That right what I was asking for.

But I disagree with you. In Yokai I have lot of small assets, all 256px, and the game only uses 50mb of vram, but as soon as I import larger images, even if it's only two sprites of 512px, vram increases drastically. Construct handles better lots of small images instead of few large ones, it's not the same thing.

4 different objects at 256 x 256 take up less vram than 1 object at 512x512?

That just doesn't add up unless the big object is not exactly 512 x 512, or your video card doesn't support it. The latter being the most obvious of course.

I think it's easier to just use a huge tiledbackgroundlayer rather than tiles as Construct just isn't really usable for large tiled games. As an example, level 1 of my game was originally meant to be 205x57 tiles of 32x32 each, totalling 11685 tiles. Instead, I use a tiledbackgroundlayer of 6560x1824 px. Even with sprites of 64x116, it still only uses approx 66MB VRAM.

4 different objects at 256 x 256 take up less vram than 1 object at 512x512?

That just doesn't add up unless the big object is not exactly 512 x 512, or your video card doesn't support it. The latter being the most obvious of course.

You're wrong, that only works in theory:

1st cap: 4 images 256px

<img src="http://img11.imageshack.us/img11/6536/cap1wc.jpg">

2 nd cap: 1 image 512px

<img src="http://img196.imageshack.us/img196/9986/cap2rq.jpg">

The four images take half the vram of the large one. Not to mention the first cap loads faster.

I can upload the caps if you want...

I think it's easier to just use a huge tiledbackgroundlayer rather than tiles as Construct just isn't really usable for large tiled games. As an example, level 1 of my game was originally meant to be 205x57 tiles of 32x32 each, totalling 11685 tiles. Instead, I use a tiledbackgroundlayer of 6560x1824 px. Even with sprites of 64x116, it still only uses approx 66MB VRAM.

The idea here is to avoid tiles, look at the Rayman images....

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

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

What you are talking about could be achieved if Construct had parenting functionality. For instance, say you had several small sprite parts that made up that rock like your example shows (and presumably you could make various sized rocks from the components and save on vram that way, rather than having separate, whole "big rock," "medium rock," and "small rock" sprites).

Now, you want to be able to rotate and scale your component rock, yes? That's where parenting would come into play. Take your rock pieces:

>rockTopLeft
rockTopMid 
rockTopRight
rockBottomLeft
rockBottomMid
rockBottomRight
[/code:w275hifs]

And create a parent for them:

[code:w275hifs]
MediumBoulder
  >rockTopLeft
  >rockTopMid 
  >rockTopRight
  >rockBottomLeft
  >rockBottomMid
  >rockBottomRight
[/code:w275hifs]

Now you have a MediumBoulder object (which is essentially just an empty vessel with nothing but position, rotation, and scale information) composed of child objects in a hierarchy.  You can select a child if you wish to swap it out or change it, or you can select the MediumBoulder parent and manipulate it.

Scaling, rotating, or moving the parent would automatically translate to the children, so they would stay in position and orientation [i]relative[/i] to the parent object.  The children's individual scale and such would all be "local" to the MediumBoulder object.

You could also select the MediumBoulder object and copy/paste instances of that, rather than having to build new ones from scratch all the time.

Also, let's say that your boulder is actually a small platform made of pieces of separate dirt and grass tiles, and you want the whole thing to move up and down together, like an elevator.  Create a parent for them and put your Sine behavior on the parent.  Ta-daa, they all follow along automatically.

Ideally you wouldn't be restricted to all the same child objects under a parent either, so you could for instance do something like this:

[code:w275hifs]
Player
  >commandoSprite
    >Gun
      >rifleSprite
      >muzzleParticles
      >shellParticles
  >Nametag
    >idText
  >Flashlight
    >lightObject
[/code:w275hifs]  

This is how Unity3D does things.  It is very handy for creating complex objects .  In fact the object list for your scene is called the Hierarchy, and every single object in it is basically a child of the scene.

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.

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)