Cocostudio 2.0, cocostudio2.0

Cocostudio 2.0, cocostudio2.0

Recently, cocostudio was started, mainly used for UI. I don't want to talk too much about it. I just want to say that an editor that is highly respected and heavily developed is not as good as a plug-in Unity. Previously, I felt that NGUI was difficult to use, but it is much more convenient and powerful than DF GUI.

1. Basic usage:

Edit the interface in CocoStudio, and then export the resource. After the export, the Resource Directory and csb file are displayed. We can directly load this csb file when using it. It is serialized by protobuffer. CocoStudio2.0 does not support json format at the moment.

Lua Load Code:

Local node = cc. CSLoader: createNode (file) -- TODO looks like a full-screen local panel = node: getChildByName (panel) -- Dialog Box panel

    scene:addChild(node)

2. Multi-Resolution processing:

Cc. Director: getInstance (): getOpenGLView (): setDesignResolutionSize (1280,720, cc. ResolutionPolicy. FIXED_HEIGHT)

By setting the design resolution, the design resolution is the default resolution when the UI and game content are created. Once determined, the resolution will not be easily changed. The last parameter determines the zoom of the window with different actual screen resolutions. Whether it is SHOW_ALL or NO_BORDER or FIXED_HEIGHT depends on the actual needs. In fact, none of them can solve my actual problems perfectly.

Generally, a non-full-screen UI does not need to care about multiple resolutions, and the controls in it do not need to care about the anchor, relative location, or something, because the interface size is fixed (whether it is 960x640 or 1024x768, the interface is so large ). Some UI content that requires full screen processing must be specially processed, such as the main interface. Generally, the main interface needs to display the Avatar content in the upper left corner, a series of buttons in the lower right corner, and a series of buttons in the upper right corner. At this time, cocostudio only uses one interface, and it seems powerless. My solution is to divide the content into three panels and load them separately, then, the panel is placed at the destination position based on the corresponding anchor relationship (for example, in the upper right corner of the anchor point, the anchor point of the corresponding panel is set, set the coordinates to winSize. width winSize. height ).

Full Screen stretching of background images also requires special processing. In general, we need to stretch the background image without deformation (to maintain the aspect ratio), and fill the whole screen with no black borders.

To sum up, it seems like this. cocostudio cannot be used to control the entire ui system. The display position of the interface still needs to be controlled by the upper-layer logic code. Although it is not very troublesome, it is always relatively low. Of course, it may be that I have not mastered the corresponding skills, and you are welcome to criticize and correct them.

3. Node: getChildByName is non-recursive:

Directly Using getChildByName is non-recursive, and a rootNode cannot be used to obtain the child control. Cocos2d-x v3.2 provides a function to solve this problem: enumerateChildren. The usage is as follows:

function util.ui.getControl(root, name)    local control;    root:enumerateChildren('//' .. name, function(ret)        control = ret;        return false;    end);    return control;end

This function is a little weird to use, but it is still quite powerful. You can specify the path or fuzzy search. For details, refer to the comments of the function in the source code.

4, Panel color filling by default, and the cocos2d-x v3.3 version seems to have a bug, the panel directly choose Fill to None, in the actual game will still have Fill color, you must manually set the Opacity value to 0. CocoStudio and its own programs do not have this problem.

5. The coordinates can be pixels or percentages relative to the parent window.

This is not a pitfall. It is estimated that they also wanted to use this system to replace the Layout System of the anchor. However, it is a little bad, because most dialogs only need to configure absolute pixel coordinates, and when automatic layout is required to adapt to multi-resolution, the relative layout of this set of percentages still cannot be properly adapted. That is to say, when it is normal, how can it be abnormal.

6. The packaging function is not provided. You need to package the imported resources.

This is not a pitfall. The original unified packaging has some disgusting problems. For example, the background image or some large images should not be packaged, but they should also be packaged. The current method is more free. I have not tried the compatibility of texture packer packaging. I guess there will be such a problem. I use the interface configured with the original image. After I replace it with plist, all interface images must be re-specified. If this is the case, it cannot be too harsh, but it does not seem human-friendly.

7. Insufficient controls and weak functions

For example, three-state buttons, single-choice Button groups, Tab labels, and other functions are not available, and I want to directly control the image style by setting the Button status.

Of course, these are not true, but they only need to write some additional code for processing. Compared with NGUI, df gui, and even Unity's new uGUI, NGUI is much better than it.