You're not paranoid if everyone really is out to get you. That's not really what happened here, and I know that on some intellectual level, but it doesn't feel that way. It feels like everyone is trying to screw me. You probably are too, and are just reading this to gloat. Well screw you too, buddy.
Anyhow, the point is that I had kind of a neat idea for an algorithm using the fancy-smancy new move operators in C++11, that, among other things, allow you to efficiently return STL containers. Not pointers to containers, not passing in references, just return the thing, no fuss, no muss, it just automatically generates a move operator, or constructor as the case may be, and off you go. Easy, right?
Except, well, you know, often times you want more than just STL containers, you want to get yourself some of that abstraction everyone keeps talking about, so you make one of them there object things, and the standards all say that that the compiler should automatically provide the move constructors. Great, right? Well, yes, it sounds awesome. Except, Visual Studio 2013 doesn't actually do this. Bummer, right?
But no big deal. Visual Studio is just another one of the tools the man uses to keep us down anyway, right? So I get mingw (one of the few c++ compilers that is easier to use than pronounce), and I'm rocking it. Except, well, I was going to use that neat algorithm from above to make a game, with some procedurally constructed geometry, and well, Direct X 11 won't compile at all, and direct X 9 will work, but the headers produce a gabillion warnings (though I swear at some point I found the switch to turn them off, but that is besides the point.) Apparently the problem is that mingw uses a c runtime which comes with the Windows system, called msvrct, but one which is from VS 6, and isn't supported on some of the new Microsoft stuff.
Yes, I realize I could now try to get another runtime to work with gcc. Also, some people have managed to drop in clang to the mingw tool chain as a replacement for gcc, and that has a switch that lets you use a different runtime. But these are all uncharted waters, and I am not particularly interested in sailing around in them. So I'm not going to do that.
What I am going to do, is to just switch from dx 9 (which does seem to work somewhat, but those compiler warnings are giving me the heebie jeebies, even though i think they are relatively innocuous.) to opengl. This is a move I was going to make earlier, except that I hear Intel graphics chips have pretty spotty support for it, and that a large number of people use those integrated graphics chips.
But, in the final analysis, I have decided I just don't care about this. This is an app that I would kind of like to sell to people without fancy video cards (it will hopefully have a good bit of casual appeal), but opengl eases the way to eventual ios and android support, which is another avenue. And, besides, maybe some people will buy the game anyway, and then forget to return it when it doesn't work. I mean, they clearly did that when they bought the computer with the intel graphics chip that says "OpenGL 3.0" on it, but doesn't actually work.
No comments:
Post a Comment