<\/td><\/tr><\/table><\/p>\nThat’s Good Robot, running on Linux. It’s not running under wine<\/a>. This is a native build. <\/p>\n I can’t take credit. 95% of the work was done by Peter Olson. You might not recognize the name, but Peter and his brother Clint have done a lot for this site over the years and are basically outstanding people. <\/p>\n Peter loaded up the code on his Linux machine and went through the steps required to get it to compile. For a lot of the process, Peter was streaming his desktop for me to watch and then we hammered out the details in chat. <\/p>\n If you’re curious about what goes into porting software from one place to another, here is the list:<\/p>\n Actually wait. Before we get started, I need to do a disclaimer. Throughout this article I will equate programming on a Microsoft platform and using Microsoft tools. This is not necessarily the case, since you could use (say) the Code::blocks<\/a> development environment even if you’re developing on Windows. But since Microsoft Visual Studio is really good and Microsoft offers a free version, a lot of people naturally use it. I understand that “usually” is not the same as “always”, but to keep things simple I’m not going to make the distinction every time it comes up. If this really bugs you then:<\/p>\n Okay? Fine. Let’s get on with this.<\/p>\n Turning C or C++ code into a usable program is a two-step process. Step one is the compile stage. That’s were it parses all of your code, checks to make sure everything makes sense, makes sure your syntax is valid, and turns it all into “object code”. If you declare a variable a “Hitpoints” in one place but then refer to it as “hitpoint” later on, the compiler is the thing that will say, “I’ve never heard of this ‘hitpoint’ thing and I have no idea what it is.” This is also the stage where it pulls in headers for external libraries. If I’m using OpenGL, I don’t actually have the source code to OpenGL in my project. Instead I The second step is linking. The linker takes all the object files made by the compiler, adds in all the external libraries (like OpenGL) and then ties them all together. If I miss anything (like if I said I was going to have a function called SpaceMarineDie () but never got around to writing it, or if I included a header saying I’d use OpenGL but didn’t add the OpenGL library to the linker) then the linker will tell me what’s missing. If it has what it needs, it makes an executable file for us. <\/p>\n This is a complex process. It’s actually the thing I hate most about this language. It can be fiddly, tedious, obtuse, and unpredictable. But as bad as it is, it started out a lot worse. <\/p>\n It used to be that you compiled things from the command line. I don’t know how to compile anything from the command line for the same reason I don’t know how to sift wheat or shoe a horse, but I understand that it was done in the past and is still sometimes done by rugged independent types who would rather memorize hundreds of compiler options<\/a> than resort to something as decadent and ostentatious as a menu, or use something as humiliating as a mouse pointer<\/em> to select options. The point is, we don’t usually compile things by hand, even when using a terminal window. There are countless little options to control what files the compiler will read, where it will look for them, how it will interpret their contents, how it should report errors, and (if you’re successful) what kind of code it spits out. <\/p>\n Entering all these options every time you wanted to compile would be insane. So you stuff all of those options into a makefile. The makefile will guide the compiler and linker to do their thing so you don’t have to. Then you can give your project to someone else, provide them with the makefile, and they’ll be able to compile it even if they don’t know how it’s all organized. They should be able to compile your project even if they’re on a different platform. <\/p>\n This is all fine, EXCEPT…<\/p>\n If you’re using Microsoft tools, you don’t have a makefile. Microsoft uses project files. It’s the same idea except it’s, you know, different<\/em>. So step one of porting from Windows to Linux is creating a makefile. This means that everyone can share their code, but it’s a bit harder to share between Windows and non-Windows. <\/p>\n Remember the headers I mentioned earlier? Well, there are a lot of them available. Hundreds of them. Maybe even thousands. I dunno. Now, some of these are standard headers. If you’re using a standards-compliant version of C or C++, then you should have a But! Different platforms have their own ideas about where to put all those files. <\/p>\n On Linux, the io header is under the sys\/ directory but utime isn’t:<\/p>\n On windows, it’s reversed:<\/p>\n Why? Why is this different? Why is this not standardized? Who saw the files arranged one way and decided they just HAD to reverse them? I have no idea. Is this a case of Microsoft just doing as they please and expecting the standards to conform to their behavior? (As they did with Internet Explorer 6.) Or is this a case of anarchic Linux environments leading to fragmented systems? Or do we blame the ISO<\/a> for failing to herd these cats? Beats me. The politics of the language are opaque to me. All I know is that we’re beset by stupid trivial crap that ought to work but doesn’t. <\/p>\n Some things aren’t part of the strict C++ specification, but end up as part of the language anyway. Sort of. Informally. If you want to open a file you use open () to open a file and unlink () to delete it, unless you’re on Windows where you use _open () and _unlink (). Again, we can argue about who to blame but the fact remains that you have to deal with this when porting. A bunch of little stuff might have slightly different names or subtly different ways of being used. <\/p>\n Now, in this particular example we don’t have to use open () and unlink (). There are newer systems with better portability you could use instead. If you’re writing new code, you could use an ifstream or ofstream for file access. But there’s a ton of legacy code out there still using the old way, and “rewrite all your file access code from scratch” isn’t a super-attractive option. <\/p>\n In any event, you’re likely going to have several dozen little points in the code where you’ll need to deal with name conflicts. <\/p>\n We’ve got this little thing called max () that returns the larger of two numbers. There’s a version of it for comparing two floating-point values (like 4.43587 or 0.3429085) and another version of it for comparing integers.<\/p>\n Note how in line 3 I didn’t explicitly say that the number 2 was a float. One compiler will see that my code looks like: But what really sucks is moving from a relatively permissive compiler to a stricter one. The compiler will hound you for hours over tiny little bits of inconsequential code like this and make you do many little edits to “fix” code that worked just fine for the other compiler. <\/p>\n On windows, these are equivalent:<\/p>\n On Linux, they are NOT the same. The sad thing is, I’ve known about this distinction for years, but I can never remember which way is the portable way and I’m not inclined to Google it when I’m in the middle of working on something else. So I guess, and apparently I’ve been guessing wrong more often than I was guessing right. This was fine until we tried to port, at which point it caused all these goofy problems. <\/p>\n And after all that work, the game is still broken in many stupid little ways, even on other versions of Windows. One tester is reporting performance WAY lower than what I would expect of a machine with their specs. One person using Windows XP reports that all of the robots get more transparent depending on how bright their colors are, which means there’s some shenanigans going on with the alpha channel, but ONLY on Windows XP. One Linux machine renders fine. Another one has textures and sprites flickering in and out all over the place. Another user reports that music never plays. Another one has the music play, but only if they open and close the main menu.<\/p>\n Sigh.<\/p>\n A lot of these problems can be traced back to the use of my vertex shader. As annoying as it is getting C++ code working on more than one machine, vertex and pixel shaders are far, far worse. NVIDIA and ATI always find a way to interpret the spec differently, and those differences aren’t even consistent across different driver versions. I’m seriously considering pulling out the vertex shader for now. It’s the source of about 80% of all of my technical glitches, with multi-threading making up the other 20%. <\/p>\n So that’s the adventure porting the game to Linux. It “only” took a few hours, which is either amazing or horrible, depending on your expectations. <\/p>\n","protected":false},"excerpt":{"rendered":" Early in the project I said (hopefully here on the blog) that one of my goals for the project was to leave the door open for porting to linux. I might release a linux version or I might not, but I wanted the option and that meant I needed to keep the codebase free of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[498],"tags":[],"class_list":["post-21352","post","type-post","status-publish","format-standard","hentry","category-good-robot"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/21352","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=21352"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/21352\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21352"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21352"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21352"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\r\n#ifdef _PEDANTIC\r\n#define USING_WINDOWS USING_WINDOWS_AND_ALSO_USING_VISUAL_STUDIO\r\n#endif\r\n<\/pre>\n
Makefiles<\/h3>\n
#include \"gl.h\"<\/code>, which is just a text file that tells the compiler, “Yeah, all this OpenGL stuff exists elsewhere and here is what it will look like.”<\/p>\nHeaders<\/h3>\n
stdio<\/code> header. (Standard Input\/Output.) If I #include <stdio.h><\/code> in my code, you should be able to compile that code on your completely different machine with no changes. <\/p>\n\r\n#include
\r\n#include
Differently-named functions<\/h3>\n
Compiler differences<\/h3>\n
\r\nint a = max (10, 52); \/\/a all be set to 52\r\nfloat b = max (10.1f, 0.52f); \/\/b will be set to 10.1\r\nfloat c = max (2, 0.001f); \/\/c will be set to 2\r\n<\/pre>\n
float = max (ambiguous, float);<\/code> and conclude that the ambiguous value is a float. Another compiler will throw a tantrum and refuse to proceed until the ambiguity is removed. You can argue this either way. The former is more permissive, while the latter is more strict. More strictness can save you from making mistakes but can also make code more cluttered, verbose, and hard to read. It depends on what you’re doing. The coding conventions<\/a> of your project might make these little differences incredibly important or a non-issue. <\/p>\nFilesystem differences<\/h3>\n
\r\nopen (\"mygame\\\\games\\\\saves\\\\savefile1.sav\");\r\n\r\nopen (\"mygame\/games\/saves\/savefile1.sav\");\r\n<\/pre>\n
Wrapping up…<\/h3>\n