Home / Topic / 3.24c Problem

3.24c Problem

Viewing 15 posts - 1 through 15 (of 24 total)
  • pkay@twitch.com
    Participant
    #82533

    Alex – I’m not sure if this is a Kwik problem, a Corona problem or an iOS problem. Since the latest upgrade my builds work fine in the emulator but crash on the iPad – the page transition between 8 and 9 causes a crash on the iPad. Is there any way you can take a look at either the entire app or the relevant pages and point me in the right direction? I’m thisclose to launching the app…

    Peter

    Administrator
    Keymaster
    #82534

    I would suggest you to connect your iPad to Xcode by cable and run the Organizer option (then select the console option). Clean up the Organizer view and run your app in the iPad. All errors will show up there.

    I have sent already another similar situation to Corona Labs (they are evaluating it now) as, it seems, there are some issues with disposing memory. As soon as they reply me, I will update the code (if necessary) and release a new build.

    #82559

    Hi Alex!
    This sounds like the same issue I am having. I sent a note in the roadmap forum with some feedback I received from Corona in regards to disposing of the audio. I am wondering if it is also an image disposal issue as well.

    FYI – I did some comparison of my TexMem in the terminal from the app built in Kwik2 vs. Kwik3.
    In the Kwik2 build my TexMem fluctuated and never exceeded 20. In the Kwik3 build it starts at 31 and just continues to go up from there. It never goes back down after a scene change. By page 6 the TexMem shows 375 in the terminal which I assume is why it is crashing on my older iPad2 device. Let me know if there is any other data I can give you to help resolve!
    Thanks so much!
    Christi

    #82560

    I have tested every version of 3.2.4 from 4a thru 4c and they all have the texture memory disposal problem. Alex worked to correct this as recently as June and it was corrected, but I guess it didn’t stick. 3.2.4 does not have the problem, but is unusable, for me at least, because it crashes on exporting images (a problem none of the other later versions have).

    pkay@twitch.com
    Participant
    #82561

    Here is the console logfile from start til crash
    https://www.dropbox.com/s/s4h8pj0agostatw/FourSeasons

    Administrator
    Keymaster
    #82562

    Are you all navigating with the auto swipe or using a button with GoTo Page interaction?

    pkay@twitch.com
    Participant
    #82563

    GoTo page. I disbled autoswipe.

    #82564

    GoTo via buttons and the menu navigation.

    Administrator
    Keymaster
    #82567

    I sent you all an email with instructions on how to re-test it. Please take a look and let me know the results. If they work, I will create a new public build tomorrow.

    #82572

    As I responded, I tested this and found that the memory is now disposing properly when I advance the pages via the goto button, but not when I use another goto button and/or menu navigation to go back to previous pages (ie from page 4 to 3 or page 6 to 2).

    #82573

    I had the same results as well Alex. The update you sent fixed the disposal issue for the GoTo Next(auto) but not the Previous(auto) or when I chose to Go to a specific page.
    Thanks for working so hard on getting it fixed!
    Christi

    Administrator
    Keymaster
    #82574

    I am still waiting from Corona’s help on how to handle the issue with memory disposal. Unfortunately no news at this moment. Can you please let me know, meanwhile, if you see crashes on your device going backwards or via navigation menu?

    pkay@twitch.com
    Participant
    #82575

    I am using buttons to move forward and one button at the end to return to the beginning. Everything is working as expected.

    #82576

    Hi Alex! Only one crash on the device. (yeah!) and it looks like it is more with the Nav menu and only after quite a bit of use. The back button seems to be okay.

    dittophantassy
    Participant
    #82578

    Hi, i found this same problem with texture memory and I think I found a solution:
    In the go to scene logic I commented the removeScene call because I found out it was running twice, once in the go to scene and once entering the new scene.
    Like this:

    local myClosure_switch76 = function()
    local options = { effect = “fade” }
    — if nil~= composer.getScene(“page_2”) then composer.removeScene(“page_2”, true) end
    if self.type == “press” then
    self:setEnabled(false)
    — composer.removeScene( “page_1”, true )
    else
    self:removeEventListener( “tap”, onLayer_6Event )
    — composer.removeScene( “page_1”, true )
    end
    composer.gotoScene( “page_2”, options )
    end
    composer.timerStash.newTimer_276 = timer.performWithDelay(0, myClosure_switch76, 1)

    With this changes the memory stopped going up on each new page.
    Also I don’t know why the composer.removeScene is both in the “if” and in the “else”, it looks completely superfluous.

Viewing 15 posts - 1 through 15 (of 24 total)

You must be logged in to reply to this topic.

Privacy Preference Center

Strictly Necessary

these coolies are for WP-SpamShield, gdpr-wp, woocommerce, paypal

PHPSESSID, SJECT16, JCS_INENREF, JCS_INENTIM, gdpr, woocommerce_cart_hash, woocommerce_items_in_cart, woocommerce_recently_viewed, wordpress_, wordpress_logged_in_, wordpress_sec_, wordpress_test_cookie, wp_woocommerce_session_, AKDC, akavpau_ppsd

Functionality

WordPress cookie created when auto-saving a post in the editor.

wp-saving-post, wp-settings-, wp-settings-time-

Performance

google analytic

__utma,__utmb,__utmc,__utmz,_ga,_gid,_gat

Advertising