Cocos Creator v1.4.0 beta releases(02.07 updated rc.2)

beta.5 updated on 12.22

3 Likes

@nantas2 I can confirm this works great! Now I have been able to open the editor. I’m doing some tests with a small project and compiling iOS version. So far so good. Thanks! :slight_smile:

1 Like

Awesome! Thank you for your feedback!

Hi jyinkailej,

thank you, now in beta 5 looping works again here.

Take care

Michael

This will greatly improve loading time of my project. Thanks ! :heart:

Thanks for the fix :slight_smile:

I’ve noticed a few other unexpected behaviors that could be looked into:

When using slicing for sprites, if the original texture is bigger than the target size of the node, instead of using slicing, the texture is just downsized and stretched. What I think that should be done is downsize the texture along with the coordinates for slicing and use slicing on the resulting texture and coordinates to create the node. The reason I bring this up is that if I use smaller textures, so that the bug doesn’t occur, there will be much upscaling for my highest target resolutions and everything will be blurry. Here are 2 images showing the problem:

Wrong - downsizing and stretching

What should be - downsizing and slicing

My second concern is with the scrollbars in the ScrollView. If I try to make the scrollbar shorter than the ScrollView, the scrollbar behaves very strangely and exceeds it’s limits when scrolling. This is probably because its maximum size is calculated from the ScrollView instead of the scrollbar. Also another thing that bothers me is that no matter what I do, the bar node always gets stretched to full width/height of its parent node (depending on horizontal or vertical scroll) and I can’t have a bar that is narrower than its parent. For example in the ProgressBar control you set the position of the filling bar and set its maximum length and it only resizes it in the direction of which the bar goes (actually the 2 upper images are from a ProgressBar :slight_smile: ). Here are images to illustrate the problem:

Narrower bar (set in editor)

Bar is stretched when running the scene

Bar exceeds the scrollbar’s limits when the scrollbar is smaller than the ScrollView

On a side note, do you plan to have a different sprite in the PageViewIndicator control, as currently all of them use the same sprite and a color is applied to the indicators that aren’t for the current page? Maybe have something like the transition property of buttons and be available to select from color, sprite and scale, instead of being hardcoded to color only.

Edit: I found another bug after trying to mask component, so I’ll add it to this post as an edit instead of writing a new one. If you use the mask component with a sprite and then add a sprite node as a child to it, the image gets the shape of the mask. So far so good, but when put inside the container of a ScrollView, if the image is outside the view (due to scrolling), it is rendered fully (without the mask) when it should be clipped (not rendered at all) because of the view. Maybe both the view and the mask use the same logic and they cancel each other somehow and this should be fixed.

beta.6 updated on 12.26

could you provide a test sample to me, I will check the issue.

As stated in my previous comment, beta.5 fixed the issue for me :slight_smile:

In beta.6 nothing has changed for the issues described in my comment from 3 days ago, but I guess that in the next release they will be looked into.

Edit: Actually in beta.6 it seems that the id parameter from cc.loader.load is changed to url which is fine (as you probably meant for it to be url from the beginning). But there is a problem with the callback. It returns a null texture and null error on it’s first call for each url, so my interface ends up with empty spriteFrames unless I call it again or query the textureCache for the url after some time has passed. Could you look into that as well ?

How are you using cc.loader.load exactly ?

Actually the id parameter is deprecated because we need to define it internally, if you pass an id and find it being modified after load, it would be annoying, so we decide to not permit id parameter. You can use url or uuid instead.

beta.7 updated on 12.29

I’m using it the same way as I did in beta.5 - with the exception that in beta.5 it didn’t work with url and required id instead and now in beta.6 it is the other way around.

cc.loader.load( {url: this.imageUrl, type: 'jpg'},  function (error, texture) {
                    // handle loaded texture
                    cc.log(error, texture);
                    self.imageLoaded(texture);
                });

imageLoaded: function (texture) {
        if (!texture) {
            cc.log('no texture');
            return;
        }
        this.image.spriteFrame = new cc.SpriteFrame( texture, this.image.spriteFrame.getRect() );
        this.image.spriteFrame.setRect(cc.rect(0, 0, texture.width, texture.height));
    },

In the web browser log I see:

null, null
no texture

for each picture that I try to load. They are https, but they worked fine in beta.5 so I don’t know what is broken in beta.6 except that which I already explained - I get null texture and null error, but if I try to use the texture by its url from the textureCache it works, so the load callback for the cc.loader is somehow messed up in beta.6.

I’m currently downloading beta.7 to see if the issue is fixed, but from the looks of the changelog neither this, nor the things described in my other post have been looked at.

Edit: Yup all the issues are present in beta.7 as well.

Thanks for the details, I’m looking into it

Can you give me one url that triggers the problem here ?

I tried one https url but got the correct response, we do modified a little bit the logic for https image urls, here is the steps:

  1. we will try to fetch https urls with img.crossOrigin = 'anonymous' setting, if the server accept, then everything will be ok, texture will be created
  2. If the server doesn’t accept, then we will continue as if an error occurred, because even if we succeed to load the image without crossOrigin setting, the image will failed at texImage2D call after loaded

Sure, here are a couple:

https://scontent.xx.fbcdn.net/v/t1.0-1/c33.33.414.414/s50x50/309471_10150825926290385_420917735_n.jpg?oh=3277927cf45a7967323446ec7f0b35ac&oe=58D79564

https://scontent.xx.fbcdn.net/v/t1.0-1/p50x50/13754440_10101287690280660_823608416174929974_n.jpg?oh=f9288f094ebaf3b3f4229ac4b8ba7c5d&oe=592416C8

https://scontent.xx.fbcdn.net/v/t1.0-1/p50x50/14956023_10101920307465703_1169248491202415469_n.jpg?oh=c9a297d8fd885c0a712195d370476bf1&oe=58E4A5DF

I can confirm this as a bug of loader, the url stored in cache have been modified, it will be fixed in the next release. Thanks ~

Great, thanks :slight_smile:

If it is possible I would like at least a comment on my other post on whether the things are going to be fixed or not, so that I can know if I have to wait for a next release, or try to find a workaround myself.

For that problem, please give a sample to @owen, he is the owner of UI module, and he did asked for a test sample :wink:

Sorry, since his reply was to the post with messed up textures (which was fixed in beta.5) I thought that nobody had replied to the other post. I’ll try to make a minimal project to showcase the issues and upload it :slight_smile:

Here is a minimal project illustrating the issues outlined here

GuiIssues.zip (177.7 KB)