Animations hang when scrollView is scrolled after upgrading to new build

Audio and Graphics
#1

I’m having problems with scrollView widget after upgrading to the new build.

In the old build everything worked fine. I have a simple game where there are a few subviews implemented by using the scrollView widget that have lists of elements that can be scrolled. At the same time in the main game area there are some transition animations going on, and in addition to those on top of everything there are transitions going on.

However, when I scroll the scrollview, every transition that is currently clipping with the scrollview stop immediately.

The images can still be seen, and if there’s sprite animation involved, the sprite animation continues. Images receive touch events normally. Only effect seems to be that active transition is stopped when scrollview scroll event is activated.

In the previous build, this didn’t happen and I haven’t touched the code.

Does anyone have any idea how should I start resolving this problem?

#2

I corrected this by using the v1 of widget library, but I had to manually comment out all the setReferencePoint methods in the source code because I already migrated the code otherwise to v2 and didn’t want to put on the compatibility mode. 

Would be great to have a fixed version of the v2 library at some point.

#3

add:   

graphicsCompatibility = 1

to your config.lua at the same place you set the width and height.   This will make the G2 engine recognize reference points and the 0-255 color ranges.

Rob

#4

I know this, but as I already migrated my old code to support v2 reference points and code ranges, I don’t want to go to compatibility mode anymore. It was easier to migrate the old widget.lua to remove reference points as they didn’t break scrollView. 

But this is side issue, the original issue is v2 scrollView breaking other element translationTo:s

#5

Widgets with G2.0 should be fully compliant with G2.0 positioning methods.

#6

I’m having this issue too. Not only if an element is scrolled inside a scrollview (for example, loading images inside the scrollview rotating with transition.to) but also on other occasions too (that I’m still trying to figure out).

What did you really did “matti.paalanen”? Because I already have “graphicsCompatibility = 1” but it still doesn’t work.

Does it have anything to do with the “onComplete” not being called?

#7

What I did was that I downloaded the published version of the old widgets code and saved it as a distinct lua file into my project. Then I edited it by commenting out all the references to setReferencePoint calls.

I don’t use the compatibility mode in my project because otherwise I already migrated to 2.0

So I just manually changed the widget imports to use this modified 1.0 lua file instead of the official widget library and now everything works ok.

#8

I can’t upgrade mine now but, I found a solution for the scrollview:

function fix.transition.to(target, params) if (params and params["onComplete"] and (not params["onPause"])) then params.onPause=function() transition.resume(target) end end return transition.to(target, params) end

It seems that scrollview pauses the transitions of it’s childs when moved and so, all that I need to do is call resume on pause for that case.

But I’m still having problems with another things and transitions. There are situations when sometimes, when I click on a button that slides 2 groups from right to left, the slide stops (and some other animations not related to it stop too) or the loading images that come inside these groups stop rotating.

This is weird because it only happens sometimes and also stops some animations that are not related.

#9

Ok, I solved that. I was using a recursive function to spin the loadings and the only change I made was make it local instead of global to self image element. Now I use the fix I post before on every transition and it works for me =).

#10

Has anyone filed a bug report on this?  If not, can some file one please?

And please post the bug number back to this thread.  You might want to include a link to the thread in the bug report.

Thanks

Rob

#11

Well, I don’t know if it is a but or not because it makes a little sense to pause transitions when they are not visible. But they should be resumed when they become visible again I think.

#12

I would agree that pausing them when off screen makes sense from that perspective, but not resuming them when they come back on screen still seems like a bug.  If we want engineering to look at it, they will need a bug report.

Thanks

Rob

#13

I submitted it as a bug. It’s the first time that I did that and so, I don’t know if it is ok but, I think it is.

#14

Thanks for the information! Hopefully we’ll get a bugfix soon

#15

This was fixed in daily build 2088.

Rob

#16

Ah ok, good to know thanks! 

As I don’t yet have subscription to daily builds, is there any rule of thumb, how long is the official version update cycle if it contains these kinds of bugs?

#17

We don’t have a set schedule on when we release new public builds.  There are many circumstances that drive when.   But in this case with Graphics 2.0 being so big of a change and some other fixes that impact many people, we will likely have a new build sooner than later, but I can’t commit to a time.

Rob

#18

But matti.paalanen, I believe that you can use my fix on 2013.2078. At least I’m using it without any problem. Unless you really need to use the “pause” callback for anything else. But for the most cases, the fix should work =).

#19

I corrected this by using the v1 of widget library, but I had to manually comment out all the setReferencePoint methods in the source code because I already migrated the code otherwise to v2 and didn’t want to put on the compatibility mode. 

Would be great to have a fixed version of the v2 library at some point.

#20

add:   

graphicsCompatibility = 1

to your config.lua at the same place you set the width and height.   This will make the G2 engine recognize reference points and the 0-255 color ranges.

Rob