Forum > C# > Winter is coming..

Winter is coming..

By cerberillo Posted 2012-02-19 18:20 Comments 5
  • Posts: 1

Hi there[]()

I’ve been surprised with the new of an official XNA branch of Cocos2D.

My last year work (part of it) has been the development of a huge Cocos2D port for XNA from iOS version, so in this year I know perfectly also what is needed to be done and what problems you will encounter.

To be more practice, in first place I wish to offer myself as an official developer of Cocos2D for XNA , I’ll be very pleased in helping you guys with the development because I’ve done this before and I know the road.

In first instance I can tell you that this porting will be very painful in performance just having a quick review on the code. XNA philosophy is not followed EVER in your port, and you will have serious problems on that, your FPS will fall down to hell as soon as you use hard particle systems and sprites because you are using Draw loop to calculate EVERYTHING, when Update loop is the one in which is supossed to be don that stuff.

I will follow Cocos2DX very close and expect you all consider my offer of entering as a part of the development team.

Thanks a lot for your effort!

  • Posts: 171

#1 RE: 2012-02-20 02:36

hello, David, Cocos2D-x for XNA is an open-source project, you are welcome to pull request.
When you make enough constributions, you will naturally become a core developer.

  • Posts: 171

#2 RE: 2012-02-20 03:33

to David:
about particle system: bug 981( has been created.
in fact, i have changed the particle system draw into 3d way before, but the performace seemed to be slown down.
about update loop: i don’t quite catch you. Now in cocos2d-x for xna, update() is used to update data, and draw() is used for rendering.
  • Posts: 243
  • Location: Totally Evil Entertainment - San Diego

#3 RE: 2012-07-06 16:14

RongHong, the Update versus Draw advice from David is about the pipeline implementation that game developers are confused about in XNA.

The Update() pipe is asynchronous with Draw(). Just as general advice, if you put any long calculations in your DRaw() that update game state, then you will suffer serious performance problems. The Draw() is just to draw screen elements. Update() is where all game state logic should occur.

So far I’ve seen the cocos2d-xna port perform pretty well on a variety of platforms,even Android using MonoAndroid. Our current effort is to get it working back on iOS using MonoTouch. This has not been as easy - none of the sprites show, but the game interactions are there. As with all platform ports, the core graphics hardware tends to be different to the point of nuance and frustration.

XBox 360 : On there
Windows 7 Desktop: On there
Android : On there
iOS : On there but sprites are not drawing as visible

ALL of this is with the same (yes SAME) XNA game code. NO changes at all to the game. Just a platform driver to implement the UIView main or Activity per iOS and Android, respectively.

Good job guys. There are some implementation holes in cocos2d-xna that need to be plugged, but otherwise, it’s a great API for doing some cool effects.

— Jacob Anderson, Totally Evil Entertainment.
  • Posts: 243
  • Location: Totally Evil Entertainment - San Diego

#4 RE: 2012-08-08 18:40

I have begun the process of moving non-UI specific updates to the update() pipe. The scheduler “tick” is now in the application update() call instead of in the drawScene() call chain. All tests work just fine with this change. The scheduler will receive more tick() activity now.
  • Posts: 243
  • Location: Totally Evil Entertainment - San Diego

#5 RE: 2012-08-10 17:25

I do see what David has referred to in his initial post. None of the code in this library is designed for multi-thread awareness. When I pulled the scheduler into the update() loop, I found some random partial-state conditions in the transition classes, which make use of the Tiled engine. That code makes not attempts at thread awareness or state-readiness flagging, so the update() calls hit objects that are partially initialized and thus throw NREs and other problems.

This is a reasonably large effort to make this library XNA-ready. I’ve already started, but it’s going to be quite a bit of work.

One thing I am doing along the way is removing the rampant temporary object creation that plagues the code. new ccGridSize(x,y) is the bane of performance when placed in a nested loop. Constructing over 1000 ccGridSize() objects just to do a logic test is horrible for performance.

Loggin to reply

Copyright © 2010 - 2013 Cocos2d-x.orgClustrmaps