1 Big NON pow^2 sprite VS 6 small pow^2 sprites

» Sun Jul 03, 2011 11:07 am

As the title says.
One of the last things i still have to do for my game alpha demo and at the same time one of the most importand things i have to learn to control are all kinds of beams.
The beam i am currently using for my needs is 768/128. You see its quite long but laos quite thin. From what i remember this 768/128 uses the RAM amount of if it would be 768/768 which is a waste. So i thought to split this sprite into 6 x 128/128 ones to save RAM.

But em i right? Will this help in anything? Correct me please.
B
16
S
5
G
4
Posts: 211
Reputation: 3,767

» Sun Jul 03, 2011 11:38 am

like laser beam? why it have to be 768/128?
B
141
S
58
G
37
Posts: 2,549
Reputation: 31,736

» Sun Jul 03, 2011 12:05 pm

like round numbers :) and because its long and detailed.
B
16
S
5
G
4
Posts: 211
Reputation: 3,767

» Sun Jul 03, 2011 12:15 pm

I mean numbers are nice ;P just big.
could you post that beam image? or send me PM to get more private ;)? - maybe we could figure it out what to do with that.
B
141
S
58
G
37
Posts: 2,549
Reputation: 31,736

» Tue Jul 05, 2011 6:02 am

[QUOTE=The_Funny_Guy] As the title says.
One of the last things i still have to do for my game alpha demo and at the same time one of the most importand things i have to learn to control are all kinds of beams.
The beam i am currently using for my needs is 768/128. You see its quite long but laos quite thin. From what i remember this 768/128 uses the RAM amount of if it would be 768/768 which is a waste. So i thought to split this sprite into 6 x 128/128 ones to save RAM.

But em i right? Will this help in anything? Correct me please. [/QUOTE]
A texture will use the next 2^n size, but doesn't need to be squared. For 128 that's 128 (2^7), but for 768 it's 1024 (2^10, 2^9=512).
Your texture would consume VRAM for a 1024x128 texture, which is 0.5 MB.
6 textures with the size 128x128 will consume 0.375 MB of VRAM, plus a little more overhead in RAM, because it is 6 objects instead of one.
That's not much to save, but if you are using dozens of beam objects (not instances) it could help saving VRAM.
But if those beams change size, angle, etc, it does not help, because calculating 6 objects costs more processor time than one object.

Have you thought of using the tiled background object with a repeating pattern of your beam?
If the details of your beam can be stretched on one axis while keeping the detail on the other, the panel object is also an alternative.
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

» Tue Jul 05, 2011 7:04 am

Thats exactly what i wanted to know! thank you Tulamide! :D
i tried the tilebackground. Actualy ive started from there. wanted to use constant offset to "animate" the sprite without using actualy any more frames. But the problem is that the beam angle changes and as far as i can tell - its imposible to "angle" a tiledbg.
I also tought about panel but not only it streches the beam terribly but also make sit imposible to have more then one frames, leaving it static.
this is what i have Tulamide
http://www.scirra.com/forum/cc-grindspace-alpha-002_topic43350.html
B
16
S
5
G
4
Posts: 211
Reputation: 3,767