Animate proc acting differently

Page: 1 2
ID:1536971
 
Apr 5 2014, 7:52 am (Edited on Apr 5 2014, 9:40 am)
Resolved
Pixel offset animations still sometimes had trouble with moving objects. Also, screen objects inappropriately allowed pixel offset animations to work.
BYOND Version:504
Operating System:Windows 7 Home Basic
Web Browser:Firefox 28.0
Applies to:Dream Maker
Status: Resolved (506.1242)
This issue has been resolved.
Descriptive Problem Summary:

We were working on one of the earliest stable versions that featured the animate proc. After switching to the latest stable version 504.1234, animate has been acting differently.


Code Snippet (if applicable) to Reproduce Problem:
        clickToBegin
            icon='gameTitle.dmi'
            layer=98
            var/clicked=0
            mouse_opacity = 2
            mouse_over_pointer = 'mouseOverCursor.dmi'
            alpha = 150
            MouseEntered()
                ..()
                icon_state= "12"
                alpha=255

            MouseExited()
                ..()
                icon_state= "1"
                alpha= 150

            New(mob/User/U)
                ..()
                src.screen_loc="9, 10"
                src.pixel_y= 70
                U.client.screen+=src
                animate(src, transform= null, pixel_x=0, pixel_y=0, time = 10, loop=1)


Expected Results:

For the title to slide down and stay there.

Actual Results:

http://gyazo.com/220a50f2cb1bacaac0b7868734c45328

Other example:

http://gyazo.com/23c6aa7de7e48e9946443ed87a9ca053

You will notice the fireflies acting sporadically.

Does the problem occur:
Every time? Or how often? Every time.
In other games? n/a
In other user accounts? yes.
On other computers? n/a


If we could get some feedback on this as quick as possible it would be really appreciated. We have been working on this project for close to a year and now that we are nearing completion we have hit this annoying roadblock.


edit: The problem begins in version 504.1227. Up to .1226 everything works properly.
Apr 5 2014, 8:45 am
Set loop to 0 if you want it to cease after the animation finishes. If loop is set to 1 it will return to the first frame of the animation after it completes and go again -- if there's enough time left on the time parameter.
Apr 5 2014, 9:17 am (Edited on Apr 6 2014, 4:26 am)
In response to Nadrew
Tried it, didn't change anything.
Apr 5 2014, 9:41 am
I found that the problem begins in version 504.1227. Hope this helps.
Apr 5 2014, 11:21 am
I thought pixel_x and pixel_y didn't affect screen objects?
Apr 5 2014, 12:01 pm
In response to DarkCampainger
Why wouldn't it.
Apr 5 2014, 12:13 pm
In response to YnorRon
They don't. Pixel offsets for screen objects are effected per screen_loc and transform.

The pixel_x and pixel_y variables are physical map offsets.
Apr 5 2014, 12:22 pm
In response to Kaiochao
Seems to be working fine in those gifs? I don't know that's the issue here, the fireflies aren't screen objects either way and they're spazzing all over the place.
Apr 5 2014, 4:51 pm
I think you're reporting a bug that was already fixed in a newer beta.
Apr 6 2014, 4:16 am (Edited on Apr 6 2014, 9:09 am)
In response to Lummox JR
Updating to the beta was one of the first things I did and the behavior was worse.
Apr 6 2014, 10:25 am
Oh, I see now. I wasn't paying attention to the fact that you were using screen objects before. That doesn't work, and it explains why your issues don't match up with what I see when I test pixel offsets in animation. The fact that animate() is doing anything with pixel offsets on a screen object at all is a bug. The correct behavior is that you shouldn't see any pixel offsets beyond what's included in screen_loc. So there is a bug in play here, but the fix won't give you the behavior you want.

What you should do is simply set the obj's transform to matrix(0, 70, MATRIX_TRANSLATE) (that's just a quick undocumented way to get matrix(1,0,0,1,0,70)) before animate(), since you're returning the transform back to null as part of the animation.
Apr 6 2014, 10:49 am
In response to Lummox JR
I see, but that still doesn't explain the behavior here fully. In the second gif you can see the fireflies flickering in the back and they aren't screen objects.
Apr 6 2014, 5:19 pm
It's hard to know what the fireflies are supposed to look like without code or a test case. (A test case would be very helpful.) Are the fireflies better in the newer version? There were bugs with pixel offsets fixed since 504, so if the fireflies behave in 506 then there's no bug except the fact that screen objects are applying animation pixel offsets.
Apr 6 2014, 6:22 pm (Edited on Apr 6 2014, 6:33 pm)
The fireflies aren't screen objects, and they begin flickering in version 504.1227 on to the latest 506 beta. They are added to the map just like every other object or turf.

This is a gif of how they begin acting: http://gyazo.com/23c6aa7de7e48e9946443ed87a9ca053

Here you can see how they act in version 504.126 and below:
http://gyazo.com/931a4e1ebba6d62c2fec4335d922ece2
http://gyazo.com/8144b81d759c324283aead1c6cdca330

This is the code: 
obj
    littleThings
        fireflies2
            layer=MOB_LAYER+2
            icon='fireflies.dmi'
            New()
                ..()
                spawn(rand(0, 50))
                    icon_state=pick("1","2")
                    step_x=rand(-5,5)
                    step_y=rand(-5,5)
                    while(src)

                        if(src)animate(src, pixel_x=rand(-15,15), pixel_y=rand(-20,20), time = 40, loop= 1)
                        sleep(40)
                        if(src)animate(src, pixel_x=0, pixel_y=0, time = 40, loop=1)
                        sleep(40)

        fireflies
            layer=MOB_LAYER+2
            icon='fireflies.dmi'
            New()
                ..()
                spawn(rand(0, 50))
                    icon_state=pick("1","2")
                    step_x=rand(-100,100)
                    step_y=rand(-100,100)
                    while(src)
                        if(src)animate(src, pixel_x=rand(-50,50), pixel_y=rand(-50,50), time = 40, loop= 1)
                        sleep(40)
                        if(src)animate(src, pixel_x=0, pixel_y=0, time = 40, loop=1)
                        sleep(40)



Where would I send a test case to?
Apr 6 2014, 6:29 pm
Have you tried removing the loop=1 parameter? Your timings don't have any leeway built into them, so if the next animate() call is a few milliseconds late in reaching the client, it may restart the previous animation and create a stutter before it gets the new one.
Apr 6 2014, 6:34 pm
I don't think losing the loop=1 param will have any impact as that's the default anyway. (It doesn't need to be there.)

You can send a test case to me in a zip at [email protected]. Something really minimalist would be best, like a single firefly, if you can reproduce it that way. I could try some experiments too.
Apr 6 2014, 6:37 pm
I think at this point I put the loop there out of habit.
Would you need the source code or just a quick demo.
Apr 6 2014, 6:59 pm
Oh, derp. I was thinking it was a true/false value as to whether it should loop forever, but it's the number of times it should loop. My bad! [insert colorful adage about making assumptions and wot-not]
Apr 6 2014, 7:34 pm
In response to YnorRon
Source is best, if you have it. I'd like to know exactly what animate() calls are being made and how.
Apr 7 2014, 5:44 am
In response to Lummox JR
Sent.
Page: 1 2