Does any one know how porting is done. Actually I want to port cocos2d to Qt platform & I have no idea about this. If anyone know please help me.
What you want to look at is not Cocos2D itself (which is pure python and will require a platform for which Python is available, including OpenGL / SDL functionality), but rather Cocos2D-X. That provides a cross-platform C++ API closely mapped to Cocos2D's python interfaces.
See:
http://www.cocos2d-x.org/projects/cocos2d-x/wiki
and specifically for Symbian / "Qt Platform", check:
http://www.cocos2d-x.org/boards/6/topics/373
Cocos2D-x already works with Marmalade, so if you want to take your Cocos2D game to iOS, Android, Symbian, webOS, bada, RIM QNX and more, check out Marmalade:
http://madewithmarmalade.com
Related
GNOME has chosen to not support server-side decorations under Wayland. That's okay, but I'm making a game in SDL, and I'd like first-class Linux support, including supporting running natively in Wayland (with SDL_VIDEODRIVER=wayland) under the biggest desktop environments (including GNOME).
Currently, when I run my game with SDL_VIDEODRIVER=wayland, no decorations are drawn. How am I supposed to integrate with the rest of the system? What's the story for non-GTK/Qt applications in practice?
The SDL2 developers are working on this right now: https://github.com/libsdl-org/SDL/pull/4068 So while there isn't an easy solution as of now, the good news is that you'll probably not really need to do anything than wait a few more months and then just use latest SDL2.
In general, the situation for non-Qt/GTK stuff is like this:
GNOME is currently not willing to introduce the decoration code into GNOME's compositor Mutter mostly from what I can tell are technical reasons: GNOME's decorations are GTK+-based, but Mutter has apparently zero GTK+ code right now so it's apparently not as easy to integrate as one would hope.
So non-GTK/Qt applications have three options: 1. they can manually implement it, or 2. they can use something like libdecoration as SDL2 is apparently going to do, or 3. pull in GTK+ as a dependency purely for the window and decorations which e.g. Electron/Chromium uses it for. It seems like in the medium term at least, GNOME will not fix this so these are the only options I'm aware of.
I only write QML app with Qt 5.1.1 running on Mac & Windows.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
Do the Qt on uclinux support QML? Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
First and foremost, please do not ask several subquestions in a question.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
There is no such a thing. Qt 5 is meant to be well supported for embedded, too, without external third-party projects.
That being said, you may ask Digia about their embedded plans, like Boot2Qt and so on.
Do the Qt on uclinux support QML?
That is the wrong question around. The correct question is whether Qt/QML suppports uclinux. I do not think this will work off-hand, no. You will probably start writing a custom mkspecs file for your scenario and fix lots of issues.
Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
That would probably be even worse as they are having a lot of overhead in terms additional layer. What I would suggest is to forget about QML for now, and try to bring up a simple screen with QScreen.
As stated, I do not think even that will work off-hand, but if you are enthusiastic, you could get it work.
Since Qt 5 has a hard dependency on the standard library these days, your first task is to get that building againt your mmu-free uclibc. There was some discussion about that here.
But honestly, you may be better off with some lightweight gui framework that supports framebuffer for rendering. Qt is big and not properly tested on minimal systems.
I am looking to get started with some 3D programming in C or C++. The problem I have is that it seems like the only tutorials I can find for Mac OS use objective C and Cocoa frameworks. I want to obtain the same environment as Windows users, more or less.
If I try to use a text editor and g++ compiler, I am missing headers, but, if I try to use Xcode, I am forced to grapple with Cocoa, which is frustrating to me. I don't really see any reason why the OpenGL/GLUT that comes pre-installed on Mac should force me to use Xcode, but it seems I can't get the header files without it.
How can I get through all of the Apple 'developer friendly' interfaces to write some old-fashioned code with full cross-platform portability?
Some portion of Objective-C is inevitable if you want to use the latest benefits of the OSX/Cocoa. The easiest way to port an existing application to MacOS would be the following:
Write the "bare bones" nibless application in Objective-C. It would only be a single AppDelegate class and a little setup in the main() function
Add the custom NSGLView descendant in your window which you create in the AppDelegate's didFinishLaunching event handler
Setup the CVDisplayLink and rendering callback in the NSGLView initialization
Use your existing OpenGL rendering code in the CVDisplayLink's callback
Now for the interesting part: where to get all of this ?
Surprisingly, a good nibless application sample is the UI for OSX's port of QEMU (yes, the emulator). Also the Apple's official GLEssenstialPractices demo shows all the information you need to set up OpenGL rendering pipeline. All the rest is up to you.
The detailed and modern introduction to system-level OSX programming can be found in the "Advanced Mac OS X Programming" book by Mark Dalrymple. It explains many things and after reading all of this I've understood most of the design decisions in the OS (it really makes you accept all the "non-standard" things if you think from the performance viewpoint).
To get through the "nibless" programming I would recommend you to read the blog posts like this one http://blog.kleymeyer.com/2008/05/creating-cocoa-applications-programatically-ie-nib-less/ The google search helps a lot.
The same tricks apply to the CocoaTouch/iOS and there are a lot of questions answered on SO, like this one Cocoa touch/Xcode - generating NIB-less graphics context
If you want to create cross-platform applications you could create a project with the Command Line Tool template.
Next, import the OpenGL and GLUT framework. This will get you a "blank" C++ project with the required OpenGL and GLUT headers.
Lighthouse 3D gives you some tips about portability and how to initiate your first project.
http://www.lighthouse3d.com/tutorials/glut-tutorial/initialization/
I have created a software layer (named cocoglut) that allows the translatation of basic or essential GLUT calls to COCOA. This library allows creating/destroying windows and register callbacks from a C/C++ application, just by using GLUT calls, without the need for nib files or for XCode project files (and can be compiled from the command line). This option uses full retina display resolution. The source is on GitHub.
After using 'cocos2d-iphone' in one of my projects, I am trying to decide which flavor of Cocos2d I should use for an Android game. My personal list of pros and cons:
Cocos2d-x
pros: it should be easier to bring the game to iOS later, potentially other platforms as well
cons/doubts: debugging c++ code on Android (easy or not?), compatibility of NDK app with various Android devices (how much of a problem?), accessing platform-specific functionality (in-app purchases, etc.)
cocos2d-android
pros: all Java, easier to setup and access platform-specific functions
cons: will have to translate from Java to either c++ or Objective-C for other platforms
Are there other issues with either of the options that I didn't think about? If anybody had to make this choice, what did you choose and why?
Note that there are two projects with almost the same name: cocos2d-android and cocos2d-android*1*. The latter is a fork of the former and its author did it because cocos2d-android project was almost dead.
In the beginning I was in doubt about cocos2d-android1 (which seems to be a very good work) and cocos2d-x but the possibility to develop in C++ (that I like a lot) and be multi-platform made me chose cocos2d-x.
I'm still trying to learn cocos2d-x.
What I like about it:
List item
it's a C++ framework
you can develop for Android, iPhone, Bada, Blackblerry Playbook, Windows and Linux.
Please, notice that at the moment cocos2d-x team advises that Windows and Linux port are meant for easy your development not for production.
it has a Lua binding
it has a version for Marmalade (a paid multi-platform SDK)
cocos2d-x works with NDK since release 4. Currently I'm using NDK r7. You can develop for devices running since android 2.1 (API 7)
It seems that there are some issues with cocos2d-x on android 4 (what shouldn't be a problem because both it's still not that wide spread and cocos2d-x team will fix any problem they come across).
You will be able to access platform specific functionality like in-app purchase but it comes with a price: you will do almost everything using JNI.
Definitely it's harder than just putting a jar SDK into libs folder and directly call Java functions but it's feasible.
You can develop on Windows, Linux or Mac. For each OS you're using in the development machine the procedures to prepare your environment (cocos2d-x + target SDKs) varies. It's not a problem because you usually will stick with one of them.
Now let me tell you that it's not that easy to debug JNI / Java code. Why? Because there are many steps you must take to enable this and debugging process is slow.
So that cocos2d-x team advices to develop all your game for Linux or Windows and after that everything is up and running you compile it to Android. This way you will have minor problems to solve (if any)
I prefer to develop for android from the beginning.
All in all, I'm really happy coding with cocos2d-x. Community is very passionate about cocos2d-x and they are very supportive.
In the process of learning I wrote two tutorials:
Developing with cocos2d-x for android on Linux, that teaches how to prepare your environment to develop for android using cocos2d-x
How to debug cocos2d-x and Java code using Eclipse that explain in details all needed steps to perform debugging sessions.
Regards.
I had the same problem 2 month ago. Cocos2d-Android is dead, so use cocos2d-x. Here some links and tutorials to start using it.
If you are comfortable with C/C++ , by all means go the Cocos2d-x route.
HOWEVER, if you are coming from an Android and Java background, with no experience in C++ , it can be a really painful experience getting everything in order.
In asmuch as the Cocos2D for Android Project has been slow recently, I wont particularly say its dead. I used the version hosted on github here ..
https://github.com/ZhouWeikuan/cocos2d
There are several tutorial on getting started.
Step by Step Guide on How to build your first Slider Puzzle game in Cocos2d for Android – Part 1 http://denvycom.com/blog/step-by-step-guide-on-how-to-build-your-first-slider-puzzle-game-in-cocos2d-for-android-part-1/
How To Make A Simple Android Game with Cocos2D http://dan.clarke.name/2011/04/how-to-make-a-simple-android-game-with-cocos2d/
For all others coming to this thread, I hope this is useful!
cocos2d-x (98% in C++ and some Android Java Code) is the only version of cocos2d useful for Android.
cocos2d Android (all Java) may be useful if you want to create some prototypes, but as an active open source development project it is long dead and not maintained.
If you want to write a Java game on Android, use AndEngine - it is active and well maintained.
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.