Progress of graphics backend integration

cocos2d-x
#21

O no - it is not good news.
CustomCommand is only wrapper for user onDraw() function which put to the general queue.
Why can’t user call GL library independ backend functions directly from the onDraw ? Or use macroses and call certain library dependent functions (metal, oipengl). It was very convenient.
For example what to do if needed to reset translation of the camera View Matrix before passing it to the shader, for some rendering objects?

#22

We can keep the function, but i don’t think it is needed, as you can see, now LayerColor doesn’t need to invoke backend dependent API: https://github.com/minggo/cocos2d-x/blob/metal-support/cocos/2d/CCLayer.cpp#L483. It is better don’t invoke backend API directly as possible, because it is more convenient for engine to optimize the backend without affecting other codes. For example, the API may change if we support multi-thread rendering or support vulkan later, and it may change the backend API.

#23

Update: support ProgressTimer without rial mode because metal doesn’t support GL_TRIANGL_FAN.

#24

I see that you reimplemented CustomCommand very much. Do you mean that only opportunity to set user ‘onDraw’ callback is excessive?

Clarify please about LayerColor. The vertex buffer is updated on each frame in the ‘draw()’ function? Why this implementation?
There are functions which beat performance (malloc, free, copying to the gpu).

I mentioned about necessity to reset Camera Translation for some objects, like you did for SkyBox.

It would be great if you leave ‘onDraw’ for a first time. May be will mark it deprecated. It will help to accelerate port of the existing code at least.

#25

So just simply remove functionality which is required?

#26

@squares no, we should simulator the behavior before releasing.
@solan i think i described the reason above. I mentioned LayerColor just want to say, onDraw is not needed, you can ignore the detail implementation. And you can see ProgressTimer. It is simple now. We can discussion it again after we finish adapting. Adapt to new backend API is more or less the same to adapt to new custom command.

#27

Should say, that it is very good idea to accomodate all needed rendering information in one place. It should be very lightweight. I really wait your progress! Good luck!

#28

Update:

  • all label effect works without underline effect
  • particles system works
  • some tilemap effect works
3 Likes
#29

Update:

  • rendertexture without saving image support
  • effects(grid3d and tiled grid) works
  • transition works
  • almost all UI components work(it is not merged, in testing)
  • draw node works(not merged, in review)
2 Likes
#30

Awesome, keep it going! By the way: is there much left to do? Do you have some sort of list?

1 Like
#31

Most of 2D features are supported, spine and 3d feature is not started.

#32

Update:

  • draw node merged
  • add UI back, some tests works
  • clipping node works without alpha test
Final topic about Anti-Aliasing disease
#33

Update:

  • iOS uses metal too
  • Android and windows can work, but use cmake instead
  • progress timer support radial
  • support scissor

I will send a PR to cocos2d-x for metal-support, then developers can join the development. I don’t know if we can call it v4, but it breaks something. I will name it metal-support currently.

After supporting spine, i will release a alpha version. Then we will continue to support 3D features and fixing bugs.

3 Likes
#34

Awesome. Motion Streak implemented?

#35

Not yet, it is quick to support it.

#36

@kiranb47 motion steak is supported.

#37

ok great. We will also start testing when alpha version is available.

#38

update:

  • fast tilemap works
  • fix depth test issue
  • physics test works
  • can show stats information
  • improve performance of layer/progress timer
  • custom command supports index format
  • correct synchronization between CPU/GPU in metal
  • spine supports, because it will break spine runtime license, so we will not merge it before it is accepted by spine author, you can merge the PR manually to have a try.

Refactor uniform setting to improve performance will be finished in days. After that, i will sync all the codes to official repo, then release an alpha version. So the alpha version will be released in this week without 3D features.

1 Like
#39

There may be an issue with that. If the changes are merged in, wouldn’t it break Spine for the current Cocos2d-x 3.17.1 and lower versions? If that is the case, then there needs to be preprocessor checks added anywhere the code would cause issues with the currently released versions of Cocos2d-x, otherwise there would need to be a completely separate release of the Spine runtime for the new Cocos2d-x.

Side-note: Spine now have a cpp runtime available, and will no longer update the cocos2d-x C version going forward (they will maintain it, but they will not add new features). The spine-cpp runtime is now the default to use for Cocos2d-x. More info here: http://esotericsoftware.com/blog/Spine-3-7-released#Spine-cpp

#40

We discussed it with spine author, and it will be in a new folder, it will not affect spine-c/spine-cpp.