Related
How come these "Bible" type books for programming which are supposed to be comprehensive don't mention anything about programming sound or graphics?
My C programming language second edition book came in the mail today by Brian Kerninghan and Dennis Ritchie, and I thought the book was supposed to be comprehensive, but what I first noticed about it is that it is very thin. And it doesn't really seem to talk about much beyond just the basic stuff we have already learned.
So then I thought I would look in my C++ programming book by Bjarne Stroustrop, which is a lot thicker, to see what IT says about graphics and sound, and at least going by the table of contents, in 1200 plus pages, there doesn't seem to be anything on graphics or sound either.
Are graphics and sound some kind of extra subject matter that requires specialty books or something on some specific libraries or something?
Because surely, there must be some foundational stuff on sound and graphics in the core language itself, isn'tt there?
If not, where does one go to start learning about programming graphics and sound?
Sound and graphics are not part of the C or C++ programming languages. The C and C++ standards define only core languages that must be extended to provide other services.
C and C++ are, by and large, abstract programming languages. They specify a few features for input and output, which are subject to interpretation and implementation choices, but they do not specify interactions with devices, including sound systems or graphics displays. They specify features for computing with data and minimal provisions for interactions and storage.
The C and C++ standards define core languages. These core languages are extended in various ways, including:
Providing external libraries that any kind of services, including sound and graphics features.
Using volatile objects to interact with machinery, including devices connected to a processor.
Building more features into the language by supporting additional keywords or language constructs in a compiler.
C++ (and C) does not have graphics libraries as part of its Standard Library
Much to the chagrin of many novice programmers.
The reasons why C++ presently lacks a Graphics Library are varied. There is a proposal for a 2d graphics library to be added to the C++ standard, but it failed multiple times to get added, and as of this year is more-or-less defunct.
There's some writeups on Reddit that try to go into the details of what went wrong, which I'll link below, but I'll summarize the basic issues:
First, the proposal was for functionality that, intrinsically, not all Architectures + Operating Systems could support. Any viable Graphics API needs to have some basic components that can be backed by the Operating System, things like a Surface (something to draw on), a Display, and commands for drawing arbitrary images on that surface and presenting them to the display. Lots of Operating Systems have that: Windows, Linux, MacOS, for example. But many more don't, and trying to build an API where the entire API could be rendered invalid by an Operating System that fails to provide the necessary functionality was troublesome. The philosophy of the Standard Library is that it provides functionality to all compilers that correctly implement it, and a feature that couldn't make that guarantee was inherently unsuitable.
The second problem is that there was virtually no agreement on how the library should be interfaced with. A basic 2D Graphics API like that provided by Java, Python, or (some variants of) BASIC could be implemented in a wide variety of ways, each with quite substantial upsides and downsides, and the authors of the proposal didn't seem to have a coherent vision of how it should be implemented.
In particular, modern graphics is largely a matter of heterogeneous computing, between the ways that DirectX11/OpenGL 4.x try to implement their APIs (more substantially in the former case than the latter...), or the ways that DirectX12/Vulkan represent attempts to get "as close to the metal as possible", and the C++ Standard Library lacks a lot of valuable tools for handling these kinds of functionality.
Tools like std::future might have been sufficient, but in my experience with graphical programming, I'm skeptical it would have been enough, and even if it was, you then have the question of whether you want a Graphics library in your Standard Library that's implemented in such obtuse terms. That's held back the Networking proposal for years, and even that is only getting added in C++23 because there's other library features that are going to support it, like the Executors proposal, which the Networking library is pretty much dependent on.
There's a number of other ways things went wrong, but I'll leave it at those two big ones, since not only do they explain why this specific proposal didn't go anywhere, it also explains why a lot of other ambitious proposals to do the same didn't go anywhere either—including many proposals to add Audio libraries to C++.
So what can you do instead?
For Graphics, you need two things (at minimum):
An API for getting Windows/Surfaces/etc. to display on
An API for generating the images that are displayed
The former can be handled by your Operating System's native windowing api, but you can also use something like QT, GLFW, SDL, or any other api you prefer that's designed for cross-platform compatibility.
The latter can be handled by a good graphics API like OpenGL, or (if you're developing for a Windows environment) DirectX (11-). You could also use Vulkan or DirectX12 if you want to get familiar with the cutting-edge technology, although I'll warn you now that both are far more complex than their predecessors because they don't abstract anything other than the barest of basics, so be aware that it's a much steeper learning curve for those.
For Audio handling, I don't have any recommendations I can personally vouch for (my experience is more limited on that front) but there's quite a few APIs that are specifically designed for that, so just do a little research into what's available.
References:
https://www.reddit.com/r/cpp/comments/89q6wr/sg13_2d_graphics_why_it_failed/
https://www.reddit.com/r/cpp/comments/89we31/2d_graphics_a_more_modest_proposal/
Putting it simply (comment from #NathanOliver): C and C++ have no concept of sounds or graphics.
As you've guessed, graphics and sound are extra subject matter that require other types of books.
Most of these things are abstracted away from the hardware, and are usually OS-dependent.
Take, for example, /dev/dsp on Linux. It's a part of OSS, an abstraction that allows you to play audio. You can interact with it in standard C or C++, it just won't work on all platforms.
For some historical perspective, at least on C:
Once upon a time, the core C language did not even cover I/O to files. The core C language covered the syntax of the language, and that was it. If you wanted to do I/O to files, well, you could include <stdio.h> and call those functions... but they were just external functions in a library, you could use them or not, it wasn't like they were part of the language or anything. (You will probably find language in that copy of K&R you just got saying more or less what I've just said here.)
Now, when the first ANSI C Standard came out in 1989 or whenever it was, it did cover several of the then-standard libraries, so the functions in <stdio.h> (and the ones in <string.h>, and <math.h>, and several others) became a formal part of the language. But that was a pretty significant change.
But there had never been a <stdgraphics.h>, so there wasn't one to standardize. (And of course there still isn't.) And pretty much nobody was doing computer audio in the 1970's, so that had even less of a chance.
(Unix in those early days did have a nice, simple 2D graphics library, <plot.h>, and there might even be a few dinosaurs besides me still using it, but I don't think anyone ever considered trying to push it as a broader standard. Today's GNU libplot is a descendant of it.)
Basically, C never aspired to be a "platform" language like, say, Python. And it's now so well entrenched as a low-level, platform-independent, "systems" language that I'd say there's very little chance that any of these "higher level" functionalities will ever be added to it.
ISO C++ does have a sound and graphics (and input) Study Group:
SG13, HMI & I/O (Human/Machine Interface): Selected low-level output (e.g., graphics, audio) and input (e.g., keyboard, pointing) I/O primitives.
which is currently active (after being inactive).
Audio is probably even more of a mine-field for standardisation than graphics (where, I note, nobody yet has mentioned motion video - see Codecs below). There are at least these levels of abstraction it could operate at (listed from low to high), depending on the application in question:
Raw PCM samples.
Datastreams suitable for audio Codecs (e.g. MPEG layer III, AAC).
MIDI - or other ways of instructing a sequencer on a note-by-note basis
Programatic audio e.g SuperCollider
PCM Audio
Taking the first, this is possibly the most generic and portable. At the very minimum, it requires audio hardware (or, more commonly, a software abstraction) of a double buffer or circular buffer into which output samples are written in real-time to be output somewhere. Lots of parameters here such as sample-rate, channel-count, sample bit-depth, latency, endianness, signed-ness, and whether a push or pull (event-driven) model is used to render buffers of data.
Low-latency audio for professional applications requires real-time threads (and thus, an operating system that provides them), and careful management of system resources.
Successful APIs are CoreAudio (MacOS, iOS only), ASIO, DirectX and whole bunch of Windows APIs (professional software invariable uses ASIO), Jack, ALSA
Codecs
Lots of them are proprietary and patent encumbered. Various web standards have significant difficulties specifying them - and they are far less restrictive than the ISO rules. Not all implementations implement all of them.
MIDI
This is at least fairly standard (although the industry spend nearly 25+ years in replacing it). Twenty years ago, you'd have been driving specialist synthesis hardware with this (pretty much every pre-smartphone era phone and games console had one, mostly made by Yamaha), but these days the sequencer generally drives software synthesisers, and any decent one is proprietary, commercial software. No two implementations have ever sounded the same either, which makes them largely useless for portability.
Programmatic Audio
At this point, you'd be defining an entirely separate programming language.
Conclusions
Good luck trying to standardise any of these - the music software industry has failed repeatedly for decades in its attempts, with much laxer standards bodies.
There's a certain irony that almost all serious audio software is implemented in C++ - often because it lacks any kind of abstractions for audio of its own.
Some background on the variations of graphics support.
Historically, the only supported graphics by computers was ASCII characters. *(Search the internet for "ASCII Art").
Graphics was developed, but had two major flavors: bitmapped and vectored. Some systems had a list of vectors (the math type), and drew those. Other graphic devices used pixels to display images. Even today, some graphic controllers allow you to define your own "bitmap" and have reserved cells (but they don't support line drawing).
The graphics started out as monochrome. One foreground color and one background color, no shades between. This was to simplify complexity and cost. Other features that soon came into being: shades of monochrome and a brightness attribute. The graphics controllers were originally one bit per pixel (either on or off, the "off" being the background color). Graphics controllers then expanded to allow more bits per pixel, monochrome still being the most popular. You could have shades of gray and change the intensity. Some controllers also had bits for "blinking" and other attributes.
With the cost of H/W becoming less and less, graphics controllers started taking on more advanced features: color and bit-blit. Now you could have 4 bits of Red, 4-bits of Green, 4-bits of Blue. This allowed for multiple color and expanding the shading when combining the intensity bit. The graphics controllers started having their own memory and the capability of transferring bitmap data from the CPU's memory to the graphics memory area, often called bit-blit. The controllers advanced to allowing Boolean operations with the blitting (AND, OR, XOR, etc.).
The modern advanced graphics controllers are considered separate computers from the CPU's. Not only do they have their own memory, but they have Cores that can be used by the CPU to perform processing in parallel. Many of these controllers have common algorithms implemented in hardware (such as screen rotation, collision detection). They have multiple buffers so that the CPU can draw into one buffer while the GPU displays another buffer (helps with graphic speed to support animations).
The C and C++ are standards. That is, you should be able to compile a standard C language program to any platform that supports the standard. The issue with graphics, is that there is no standard. Some graphics controllers only support text and bitmaps, and not line drawing. Desktop PCs have various degrees of graphics capability depend on the graphics board plugged into the system. So, there is not much that can be standardized. Also, graphics technology is constantly changing (improving) at a faster rate than the language standards are developed.
Lastly, let's talk about low level programming. To get the most performance from graphics, the code needs to access the hardware directly; sometimes also exploiting features of the processor. Any graphics API placed into the language would have to be abstract to support graphics concepts; and probably not efficient because of the subtraction. The low level programming of the graphics hardware would still exist for performance. The compiler writers are not graphics exports and would either use libraries or compiler for the general case. So many combinations to support (as illustrated in the history section above).
Remember that C and C++ languages are "you only get what you pay for". If I don't use any graphics on my embedded system, I should be able to have the compiler code without graphic support. These languages have a wider audience than other languages that support graphics, like Java.
I've had much experience writing in Java, python, C#, and C, mostly for hobby. In all of the applications I've coded that involve displays (simulations, graphers, etc.), I've always just used the stock "Canvas" class of whatever framework I'm using (Swing Canvas, .NET Canvas, pygame once for python).
The downside of this is that all of these have slightly different paradigms in drawing.
I'm starting a project in C++ and was wondering what the best solution is for cross-platform drawing. OpenGL is obviously very low level, but some sort of library on top of OpenGL would be good. I've heard of/read about things like Cairo, SDL, etc., but don't yet know what to go with. I'm already using wxWidgets for interface, but would prefer to use something more standard instead of just a wxWidgets canvas. Obviously, the ability to draw lines and shapes is important, not just display pictures or whatnot.
Thanks for any direction!
I would consider using Qt, and notably its Graphics View framework. (Qt works on Linux, Windows, MacOSX).
SDL is SimpleMedia Direct Layer, which is basically a common interface to interface with the framebuffer and audio devices. If you wanted to create windows and such, it doesn't have general purpose constructs that work cross-platform.
Cairo is for drawing graphics, but still operates at a level that's lower than what WxWidgets provides.
C++ doesn't provide anything standard, so either you go with some platform specific, or you use a cross platform library like Qt (already mentioned by Basile) or stick with wxWidgets. Both are popular and widely used, though Qt is probably much more well-known and used (though that is just opinion). I've used Qt for work and it is very much cross platform and pretty easy to use (but very extensive, so prepare to read a lot of documentation). Luckily it also has a lot of documentation and many examples available.
Plus, both wxWidgets and Qt have bindings in many languages, so you could take the knowledge with either and use it with many other languages.
Open Frameworks is very easy to use and comes with a lot of examples...
it's platform independent and somehow reminds me of processing
So I've fooled around with WPF a bit recently, and I must say that I really like the idea. I love the framework as a whole, from the GUI to the plumbing.
However, as much as I love managed land, I love my native code just as much. So I'm wondering what sort of libraries exists for C++ which capture the essence of various parts of WPF. I'm not looking for interop solution, nor do I want Managed C++ or C++/CLI solutions, but pure C++ solutions.
Now, I'm not expecting to find a "copy" of WPF for C++ - I wouldn't expect that to exist, nor would I need it to. Instead, I would expect that different libraries might capture a subset of the desired concepts. My particular interests are
Hardware accelerated graphics for widget based GUI's (via DirectX or OpenGL, preferably the latter)
Declarative language for GUI design (preferably an XML dialect)
Data binding
Resolution independence (less important)
To say a little about my reasoning, I would like to implement such a library myself, which captures a specific model that I have begun working out. I am in the process of finding some more inspiration and helpful resources before locking down my design. The library is intended to be cross-platform, so references to cross-platform ideas would be great, but not strictly necessary as I am usually capable of translating things into cross-platform solutions.
Lastly, although I am writing a C++ library, and C++ ideas would be great, I am open to ideas from any native language.
Thanks in advance for any help.
There isn't really anything like this. Not cross-platform at any rate. Direct2D works reasonably well, but is obviously Windows-only. And NVIDIA recently dropped this "path" extension of OpenGL that is similar in basic functionality, but it is NVIDIA-only (and not available on Mac OSX). Cairo has an OpenGL backend, but I have no idea how good it is. It can't be that good if Mozilla dumped Cairo in favor of D2D on Windows.
Many GUI toolkits have some form of language for making a GUI. Qt has one that is pre-compiled into C++.
Not that I know of. Data binding requires some form of reflection (WPF-style data binding does), and C++ has no native support for reflection. So you would need to implement reflection of some sort before you can even begin to make WPF-style data binding work.
That comes with #1. More or less, as any GPU-based renderer will be able to operate at arbitrary resolutions.
I love C++, but honestly, this sort of thing is best implemented for a higher level language. The lack of language-based reflection support will make implementing data binding a huge pain. Whereas, you could just implement the low-level "render stuff to area" and basic window/event management in C++, then expose it to a scripting language where data binding and such work. That way, you have native code speed where you need it, but the versatility and reflection of a scripting language for dealing with the GUI and its associated data.
I'm several years late, but for the benefit of anybody else reading this question: you're looking for Qt Quick / QML:
http://qt-project.org/doc/qt-4.8/qml-intro.html
http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
I need some specific and some general advice. I'm a fairly proficient Java programmer and a very experienced web programmer, but I would like to get into software development and I've been tackling C++. I have a great idea for a game I'd like to do, and I realize it will be a huge undertaking--but I'm looking at it more for an opportunity to learn C++, wrapping, really whatever I run into in the dev process...
But I can't get my foot in the door conceptually! I can handle the C++ aspect fine, it's just setting up the graphics, the RIGHT way, that's confusing me. I've run through a bunch of tutorials for OpenGL with C++ that all say the different things, none of which I can really get to work...
Some say to use GLUT and GLEW. Some say GLUT is dead and that FreeGLUT is the thing now. Some ignore those entirely and use a bunch of files like "glaux.h" that I can't seem to find--and other tutorials devoted to AVOIDING "glaux.h"... Most tutorials I've found come with the caveat in the comments that their version of OpenGL is dated and I should be using newer libraries-- and still others with 3rd party libraries like Ogre and Aurora.
I've been looking through a bunch of books and tutorials that ALL have an almost completely different setup for using OpenGL with C++. I realized there is probably not one right way of doing it, per se, but I'm looking for the way that is the most current, most popular, and will maximize the usefulness of the project as far as my learning... Any links to tutorials or advice in general is much appreciated.
BTW, I'm using Visual Studio Express 2010 (good idea?). My game won't be too graphically intense (isometric 2d) but will require a TON of logic and a TON of data, which is why I want to speed things up by using C++. Any other insights on better ways of doing it than using c++ for login AND graphics (from an industry perspective) are also very valuable to me! Thanks in advance!
Assuming you're learning OpenGL as a learning experience, I would recommend you this:
Use GLEW, no argument. Just do it, everyone does
Code only to the core profile. By default, OpenGL accepts old command (eg fixed function pipeline) that will later disappear, and you don't want to waste your time on that. Specifically: learn about VBO's, texture's, and, most of all, learn about shaders.
Forget about glaux and glut. Freeglut is a good and very standard option. A less obvious choice would be qt, but it's QGLWidget allows you to easily make gl calls, and not worry about context creation and all that. And it's dead easy to add gui options, which is always very nice to have when programming graphics.
To actually learn OpenGL, I would recommend http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html. Nehe has that problem where more than half of the stuff is useless to learn, and there's a lot of fluff (window creation et al) around it.
But, I wouldn't really recommend OpenGL as a way to learn real-time graphics programming. Your alternatives are not limited to DirectX. I learned a ton of graphics coding from working with Ogre3D. You still have all the concepts at your disposal that you need to know (working low level with Vertex and Index buffers, Textures, shaders), and implements tons of stuff to make your life easier. You might not learn the ins and outs of a specific API, but you will learn all you need to know conceptually. When I became a graphics programmer, I hadn't written a line of DirectX code, but I got to grips with our engine really swiftly. I learned the actually calls very easy after that. Know the hardware, and the concepts. The actual implementation changes over time anyway.
Oh, and just in case I haven't repeated it enough. LEARN SHADERS
The best tutorial around is (arguably, as anything "best") Nehe opengl tutorial. At least, this tutorial has been suggested for many years.
Also since you come from a Java background you might prefer C# bindings for opengl from frameworks such as Tao, but the actual setup might be harder than say, downloading samples and running them.
It's easy to see where the variety of choices available for OpenGL with C++ would be a bit bewildering. For the most part, Java gives two a pretty clear-cut choice between two possibilities (do you want a scene graph or not?)
The situation with C++ is certainly more complex.
Glut: This is basically an OpenGL-oriented application framework. It was apparently written primarily to allow examples to be short, but still work. The original implementation has some pretty well-known bugs, and hasn't been updated in over a decade. I would only use it in roughly the originally-intended context: short samples/examples/demos.
glaux: The story here is sort of similar to GLUT. It has some memory leaks that have been known but unfixed for over a decade now. It was never portable in any case. I'd avoid this one completely.
GLEW/GLEE: These allow relatively easy use of the functions added in newer versions of OpenGL from OpenGL implementations (e.g., Microsoft's) that haven't been updated to include headers/libraries to provide access to them directly. I prefer Glee by a small margin because it initializes itself automatically, but both work fine.
FreeGLUT: This has been updated more recently, and some of the bugs expunged. It still hasn't done much to improve the basic design of GLUT though. Probably a better choice for short demos/samples, but still not (IMO) suitable for much serious use.
Ogre3D: This is much bigger than any of the preceding libraries. It's a full-blown scene graph library, with texture loading, defined file format, etc. A solid library, but be aware that if you use it, you won't normally use OpenGL directly at all (e.g., on Windows, it can render via either OpenGL or Direct3D without changing the source code at all).
OpengSceneGraph: More often used for scientifically-oriented applications, but most closely comparable to Ogre3D.
FLTK: a small, lightweight GUI library that runs on top of OpenGL.
GLFW: In the same general spirit as GLUT, but it's been updated much more recently, doesn't have nearly as many bugs, and is (IMO) a nicer design -- minimal but still suitable for "real" use.
You should be using OpenGL if you want to write portable 3D applications. Windows, Linux and Mac OS X supports it.
You might want to take a look at NeHe tutorials. It's one of the best OpenGL tutorials available on the web.
My understanding is that if you want simple support for a recent version of OpenGL you'll have to leave Windows-land, so try take it in stride when getting started is ... complicated.
I think OpenGL is probably the right choice. You might also want to consider DirectX (which is better supported on Windows), but I'm personally not a big fan of it. You could also learn C# and use XNA, but if you want to learn C++ it just defeats the purpose. (I also can't help mentioning there's a good chance you could make it fast enough without C++)
I have to agree with the others that NeHe's tutorials are pretty much classic. You might also want to consider the OpenGL Red Book, but that costs money.
Regarding the 3rd paragraph, GLUT is old (and for that matter so is GLU), but if you see a good tutorial that uses them, I don't see anything wrong with them. Once you have your feet wet you might want to consider ditching GLUT and using SDL which I believe is a lot more 'alive'.
As far as GLEW goes, I've used it with success and it's nice if you want to do something fancy like shaders on Windows. However, I would say don't worry about it at first, because it will increase your setup time and keep you from getting to the fun stuff :)
I am going to start a game in about 3 weeks and I would really like the game to run at least on another platform (linux, MacOS) but my team thinks that's a lot of work. I am up for it but wanted to know what are the things I should watch out for that won't port to linux (apart from Windows specific APIs like DirectXsound)?
I've been reading online and Windows "_s" functions like sprintf_s appear to exist only on Windows; is this correct or are they implemented on linux also?
No, the _s functions are NOT implemented in the standard gcc library.
(At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
A sample of specific things to look for:
Input/Output (DirectX / SDL / OpenGL)
Win32/windows.h functionality (CreateThread, etc)
Using windows controls on the UI
Synchronization primitives (critical sections, events)
Filepaths (directory separators, root names)
Wide char implementations (16 bit on windows, 32bit on linux)
No MFC support on linux (CString, etc)
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
I also would make it playable on one OS before even thinking of porting.
For the 'safe' functions: they are non-standard, and almost safe :)
Endianess is something look out for.
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
So really it is up to you.
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
Whether or not to target multiple platforms from the start is a good idea is another question.
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
http://unity3d.com/
http://www.garagegames.com/
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.