I have access to both OSX and Windows. I have built my demo in Visual Studio 2010 using C++ and DirectX 10. I have read that C++ can be run on the iPhone using XCode, but that any input has to handled in objective-c.
At present there is no input so that's not an issue right now.
What are the steps I would have to take to get it running on the iPhone?
also - was not quite sure how to tag this question. by all means edit them if they're wrong.
Yes, you can run C++ code fine on an iPhone. I've released a couple games which have a large C++ component. Of course, the graphics will need to be redone.
Likely you'll need a little bit of Objective-C++ code to communicate between the UI layer and the underlying engine.
There's no DirectX on iOS (being that it's made by Microsoft) so any code that calls DirectX is going to need to be ported over to something that can be run on iOS, like OpenGL.
Other than that you'll be treating your code like a library. With a layer of objective-c that sets up the app, and calls the necessary parts of your C++ code.
Related
How can graphics functions be used in Visual Studio 2017 (C++) without using a BGI library? What header file is used? I want to use these functions to do things like drawing a circle.
The header file <windows.h> allows you to use Windows API for many functionalities including but not limited to functions that you will use to do graphics by yourself such as SetPixel and GetPixel and many others you can see the code in this repository which contains C++ implementations for various circle drawing algorthims.
You have quite a few options:
Windows API - Quite difficult to use but runs incredibly fast. This is perhaps the most difficult option due to how complex and no-hand-holding it is.
MFC - Microsoft's tools for C++ graphics. Not too easy to use but certainly easier than WinAPI. A lot of people don't like using this as it's kind of old and there are better stuff out there.
OpenGL/Vulkan/DirextX - These three are very similar technologies. They are based around using your graphics card for drawing, using small programs called 'shaders' which can be edited and compiled on the fly. Most games use one of these, and they run pretty fast. DirectX is Windows only, and Vulkan is pretty low-level. I would recommend OpenGL out of these three.
External library - There are many libraries you can use such as Qt, wxWidgets or SFML. All of these have their own pros and cons, but they all are third party libraries which bridge the gap between commands like 'draw a circle' and the Windows calls that go on under the surface.
Chromium Embedded Framework - CEF allows you to code the guts of your program in C++, then create the GUI using HTML5 and Javascript. Essentially it's a web browser connected to a C++ backend. Looks really nice but some criticise it for its resource usage, which is much larger than the alternatives.
I would recommend staying away from WinAPI and MFC and either use a third-party library (for simple GUIs) or OpenGL (for complex rendering i.e. games). If you're confident in web programming then you can go for CEF.
I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
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 develop native c++ windows application using windows API.
but i find it being difficult because i am unable to render the window and drag and drop components, change the location etc..
How can i view, drag and drop components like i can do in C# ?
May be there is no way to do. if so, what is the fastest procedure to design the application ?
If you like so much the drag and drop of components (and of course for good reason) why would you need to develop it using C++? You can use PInvoke if you need to call some C++ functions from C# code that are not in the .net framework.
But if you really insist, maybe you could try QT.
Using a library framework such as Qt is really the way you want to go. It makes things very simple and still allows you to write code in std c++ to keep most things very fast.
If you EVER have intentions of porting the code to a different platform than windows (whether it be Mac, Linux or even Android ... yes its possible), qt is definately the way you're going to want to go.
I can get an app up and running... smoothly in a few minutes using Qt but much longer and with more confusion using MFC.
Dragging and dropping 'widgets' to form a gui is very easy and possible with Qt's built-in QtDesigner!!! Check it out!!!
http://qt.nokia.com/downloads
Assuming you are using Visual Studio, if your app can be implemented as a dialog box, then you can use the dialog editor to lay things out. Otherwise, you just have to write code to create the windows and place controls. Look at the MFC examples included with Visual Studio.
Jeff Prosise's PROGRAMMING WINDOWS WITH MFC was one of the better books for learning how to do this, but I think it is out of print, and so could be hard to find.
Charles Petzold's PROGRAMMING WINDOWS is the bible for the Win32 API. Again, may be hard to find these days.
If MFC isn't your cup of tea, you could also look at QT, GTK+, or wxWidgets. There are GUI builders for each of those, but they are all pretty primitive compared to what you can do with C#.
As far as I know there is no ide out there that will let you "drag and drop create" standard win api windows like you would with C#.
Personally for that kind of application I always recommend Borland C++ Builder (Which is now Codegear Rad studio)
Although it is not standard API, it allows you to drag an drop and static linking is very easy, so you dont have to worry about redistributables