Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

Unity Creating Cross-Platform Code

This topic is 775 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello dear gamedev.net community : )

 

I wanted to learn more about creating cross-platform code, especially with C++.

At the moment, I avoid libraries which are not cross-platform. Also I use standard C++ types and therefore avoid platform specific ones.

 

Are there any tips on how I can directly tell whether a certain part of C++ is something I would like to use or not? Moreover, where could I look it up?

Is there a good and up-to-date book I could learn more about cross-platform C++ code or general concepts of cross-platform code?

 

How could I handle testing? How would I start to create a proper tool-chain?

 

Is it wise to use Visual Studio when my main target is cross-platform code? I thought about switching despite that I quite like Visual Studio.

 

I know that a lot of input changes once going for something like Android. Is there a good way to abstract my general code so I can rather easily invoke these new ways of inputs later? Let's say abstract the movement within game to a degree, where the engine can easily switch between keyboard, controller and touch (I know this is probably a comprehensive topic and needs to adjusted on a native way).

 

Last but not least: Mac seems to be hardest nut to crack for me. Are there any tips about setting up a proper tool-chain for this? Since I heard having a virtual box of it is not supported/illegal by now. I thought about buying  used Mac, are there any tips on what to look if I want one for development? However I would prefer alternatives, but those development clouds on the internet seem to be even more expensive over time.

 

That is all I can grasp with words in my head at the moment, if there is anything else I really need to keep in mind, then I would be glad if someone points it out for me : )

 

Thanks for taking your time of reading this post. Have a great day!

Share this post


Link to post
Share on other sites
Advertisement
You might want to take a look at build system generators like CMake or Premake. Dealing with file adds/removes/renames and compile option changes across multiple build systems is one annoying chore. I had to deal with that at work for a while and CMake really chopped off a lot of problems there.

If you want to keep using MSVC, keep doing it. Just make sure you do some test runs with gcc or clang regularly (build system generators like CMake should make that extremely trivial). MSVC compilers accept some code (especially when templates are involved) which are very much non-standard. Expect to spend quite a lot of time here at first, especially if you never worked on non-MSVC compilers. That becomes much less time-consuming once you get a hang for it.

Most of the platform dependency comes from window creation and context management. If you don't need any extra bells and whistles any of the usual suspects (SDL, SFML, GLFW, possible others) probably are all you need. With C++11 and C++14 Boost has become more of an option for me, but it still contains some useful abstractions (for example memory mapped files, although I have not tried them myself so far).

Share this post


Link to post
Share on other sites

With everyone elses input, I sincerely recommend not trying to shotgun everything into a single project. You're probably far better off starting off with just two pieces of the pie till the project is mostly done, then add on more. You'll find that doing this is probably more efficient, and will leave you mentally stable.

Share this post


Link to post
Share on other sites

The first thing about building your own cross-platform build chain from scratch is that you need to know about building a tool chain on all your systems.

 

If you're having trouble building a multi-platform toolchain that works on the mac, I immediately wonder how much development experience you have on the system in the first place. 

 

Different platforms have rather different implementation details.  We frequently have people at my current company who start talking about window manipulation cross application boundaries.  Works great on Windows, just manipulate the HWND. ... but then they start complaining that you cannot do that on OS X. Turns out Cocoa developers took pains to limit exposure of windowing contents and windowing manipulations, they're all kept inside the process's memory space as pointers, not OS handles.  Development teams need to abstract that away into a library, but it is one of many things that unless you happened to know it was an issue you wouldn't really think about it.

 

 

 

Assuming you or team mates are already comfortable, you need to have the people who know all the platforms work on abstracting away pieces that are platform specific. The best way to do that depends on your needs.

 

There are many different ways of doing it.  The sheer volume of cross-platform libraries that have already been written are evidence that there are many different ways to do it. Consider looking them over and identifying what they did. They've already looked at the problems and come up with their own solutions, your solutions will likely be different.

 

Whatever route you take, as mentioned above keep the platforms running all the time by people on the team. Either keep development active on all of them together, or put it on hold completely until one platform is done and then re-implement as needed as a separate port, then merge the two.  The alternative of intermittent or occasional development doesn't work well.  You can still have a lead platform where most of the development work takes place, but the secondary platforms need to be either continuously used and kept in sync, or not touched until you decide to port. Otherwise you get into nightmare support scenarios of constantly porting and re-porting segments of code.

Share this post


Link to post
Share on other sites

I'm currently in progress for doing some similar with my game engine (that targets Windows, Linux, Android and Sony Playstation) and except the PS one using all the same compiler over all platforms helps keeping a lot of compiler dependent stuff away. There are some magic tricks in the MSBuild environment and preprocessor quirks that are supported on MSBuild but not on GCC for example.

 

I'm using Visual Studio for developing the engine in a basic framework first including heavy API use and on top the real engine dont using APIs any more. For debugging the code and development I use the VS build environment in the standard profiles Debug/Release and for shipping I have an external build tool set up that calls LLVM compiler frontend for building.

 

The most anyoing problem I came accross was to keep dependencies up to date so I wrote my own build tool including a small smart C++ preprocessor for resolving all the dependencies in the code. Is still in development but will help keeping the buildchain small and clear.

 

There are common tools like make, cmake that were used for over 20 years but in the case of make have the problem to be build arround the unix shell so most features are worthless on windows.

Share this post


Link to post
Share on other sites

There are common tools like make, cmake that were used for over 20 years but in the case of make have the problem to be build arround the unix shell so most features are worthless on windows.


CMake does not need any special command line features. It can just generate a classic MSVC project structure when you work with it anyway and even the make files it generates are extremely tame. That said, having a *nix shell on Windows nowadays is hardly a big deal. Git for Windows comes with one out of the box. For the more arcane corners these is msys (comes with a lot of gcc distributions out of the box, can also be added with little work by hand) or Cygwin.

Share this post


Link to post
Share on other sites
Thought I'd add that the upcoming Windows 10 Anniversary update will be adding some "native" Linux support. While you might not be able to test the program itself (not sure how much will or won't work), you will be able to run GCC from bash directly from Windows.

Share this post


Link to post
Share on other sites

I wanted to learn more about creating cross-platform code, especially with C++.

 

What platforms do you have in mind? What is your project? If you want to have just one dev box and write once run everywhere from 4k power-rig PC to xbox one, to ipad, to android smart watch, then no. It won't do.

 

For any platform you want to target you need test environment using that specific platform and test there often. It gets more and more expensive (mostly in time) with every additional platform you want to support because every new feature you add has to be tested on every platform and regression tests are required on all platforms. Every bug fixed requires retesting on every single platform to ensure it is fixed everywhere and didn't break anything else.

 

Before you reject any lib or tool that deviates from "cross-platform" mantra ask yourself - what justifies any additional platform for your project, then support only those that you found a good reason to. 

Share this post


Link to post
Share on other sites

Figured I would chime in on a couple points here, some of this may rehash the above points but given you requested a how to I'll walk you through what I generally do.  The first thing to mention is that you started at the correct point, cross platform starts and ends with the build setup then the tools you use.  I will obviously be suggesting CMake given that my experience with Premake was great for limited areas but the bugs and lack of support generally made it unusable in the long run, and there are some new reasons for this I'll get into shortly.  While it is an old article, you may take a look at: http://www.gamedev.net/page/resources/_/technical/general-programming/cross-platform-test-driven-development-environment-using-cmake-part-2-r2994 which was where my build system started.  Today I support Windows, OsX, iOs, Android, Linux, XBOne, Ps4 and a bunch of different AR/VR system variations, it started from the presented build system in that article series.

 

Once you have a build solution working, editors and more importantly debuggers, are your next step to consider.  Being comfortable on multiple platforms takes a while and as such I am always on the lookout for the best tools available.  In the process of looking at recent updates to the Android environment I ran across a very useful tool which allows me to use a single IDE for all platforms other than Windows.  (I could use it on Windows but I prefer VC on that platform.)  Clion, the basis of Android Studio 2+, is a very interesting IDE for other platforms.  First, unlike XCode it doesn't constantly attempt to do things in unusual (and I'd go as far as saying massively annoying) manners, it is more closely aligned with VC and other IDE's in most behavior.  But, more importantly if you decide to use CMake, it doesn't use a typical solution file, it directly works against CMake itself as it's solution file.  So, without inbetween steps, when I go to Linux/OsX, I just open it up and it is ready to go.  This is not the only solution but it is most definitely worth looking into given how easy it is to hop to other platforms and fix the build quickly with low hassle.

 

With editors out of the way, as others have mentioned, you need an effective method of knowing when you have broken things.  The first thing most folks are likely to suggest will be continuous integration using Jenkins.  I tend to alter that just a bit and suggest TeamCity (https://www.jetbrains.com/teamcity/) for a couple of reasons.  The primary reason is that setting up Jenkins is quite the chore and after it blew up one of my Macs and made me reinstall from scratch I gave up on it.  I had TeamCity up and running in just under 2 hours from initial investigation to CI running on Windows, Os X and Linux.  And, as it happens, the free version has enough allowed agents and configurations to support those platforms as needed so I have not yet purchased an upgrade.  The second reason I ended up with TeamCity is the built in support in Clion, it is very sweet in terms that Clion is a fully integrated solution to managing TC such that it will pick up logs, allow you to start investigations, trigger builds etc all without leaving the IDE.  I'm sure that is all possible with Jenkins, but generally speaking it was a lot of work where this just existed as a benefit after setup and initialization.

 

Code build/link is of course just one step to having confidence in what you are doing.  Unit testing, integration testing, etc is your next step.  As with the linked article, I generally still use Google Test for C++ code as it is low boilerplate and high utility.  Additionally Jenkins and TC both have direct support such that after my builds complete my unit tests run and I get feedback on the over 500 tests across all platforms.

 

I'd say at this point you are generally ready to do real cross platform work.  While all these bits and pieces may seem like overkill, I would argue that without them you spend more time jumping around doing repetitive nonsense than you do writing code.  All this setup takes a couple days before it is working smoothly even for a simple hello world test.  But once done you will thank yourself for having set it up because you can focus on the code, where you should be, instead of fighting with different platforms constantly and switching from IDE to IDE.

 

Hope this helps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!