OS X compatibility

Hello,

I am completely new to the Cocos2d-X, so i am sorry if this question is silly. Can I use this framework to also build game for MAC? Currently I don’t see any project dedicated for OS X. And second question is about Win32 port, i am supposing that it still runs on OpenGL (ES). Is there a way or someone who is working on DirectX port for w32 platform?

Thanks …

Jirka

  1. cocos2d-x hasn’t support osx yet. It’s in the plan but maybe in 2~3 months later
  2. win32 port depends on PowerVR OpenGL ES library. It will be move to OpenGL dependance. Why you perfer DirectX than OpenGL?

It’s rather psychological reason. Currently we are developing casual games (win32/mac) - approx. 5 - 6 published. It was written a lot of articles about win7/vista performance issues with opengl. That’s why i am asking.

My question is: We would be able to write DX wrapper/implementation by ourselves. But we are kind of worried about huge variety of cards/hw. Would it be possible for you (cocos2x) to adopt back this wrapper? There are secret hopes behind that our code would be revised tested by other developers which would surely appreciate option of running on different render engines.

Jirka

Sorry, the feature of renderer wrapper isn’t in our plan.
cocos2d-x is mainly facing to the mobile games dev. For desktop games, flash is the most popular solution to write tiny games and cross-platform.

I too would love to see the OSX version running. I’m writing a tool to help me layout the levels in OSX using wxWidgets and cocos2d-mac, but would love to use the c*+ version as that is the version I would like to use in the c*+ port.

Nick

I would also be interested in a DirectX option for Win32. OpenGL is very good, but if the system is Win7/Vista and the user does not have a dedicated video card, it will work a lot better with DirectX.

With the limited resources, we deside to cut down the plan of OpenGL version on both win32 & osx, and only focus on various mobile platforms.
For casual games on desktop, Flash is a far more better choice rather than cocos2d. We don’t have competitiveness on desktop systems.

I’m not looking for an opengl version, just the equivalent of the version that compiles and runs on win32 currently (using some open source egl libraries). How difficult is it to get the currently running win32 version on mac? I would like to use this for tool development.

@Nick Torkos
The win32 version depends on PowerVR Insider SDK, http://www.imgtec.com/powervr/insider/sdkdownloads/index.asp
For PC Emulatioin, it only offers Windows Vista/XP & Linux version.
Can you find an OpenGL ES 1.1 Emulation on mac osx? cocos2d-x can easily run on this emulation then.

I will look. All one would need is a wrapper to map the calls to opengl. To have the code run in a wxwidgets window, I won’t even need the surfaces … just the equivalent drawing functions (unless I’m over simplifying it). For example, this looks like a wrapper library: http://sourceforge.net/projects/dgles/ I’m okay not being able to support powervr textures in the tool, and I could try getting the wrapper running on my own … I’m not quite sure how to start. When you port over to another machine, which classes do you get working first … the View and the Director?

Nick

I would absolutely love to have this running in a wxWidgets window (win32/mac)

I want to get the mac version working. The windows one works but isn’t current with the latest sdk. I just took the windows port and made a new class for the view, put in a couple of #ifdefs to make sure it compiles as a wxwidgets object, and passed the panel’s HWND to the constructor. If I can get it to work with an opengles->opengl wrapper then the code would be cleaner and would run better and be more portable (since I noticed issues with window resizing with the powervr library, so I don’t resize the surface, I just make sure the first one I pass is big enough). No changes had to be done to the rest of the code which makes me really excited. With a mac version running, it wouldn’t take much to write a level editor and asset packer that runs cross platform (which is my ultimate goal). If you want specifics, I can go back to my code and refresh. Ideally the wxwidgets version should be a platform branch of the cocos project.

Nick

Nick, your work is so awesome and very valuable.
In fact, the rendering wrapper of opengl es 1.1 / es 2.0 / opengl is the bottle-neck of cocos2d-iphone & cocos2d-x. Current design in cocos2d-iphone, using lots of #define, is not elegant at all. That’s why I cannot easily port it to cocos2d-x. If we can refactor the wrapper, it will also mostly help Ricardo Quesada to improve cocos2d-iphone, and make gles1.1 / gles2.0 compatible in one branch.

Since cocos2d-iphone supports mac development, how difficult would it be to support mac in cocos2d-x? I would rather not use wxWidgets on Mac because that would bring another unnecessary dependency.

OK, after arguments in cocos2d-x team, we decide to keep the opinion.

For cross-platform games on mac osx, it’s better to use flash.
For cocos2d tools & editors, our suggestion is to use cocos2d-iphone osx version by now. The members of cocos2d family are sharing the tools & editors. So if cocos2d-iphone parse and show the output file of your editor correctly on osx, than cocos2d-x will also do it well on win32,ios,android. You can use cocos2d-iphone osx version to implement the visualization, save the output file, then copy and use it on android via cocos2d-x

Deciding no to do is much harder than deciding what to do.

I managed to get cocos2d-x running using the desktop opengl es interface on windows. Attached is an example where I use the dgles open source library (with some changes) in wxwidgets gl canvas. It seems like its working. I had to install the latest opengl on my pc, also download the extension headers, link with glew library to help with opengl extensions, change dgles to get it to work, and comment out a couple of things in my current version of cocos2d-x (I am not current). I would like to see if this version works on mac (or make the appropriate changes to get it to work on mac). I like this approach better since it did not require any of the eglsurface code, just a standard open gl window. Most of the calls should produce the same results, except for the framebuffer capture calls, but I’m okay with that since I don’t really intend to make a saleable game on pc or mac, just to debug and also build visual tools for laying out objects + editing data, and save it out as an XML or binary version of xml for gameplay.

Attached is a pic of my test case, with cocos2D embedded inside a window. The framerate says zero because at the moment I am only updating the director during render. I kept it there to show things actually do render. I didn’t do a deep analysis of what works and what doesn’t since I just got it to compile and not crash. Also, its just opengl calls which should technically work. At some point I will separate the render/update portions of the gameloop so that the render occurs during the window draw and the update can happen in a thread at regular intervals. It wasn’t too much work to get everything functional, but for me it took a while to find time to work on it … work and family taking up lots of time at the moment.

Nick

woa, awesome!
I wonder if dgles is stable enough so we can use it to replace the powervr library. That will be more feasible & closer to cocos2d-mac port!
Thanks for your work! But I can only see a screenshot in the attachment. Is there any binrary or source I can run on my pc?

I just take a view of http://dgles.svn.sourceforge.net
It last commit at May 31,2006. http://dgles.svn.sourceforge.net/viewvc/dgles/tags/?view=log
Oh my father god, 5 years ago! Is this library reliable?

Yeah it’s old. It’s not the prettiest code. But there’s not much to it. And it’s really just a stub. What I did was take that code and change it to make it easier to work with as a library. In my cocos2d-x project I just added the few files to the library and made it work with glew (another library but current and well maintained) so that I could stub in OpenGL 4.1 extensions when appropriate. After that most of the compile errors were gone except for some ogles framebuffer calls, which there were no stubs for. I just commented those out for now but can put in stubs at some point when I have time. In any event the end result was OpenGLES version 1 compatibility without requiring anything but an OpenGL context. I’ll try to put up the executable when I can package it. My main interest is getting a crossplatform version I can make a tool out of. After scrambling around and failing the dgles option seems to still be the most promising.

Sorry bump this thread.
I just hope Cocos2D-x could support Mac OS X and Mac App Store.
Since the Mac App Store support In-App Purchase.
It’s a important business model that Flash can’t do.
Plus performance, Box2D Physics…etc.
And want this engine to meet its name “x”.