Plugin request/idea: Sprite Group?

New releases and general discussions.

Post » Tue Jun 07, 2011 9:37 pm

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: [url:2i0ed3du]http://www.scirra.com/forum/viewtopic.php?f=8&t=7786&p=60406&hilit=vram#p60406[/url:2i0ed3du]

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.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Tue Jun 07, 2011 9:55 pm

[quote="tulamide":16otl141]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: [url:16otl141]http://www.scirra.com/forum/viewtopic.php?f=8&t=7786&p=60406&hilit=vram#p60406[/url:16otl141]

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.[/quote:16otl141]

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
B
4
S
3
G
3
Posts: 125
Reputation: 1,450

Post » Tue Jun 07, 2011 10:15 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,478

Post » Tue Jun 07, 2011 10:26 pm

[quote="Ashley":3fsmmgzj]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.[/quote:3fsmmgzj]

That would be great! But also grouping the spites hierarchically like I mentioned would also be awsome :P
B
4
S
3
G
3
Posts: 125
Reputation: 1,450

Post » Tue Jun 07, 2011 10:27 pm

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



[url:20zhshd8]http://dl.dropbox.com/u/22173473/smallrock.cap[/url:20zhshd8]
B
19
S
6
G
7
Posts: 1,204
Reputation: 7,296

Post » Tue Jun 07, 2011 10:30 pm

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.
Image Image
B
161
S
48
G
89
Posts: 7,347
Reputation: 66,249

Post » Tue Jun 07, 2011 10:34 pm

[quote="newt":3ssg1vwy]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.[/quote:3ssg1vwy]

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.
B
4
S
3
G
3
Posts: 125
Reputation: 1,450

Post » Tue Jun 07, 2011 10:39 pm

[quote="chrisbrobs":3orxc1x8]"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?



[url:3orxc1x8]http://dl.dropbox.com/u/22173473/smallrock.cap[/url:3orxc1x8][/quote:3orxc1x8]


Hum..., I don't think the sprite looks ok...
B
4
S
3
G
3
Posts: 125
Reputation: 1,450

Post » Tue Jun 07, 2011 11:01 pm

[quote="pyteo":1vu07fv2]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.[/quote:1vu07fv2]
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.
Image Image
B
161
S
48
G
89
Posts: 7,347
Reputation: 66,249

Post » Tue Jun 07, 2011 11:05 pm

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.

viewtopic.php?f=4&t=4910&p=39036&hilit=shipbuilder#p39036


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


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.
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests