Next Public Release Candidate (2014.2187)

Solar2D Daily Builds and Public Releases
#1

Hi all, just a quick note that 2014.2187 is our candidate for the next public release. You can download it from our daily builds if you are a Pro/Enterprise subscriber.

We’re interested in knowing if you encounter significant regressions against the current public release (2013.2100).

And if you do, the following pieces of information will help us reproduce the issue on our side, so we can squash those darn bugs:

  1. Device (e.g. Samsung Galaxy S3)
  2. OS/Version (e.g. Android/4.3)
  3. Sample files (e.g. zip containing main.lua, config.lua, etc)
  4. Description  (e.g. I expected X, but got Y)
  5. Bonus (e.g. started happening in build 2014.2181)

thanks!

walter

#2

Glad that we are finally close to another public release.  Just wish that more widget bugs had gotten addressed.  Like mine.  :slight_smile:

But glad that other users will finally get all the fixes in these recent releases.

#3

Walter, it seems this Daily Build doesn’t address the issue where creating/canceling transitions inside onComplete function of other transitions will trigger a memory leak. I know there is a lot of hard work to do with every Public Release, but, IMHO as Corona SDK is a game engine, an unpolluted transition engine must be essential.

Is there any chance the next Public Release will close this nasty bug?

Thank you and keep the good work!

#4

It would be helpful to post the bug ID of any bugs you are referencing.

#5

Sorry, here is my widget bug:

(Case 30464) scrollView issues: scrollbar jumps, scrollbar cut off at top, scrollBarAutoHide = false does not work reliably

#6

Hi Rob, Regarding transitions:

I filed the bug 29913 about storyboard class triggering enterScene event twice (but not createScene event) I’m pretty sure this is because storyboard uses the transition engine internally for the scenes, and enterScene is in the onComplete function of the transition.

There are some examples of bugs with new transition API in the forum, all of them have in common that are very complicated to reproduce and all of them involves the onComplete param.

http://forums.coronalabs.com/topic/42352-serious-problem-with-transition-api-in-20132100/?hl=%2Btransitions+%2Bbug#entry220586

http://forums.coronalabs.com/topic/40876-transitions-in-graphics-20/?hl=%2Btransitions+%2Bbug#entry215167

 

http://forums.coronalabs.com/topic/40156-transitions-20-callbacks-may-end-out-of-context/?hl=%20transitions%20%20bug

 

http://forums.coronalabs.com/topic/39522-error-after-update-to-coronasdk-20131208/?hl=%20transitions%20%20bug

#7

So good to be back.  Since we don’t have access to the casenum data, what is the “fix” for getTunerVolume?  Are we going to get more reliable return data?

Release notes for build 2014. through 2014.2185
Fix getTunerVolume() for casenum 25702

#8

Transitions with easing.continuousLoop are broken. The value, being transitioned, goes bananas through zero.

And I need a parameter in transition call to disable setting transitioned variable to the end value after the transition ends.

The way it’s now, easing functions are not honored and I can’t make cool effects with custom easing functions.

For example I need an enemy walking left and right continuously with sine easing. I prepare my easing function and it performs perfectly, and at the end of the cycle enemy returns to the starting point. But due to this transition behaviour a flickering occurs between each iteration. Enemy jumps from starting point to end point and then back to starting point. Very annoying.

#9

Please please fix the problem with rounded rectangles.

This little code should result in 2 identical squares, except upper square has rounded corners. Instead it produces this:

7VcCvXA.png

[lua]-- Resize a rounded rectangle, output should be a square 100 by 100 

local roundedRect = display.newRoundedRect(display.contentCenterX, 150, 25, 25, 5)

roundedRect.width, roundedRect.height = 50, 50 – Try commenting out this line to see difference. Size will be correct but corners not rounded correctly

roundedRect.width, roundedRect.height = 100, 100

– Correct 100x100 rect for comparison

local rect = display.newRect(display.contentCenterX, 350, 100, 100)[/lua]

Just paste into main.lua and run to see it.

  1. Device  All
  2. OS/Version  All
  3. Not worked since G2 was released. Case 38847, reported 3,5 months ago. I 
#10

jonjonsson, this is not a bug. It works that way by design.

You have to create a big rounded rect first and scale it down if you need different sizes. Or recreate the rect each time you want to resize it.

#11

So I resize a rounded rect to 100x100 and get a 200x200 instead is not a bug? What is the reasoning? Worked fine before G2 as well.

#12

Ah, you are talking about the sizes. Sorry. Yeah, that’s not right. xScale, yScale work correct I assume?

#13

Thanks for the help. I’m not seeing any problem with xScale, yScale. But yeah the corners do not look nice after a scale.

#14

Hey everyone.  Walter asked specifically for regression bugs.  These are bugs that were not in 2100 but are currently in 2187.

If you are going to report a bug in this thread it needs to a) be a regression bug.  This isn’t an open time to ask that a bug you need fixed to be fixed.  If we tackle all the bugs we won’t be putting out a release build any time soon.  Please only regression bugs.  We will work on non-regression bugs after the release.

If you are going to report a bug in this thread include all four of Walter’s requested information pieces (and the 5th bonus one).

Thanks

Rob

#15

But some of the issues above are regression bugs from before 2100… what about them? Bugs not found in G1 but now present in G2… Walter doesn’t want to know about them? 

#16

Hi Rob, all of bugs about transitions appeared between public release 2072 and public release 2100, I expected to have it fixed in the next public release, and, since this post is about the next public release, that’s why I wrote about them. If you only want to know about regression bug between 2100 and 2187, well, this is not, because the transitions works in 2187 as bad as it does in 2100 (sorry). 

If you are still interested in fix this bug here is the information with the steps walter asks for:

1. Devices , all of them

2. OS , all of them

3. Sample files : https://www.dropbox.com/s/8xww9vnd1medyom/Bug.zip

4. Description : 

This sample file uses storyboard to represent the problem with transitions, onComplete and transitions cancel because it was the only way I can reproduce it. You will see the enterScene event firing twice, if you remove the fade transition changing scenes it works fine, if you comment the transition.cancel line, it works fine, if you add a timer.performwithdelay (even with 0 time) before calling transition.cancel it works fine.

5. Daily Build: 2085, (with 2082 and before works perfectly). 

There are other bugs with transitions API, all of them seem to appeared in 2100, I provided you links to the forum posts where other Corona users reports them, and sometimes, corona staff answers saying they are investigating it…

Thank you for your time and your help with this.

#17 
local webView = native.newWebView(0, 0, display.contentWidth, display.contentHeight) webView.x = display.contentWidth \* 0.5 webView.y = display.contentHeight \* 0.5 webView:request("http://www.upworthy.com/matt-damon-asked-a-cheery-13-year-old-what-shell-do-with-her-free-time-her-answer-gave-him-pause?c=reccon1")

Above code launches a webView and loads a webpage with a YouTube video embedded.

If you run it in iOS devices (iPhone/iPad), the video cannot be played. (After you click on play, the loading indicator spins a bit, and then nothing happens)

The video can be played in Simulator & Android devices.

I believe I played YouTube video in a webpage before with an iOS device.

Is this a regression bug? 

#18

@joe528 does it work with build 2100?  If it works with 2100 but not now, it’s a regression bug.

@ksan, we want to know about all bugs, but by filing them in the bug reporting mechanism.  We think 2187 is at a point where it can be released.  If you think about people who only use public builds, we are not looking for bugs they already have but bugs that would be put upon them they don’t currently have.  Does that make sense?

@GulliermoFG, it sounds like this is an issue that folks running 2100 already have, so it would not be the kind of bug Walter is looking for.

Rob

#19

With the latest build 2187, newLine StrokeWidh is no longer reliable. Was working perfectly with 2156, 2179 and 2100

We are drawing line in our list and now line height is no longer the same. Even if we ask 2 pixels, it is sometimes 3, sometimes 2. Nothing in our code has changed. Has always been working before. bet when we installed on 2187, kaboom. Problem in the sim, on android (every single devices we have) and on all iOs devices.

#20

@GulliermoFG, thanks for the data and a complete zip of your project! We’re looking into it.