Holy hell I must be stupid, animation and matrix help

Page: 1 2
ID:1873005
 
Jun 13 2015, 11:57 am
(See the best response by Rotem12.)
Code:
                            var/scaling = 50/oldstate
                            var/matrix/M = matrix(barbar.transform)
                            animate(barbar, transform = M.Scale(scaling,1), time=delayfraction, color = "#f93")


Problem description:
I want the barbar image to elongate towards the right and change color, what happens instead is it grows longer towards the left and also moves(???)

Example: http://ss13.pomf.se/uploads/2015-06-13_12-52-10.mp4

build is 1286
Jun 14 2015, 7:52 am
Best response
As it scales, the image size grows and it remains centered so you have to shift it.

animate(b, transform = M.Scale(scaling,1), M.Translate(scaling,0), time=delayfraction, color = "#f93")


I may be off (probably), you'll need to toy with translate.
I'm more concerned with the black fading corners they might be annoying at certain sizes.
Jun 14 2015, 6:20 pm
I'm more interested in why the bar is shifting off to the left like that.
Jun 14 2015, 6:37 pm
I'm more interested in why the bar is shifting off to the left like that.

That's because matrices consider 0,0 to be the center of the icon, not the bottom left. So if you scale something, you also need to offset it by (width-newwidth)/2 and (height-newheight)/2.
Jun 14 2015, 7:45 pm
In response to Ter13
Ter13 wrote:
I'm more interested in why the bar is shifting off to the left like that.

That's because matrices consider 0,0 to be the center of the icon, not the bottom left. So if you scale something, you also need to offset it by (width-newwidth)/2 and (height-newheight)/2.
I don't understand how that explains it floatin away

Jun 14 2015, 8:30 pm
Multiplying an entire matrix will also multiply the c and f components.
Jun 15 2015, 3:01 am
In response to Ter13
Ter13 wrote:
offset it by (width-newwidth)/2 and (height-newheight)/2.

I love how you know exactly how much. Thank you for that one, I actually did want to know that.

Pomf123 wrote:
I don't understand how that explains it floatin away

Imagine this is your bar.

---(center)---
right here is the center.

Imagine this is your reszied bar.

---------(center)---------
The center is no longer at same position, hence you see it floating away.

The direction it floats away or how it reacts precisely will depend on your icon, where it's positioned within the 32x32 icon file (I assume it's 32x32 file) etc.

For example, the fading blackness at the sides of your bar can be solved by simply not leaving empty pixels at the sides.

Basically when scaling an icon, it considers the entire 32x32 icon not just the pixels you placed within.


Jun 15 2015, 8:36 am
In response to Rotem12
Rotem12 wrote:
Ter13 wrote:
offset it by (width-newwidth)/2 and (height-newheight)/2.

I love how you know exactly how much. Thank you for that one, I actually did want to know that.

Pomf123 wrote:
I don't understand how that explains it floatin away

Imagine this is your bar.

---(center)---
right here is the center.

Imagine this is your reszied bar.

---------(center)---------
The center is no longer at same position, hence you see it floating away.

The direction it floats away or how it reacts precisely will depend on your icon, where it's positioned within the 32x32 icon file (I assume it's 32x32 file) etc.

For example, the fading blackness at the sides of your bar can be solved by simply not leaving empty pixels at the sides.

Basically when scaling an icon, it considers the entire 32x32 icon not just the pixels you placed within.



So how am I going to scale a small icon into a bar without the weird alpha issues at the x-axis edges?
Jun 15 2015, 2:26 pm
Scale it smaller (then bigger of course but initially it should be small), that might work. Using ter13's offset formula you can accurately determine the new position and if the bar is a simple line that takes 32x32 pixels it should be able to scale either smaller or bigger.

As long as it fills up the icon on the x axis, it should be good.

I've seen Ter13 do his first stage of animate with time=0 for setting it up so you can start the first step of the animation as a instant resize to whatever you desire then go from there.
Jun 15 2015, 2:28 pm
I've seen Ter13 do his first stage of animate with time=0 for setting it up so you can start the first step of the animation as a instant resize to whatever you desire then go from there.

FYI: I don't actually know what the hell I'm doing with animate(). It's currently got some major bugs about every second time I use it, and I'm just now getting them diagnosed so Lummox can investigate them.

So yeah, that time=0 thing might not actually work.
Jun 15 2015, 2:35 pm
In response to Ter13
Ter13 wrote:
I've seen Ter13 do his first stage of animate with time=0 for setting it up so you can start the first step of the animation as a instant resize to whatever you desire then go from there.

FYI: I don't actually know what the hell I'm doing with animate(). It's currently got some major bugs about every second time I use it, and I'm just now getting them diagnosed so Lummox can investigate them.

So yeah, that time=0 thing might not actually work.

Hey now, the best way to learn things is play with the toys in creative ways. I think it'd be better if we were to set the initial step in animate over setting a bunch of variables, especially after that explanation Lummox gave about appearances

That being said, time=0 does work
animate(src, alpha=0, time=10)
animate(alpha=255,time=0)

It reverts back to 255, however without that line you'll remain invisible. So yes, your cool little trick works and I love it.

Jun 15 2015, 2:43 pm
Okay, as for dealing with bars.

Let's say you have a 128(width) by 16(height) pixel bar.

Now, you want to transform the bar so that it's at 90%(scale=0.9).

The formula would be:

nw = floor(width * scale)
nx = (nw - width)/2

Therefore:

nw = floor(128 * 0.9)
nw = floor(115.2)
nw = 115

nx = (115 - 128)/2
nx = -13/2
nx = -6.5

Therefore:

transform = matrix(nw/width,0,nx,0,1,0)

Therefore:

transform = matrix(115/128,0,-6.5,0,1,0)
transform = matrix(~0.898,0,-6.5,0,1,0)


Now, how do we figure out we want the bar to be 90%? Simple:

scale = current/total

Therefore:

scale = 90/100
scale = 0.9



Let's say you want to scale something up by 250%? Well, let's take a look:

scale = 250/100
scale = 2.5

nw = floor(128*2.5)
nw = floor(320)
nw = 320

nx = (320 - 128)/2
nx = 192/2
nx = 96

Therefore:

transform = matrix(320/128,0,96,0,1,0)
transform = matrix(2.5,0,96,0,1,0)

Get it?
Jun 15 2015, 2:53 pm
I challenge you to add rotation to this to handle bars in awkward angles.
Jun 15 2015, 4:42 pm
Correction, as I started using time=0 in animate() I found out that if you're using loop = -1 then it will simply not loop, unsure if this is considered a bug.
Jun 15 2015, 8:34 pm
In response to Rotem12
Rotem12 wrote:
Correction, as I started using time=0 in animate() I found out that if you're using loop = -1 then it will simply not loop, unsure if this is considered a bug.

I'm not sure I follow what you mean. Can you post the code and explain what results you're seeing?
Jun 15 2015, 8:38 pm

Loops:
mob/verb/TestAnimate()
    animate(src, alpha=0,time=1, loop = -1)
    animate(alpha=255,time=10)


Doesn't loop:
mob/verb/TestAnimate()
    animate(src, alpha=0,time=0, loop = -1)
    animate(alpha=255,time=10)
Jun 15 2015, 8:47 pm
I can confirm, there seems to be a problem and it's not the same one that we saw before with color vars.

does loop:
animate(src,pixel_z=0,time=TICK_LAG,loop=-1)
animate(pixel_z=32,time=10)


doesn't loop:
animate(src,pixel_z=0,time=0,loop=-1)
animate(pixel_z=32,time=10)


I was never sure whether a time of 0 was intended to be used as an argument in animations, though, so I never asked whether this was intended or unexpected.

I never said anything because I figured you'd point out the obvious: 0 is a nonsensical time value for an animation step to occur.
Jun 15 2015, 8:52 pm (Edited on Jun 15 2015, 8:59 pm)
A time of 0 is allowed in animations. I'll take a look at this case.

[edit]
Ah, I see the issue. The first call doesn't allow 0 when looping is involved, and resets loop to 1 deliberately. This is a sanity check but I believe I can work around it.
Jun 15 2015, 11:24 pm
If you want to post a bug report on this I can mark it closed for 508.1290. Animations that are truly 0-time (total) and looping will short-circuit now and turn off looping, but otherwise 0 can be used as a time on the first step now without impacting loops.
Jun 15 2015, 11:26 pm
@Rotem: You want credit for this one? Pop in a bug report and PM the link to Lummox. I discovered this bug back in march, but I didn't report it because I wasn't sure it was a bug. You take this one.
Page: 1 2