Hello! I re-writing my game engine from scratch and was trying to decide whether I should support DirectX & OpenGL or just DirectX? I understand that OpenGL is cross-platform while DirectX is restricted to Windows & the Xbox. I also have a couple more questions:
More accurately, OpenGL supports Linux, OSX, Windows, iOS, and Android. DirectX supports Windows and Windows Phone. Every console - XBox included - uses a custom API. The XBox one certainly resembles DirectX pretty closely, but it's not identical. The PS3 does not support OpenGL, though it does support an infrequently-used non-standard GLES1-derived API with Cg shaders that led many to think that the PS3 uses GL (most games used the entirely proprietary libgcm, though).
The point being, if you really want to be ported to all main platforms, you _must_ support multiple graphics API. OpenGL doesn't get you as far as some might think.
Even if you use OpenGL, there's several variants you need to support (OpenGL Core on OSX, OpenGL Compatibility for most other desktop OSes, GL|ES for mobiles).
I am developing on Windows using Visual Studio 2013 Ultimate. If I were to implement OpenGL, how would I build for different platforms? Example: If I wanted to build on maybe, Linux or Mac. Would I have to build my project on that operating system?
You can do what's called a "cross compilation" (a compiler that runs on one OS/architecture but makes binaries for a different one). There are cross compilers available for Windows, even some commercial ones that integrate with Visual Studio. This is how mobile development is done, after all, since you don't actually compile on a phone.
Usually though you'd just port your build system and then build on an actual Linux/OSX machine. You can use something like CMake or SCons to handle builds on both Windows and other platforms. You'd continue using Visual C++'s cl.exe to compile on Windows and then use GCC or Clang when compiling on OSX or Linux.
If I do develop for both API's, how should I setup my project? Should I create two separate projects? Or keep them both separated in one project using enums, and interfaces?
Whichever you find easier. It doesn't matter much at all.
I personally prefer building a separate static lib for each underlying API and then only building/linking the one I am currently using. The public interface is a header, with the implementation files being separate for DX, GL, or so on.
You can take that a bit further and build them as DLLs (or whatever the platform's shared object format is) and allow runtime switchable system, though really Windows is the only platform that gives you multiple realistic choices but there's no good reason to use anything but DX on Windows if you support it. I stick with static polymorphism here and don't bother with virtual interfaces; they buy you nothing.
Also if I were to develop for both, and I do have to compile my code on other platforms (linux or mac), will I be able to skip my DirectX code (assuming it would cause errors because DX is not available) and just compile GL code?
Just don't compile the .cpp files that have the DX code and wrap any DX-using code in #ifdef's. Pretty simple to conditionally compile code or whole modules.
Is it even worth adding support for both?
Depends on your goals. If you are only planning to support Windows, there is absolutely no good reason to prefer OpenGL over DirectX. If you want to support the other desktop OSes they all only support OpenGL - which Windows also supports - so there's a strong argument to be made to only spend time implementing OpenGL support. If you want to support most mobiles and desktop, you're still going to need to support multiple renderers (even if GL and GL|ES are very similar, the kinds of things you can do on the desktop don't perform well on mobile) so you still need to deal with multiple APIs and conditional code. If you want Windows Phone, you must have DX.
Or perhaps, shall I finish my engine with DirectX first (creating empty methods for GL in the process) and just start working on GL support (fill in the empty methods) after DirectX is fully implemented?
This is the path I recommend, assuming you mean Direct3D 11. DX11 is both easier to use than modern OpenGL (though if you stick to old deprecated fixed-function stuff the GL API is definitely simpler) and it tends to force you to learn how to think the "right way" (which applies equally well to GL) while OpenGL can easily lead you to believe that very bad things are correct (partly because GL3+ was designed around some incorrect guesses about where hardware was going and GL is still struggling under some of those poor choices and it's not obvious in GL when you're doing something you shouldn't).
There is _zero_ reason to ever use D3D10 (the only OS that supported it exclusively is Vista which also supports 111 with a service pack) and I wouldn't recommend D3D9 for any new code; if you really need to support XP in the 2-5 years it'll take at minimum for your game to come out, OpenGL will cover you and support other platforms, too.
As one last reminder, note that your graphics code is _hardly_ the only bit of platform-specific code you'll have to write. The native, low-level APIs for threading, file I/O, memory management, window management, networking, input, audio, and so on all differ between every platform. If you think you'll just be writing OpenGL code on Windows and then compiling it for Linux or OSX you might be in for a surprise. There are libraries to consider using that paper over the problem. SDL for instance covers input, windows, simple file I/O, simple audio, and so on, though only on desktops and mobiles (not any consoles that I know of). FMOD or Wwyse cover more advanced audio needs on every major gaming platform. There are networking libraries that support a wide variety of platforms. You're still likely going to have a good deal of platform-specific code outside of graphics, however, and you're going to need to make a lot of good choices when writing you're Windows-only good to have any hope of compiling on Linux or OS without a very long time spent porting.
