Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






Targeting multiple platforms

Posted by a_insomniac, in Rants 25 August 2011 · 306 views

Well sort of...I've really been thinking about not limiting myself to just Windows and keeping my options open for developing towards multiple platforms such a Linux and Mac OS. Tonight I spent sometime actually trying to setup a development environment using Cygwin & TextPad Pro. It is just amazing how much your realize what Visual Studios does for when you are not using it.

What I really want to do is just compile and run a simple DirectX app and a OpenGL app using this pipeline to qualify it (need to figure out how to point to the lib & include directories for 3rd party SDK's). I figure building and compiling an OpenGL sample app should be pretty straight forward since the gcc build is supposed to come with the OpenGl libs.

Anyway, I'm open to any tips, caveats or even a better approach to develop outside of Visual Studio with the main goal of targeting multiple systems. Thanks in advance!

Thinking ahead, it looks like I'll need to at least become some what proficient with GDB as well...Posted Image

I look at this way, my programming skills should increase a bit considering there will be no intellisense Posted Image and I will "seriously" have to pay attention to the compiler messages.




Look into eclipse, that is a good IDE which is in some areas quite close to VS. Debugging is better on VS, though...
I'm using Code::blocks and I think it works great. It is multi-platform, has a nice integrated GDB and is being actively developed. Swap between header and source files (one key), code completion etc. I would recommend downloading the mingW setup.

http://www.codeblocks.org/

@Tobing - I totally forgot about Eclipse. I've used it alot but only for Java. Althought I remember setting up eclipse with MinGW to try and compile OBJ-C on windows and saw the C++ port. Thanks.


@O-san - Code::blocks I have always heard of it but never looked into, checking out the features and avaialble plugins the suite looks complete, thanks for the tip.
Thanks for the post! Keep us updated with what you find out. I'm very interested in knowing some tips and caveats you find while developing for multiple platforms simultaneously. In my future projects I would like to target Win/Mac/Linux and code as generally as possible to make any specific porting I have to do minimal.

I second O-san's recommendation of Code::blocks. I've been using it for a while on my work computer and I enjoy how robust and powerful it is.

Keep on keeping on!
@Sir Funk - Will do. Thanks for the motivation.
Was this for a income producing game or a free release? Was this project for fun or not? I'd seriously consider what the goal is of the said project, and how you see it ending when you're done with it. For a income producing game, I'd really target mobile or windows if I wasn't proficient in programming. Since I use major AAA game engines myself, 2 of which I have the hard code C++ to, I generically do not need to do much backdoor coding. Instead I look to their scripting languages. When it comes down to it all, you will need more focus on artwork, sound, and combat / game mechanics (including story and how your game / ideas are perceived by the players) than coding. Coding is next important. You will need to be able to have a vision of the game before you begin, unless again its for practice. For me, what defines a indie game also is advertising and marketing campaigns. How well is public relations working for you? These things added into a indie game will boost sales and publicity. Any additional income should be going into pax, e3, ect. You want as much publicity as you can get. But this doesn't apply if you want to do it for fun. Personally, I have nothing against doing games for fun, as one of my future Steam releases will be Free, supported by buy able DLC. Finally, to top off the cake you should not worry about your coding as much. Decide 1 thing at a time, do that, then see if you want to expand or not into another area. Trying to preset for ALL = Disaster. Gl, and hope the game turns out decent.
@RedPin -- huh? Posted Image
I recommend QtCreator as an IDE. Even if you don't use the amazing Qt APIs, QtCreator is still a great IDE.
Choice of IDE ought to be orthogonal to the desire to support multiple platforms -- Furthermore, people are most productive when they are using the tools they are most comfortable with, whether that's Visual Studio on Windows, XCode on Mac OSX, KDE on Linux, Vim on... well, on anything capable of running code... And everyone has a different preference.

What you really are after is a cross-platform build system -- I use CMake, which is free, open source and available on all platforms. Essentially what it does is has its own language for defining different builds and the dependencies amongst them. You modify these files when you add a new file, change the dependency structure, or change build settings such as optimizations. CMake parses these files and generates the native build files for just about any platform you can think of -- It'll make solution/project files for Visual Studio or Xcode, GNU Make files, etc. In the case of project files, you can then load these into the IDE of your choice and see the entire project just as you would for a project created exclusively in those IDEs.

The biggest difficulty is getting everyone to *not* try to effect build changes by modifying the platform-dependent build files -- you've got to always make those changes to the cmake files themselves, otherwise they get over-written the next time cmake is run. This isn't difficult, its just something you have to change your way of thinking about to break the habit. A good way to do this is the have your source control configuration ignore the platform-defendant build files, and they can never be checked into the source tree (of course, its nice to be able to fiddle with those platform dependent files locally when you're trying to figure out what changes are desirable to make to the cmake files).

November 2014 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
23 242526272829
30      

Categories

Latest Visitors

PARTNERS