THINKGEEK · FRESHMEAT · THEMES.ORG · SLASHDOT My OSDN · PARTNERS · AFFILIATES [Image] [OSDN: Open Source Development Network] Feedback / Printable Sun, Oct 1 Powered by Search GNU & Debian Linux.com: [Linux.com] Main . Chat . Desktops . Development . FirstStep . Games . Download . Hardware . Jobs . Links . LinuxGram . Linux.com Live! . Linux User Groups . Multimedia . News . Support . Sysadmin . Tuneup . O'Reilly Games News Games [Our Sponsors:] [LinuxWorld Expo] Build your From MFC to GTK: A Developer's Journey own Gaming by Ryan Gordon - Sun, 24 Sep 2000 [Image] Rig 09:37:27pm Mon, 18 September Most game ports don't come with the Related Links 2000 extras. While Descent 3 runs on MacOS, Linux.com - Linux, and Windows, the map editor, Loki Hardware has D3Edit, only builds on Win32. Any number Port posted an of other titles suffer from the same Games article on problem; level editors, character viewers, Drivers building a sound converters, and other bits of added Gaming better value don't make it into the ported Nvidia gaming products. Shogo machine. Development There is a simple reason for this: the X Shogo video game industry is very volatile. A GNU Progress company could spend millions of dollars Report over 18 months to produce a game, just to Sun, 10 have it fail in the market. This is also User Account September why successful ideas duplicate; today, username: 2000 most cool games are either based on, or Hyperion look like, Quake. Furthermore, since the password: Software originals were so popular, we can enjoy have updated seven sequels to King's Quest and eight with a repeats of Ultima. To really understand Create Login progress the volatility of the market, just look at report on the creators of those two games; Sierra Maintenance their Shogo and Origin, once giants in the field, are linux port. now mere ghosts of themselves. It's a vicious trade. With financial volatility [User Friendly, the comic strip] Kohan for as the only constant in this business, Linux game companies just can't justify the Community Fri, 8 added expense of porting games to "niche Ad: September markets" like BeOS or Linux. Those that 2000 make the effort (like id and Epic), never [Jabber - open IM] Loki has put out the money to port the extras. It sent out a simply costs too much for something that's new press nice to have, but not crucial to the release gaming experience. today. A new game is in Some of you may be thinking that porting a the works map editor must be simple, and therefore with Loki. cheap, compared to porting a whole game. The game is Not so. Heroes of Might and Magic 3 is called approximately 250,000 lines of C++ code. Kohan. Click Its map editor is only 75,000 lines. The the title game took LESS time that the editor to above to reach final release. The same is true for read the "Fear" and "Loathing", the game editors full that we shipped with Myth 2. release. Why is that? First and foremost, we can NVIDIA blame the Microsoft Foundation Classes. Drivers This API is a brick wall of 0.9-5 incompatibility. Secondly, we can blame Tue, 5 Visual C++'s extensions to the language. September 2000 I can't put all the blame on Microsoft, NVIDIA has however. GCC doesn't always function as just expected. The Standard Template Library released the (STL) and the C++ runtime tend to lag newest behind. And while this isn't necessarily a version of fault, Linux and Windows have very their different paradigms of use and development drivers. that need to be addressed by the programmer, not just in operation, but More News also in developmental habits. The MFC Resources Linux.com The Microsoft Foundation Classes are going Newsletter to be 90% of your porting headache. Games Sign up for generally don't use the MFC, so usually the Linux.com most the bulk of that porting work is newsletter focused on generating Linux-based graphics @O'Reilly! and sound drivers to integrate into the codebase. This is why the editors take Use our news! longer: you have to deal with an Snarf the almost-certain code rewrite when you latest encounter MFC code. headlines from Linux.com for You might be able to eliminate this use on your headache almost completely with the aid of site. support libraries such as Twine or MainWin, but then you get new headaches to JOLT.LiNUX.COM replace the old one. MFC 4.2, an ancient Journal of version, is the last code revision Linux Microsoft legally permits you to compile Technology for non-Windows platforms. The source to newer revisions of MFC comes with the Visual Studio product from Microsoft. Your conscience and your lawyers can decide if you should try your luck with these. Legality aside, don't forget your end users; not only are win32 wrappers considered to be "cheating" by the Linux community, no one wants to run a native Linux application that looks like a native Windows application. After all, if we wanted to use Windows programs, we'd just run Windows in the first place and save all this hassle. Your users demand more from you. Do not cheat them out of it. GCC problems The GNU project has produced a very high quality C compiler. Unfortunately, their C++ offering just isn't as good. I have trouble maintaining my faith in software that often announces that it has become "confused by earlier errors." To be fair, if it is dealing with syntactically stable code, the compiler works very well, but we are rarely in control of the quality of code we are porting. If nothing else, GCC is going to offer you cryptic error messages when it encounters the inevitable uses of Microsoft extensions to the C++ language. Here are some tips, tools, and tactics to make your porting efforts less painful: Get the right tools for the job. Chances are, your favorite Linux distribution comes with EGCS 1.1. You are going to want to upgrade immediately to at least GCC 2.95.2. The distributed revision of the Standard Template Library is almost certainly out of date, too. At the time of this writing, the latest from SGI (http://www.sgi.com/Technology/STL/) is version 3.2. Be sure to grab this, and explicitly specify it with the "-I" option to GCC during compiles. If, during the course of your porting efforts, you find compiler or library behavior that seems incorrect, it might legitimately be a bug in the GNU software. Don't be afraid to get the bleeding-edge CVS snapshot of the compiler, since these frequently fix odd problems. Slackware 7 users, and possibly others, are going to want to upgrade their copies of GNU debugger to a version that understands multithreaded programs. As of this writing, gdb still gets confused by classes that make use of templates and multiple inheritance, so again, check the CVS snapshot if it gives you trouble. Next, you will want a text editor that can syntax-highlight C++ code. There are several high-quality editors for Linux that do syntax highlighting. I prefer FTE (http://fte.sourceforge.net/). The reason for this is to give a visual hint as to what is a comment and what is actual code. The rest of the syntax highlighting is less important in this case. While porting, never delete a line of code. Comment it out and make your changes below it. If you need to, comment out whole functions. You are going to find that having an immediate reference to the original code is immensely helpful, but all that text can get very confusing. Syntax highlighting makes everything much easier. Use CVS. Having a CVS repository for the project, even if it's just for one developer, is almost essential. The ability to quickly determine and back out changes to the code is an enormous help, especially if a porting tactic used in one subsystem ruins another. Commit your work regularly. Keep Visual C++ and MSDN handy. Your worst enemy is also your best resource. Either keep a Windows box within arm's reach, or install VMware. When the program you are porting misbehaves, nothing helps as much as being able to step through it under gdb and Visual Studio simultaneously. MSDN, the ultimate documentation for Win32 programming, takes up two CD-ROMs. If you don't have it, or can't install it, it's freely available on the web at http://msdn.microsoft.com/. Always look up unfamiliar classes and functions, as many have unexpected and non-obvious side-effects. Glib, GDK, and GTK+ references, which are also invaluable, even if they are a sometimes a little incomplete, can be found at http://www.gtk.org/. Keep the source to these libraries around to fill in gaps where the documentation is lacking. Use Glade. Glade (http://glade.pn.org/) is a user interface builder for GTK+ and Gnome. It stores interfaces in an XML document, which may then be generated at runtime with the libglade library. Changes to the user interface can even be done with a text editor, and don't require a recompile. The real benefit, however, is that, as with Visual C++, you can build your UI very quickly. While Glade itself can generate C and C++ code, you will do better to use libglade, and write a simple C to C++ glue layer for your signal callbacks. Remember that Glade and libglade are different projects with different authors, so be sure to send questions and bug reports to the correct recipients. And, like GCC, the Glade packages that came with your distribution are probably out of date, so be sure to upgrade. Make liberal use of assertions. GUI applications for any platform expect certain events to occur, and not occur, in an unspoken, but specific order. Otherwise, variables don't get set, chained events don't trigger, and the program mysteriously misbehaves or crashes. Go into each MFC-based class, find the event handlers (OnMouseMove, OnPaint, etc.), and fill in some obvious conditions. Look for the data that handler uses. For example, a class's OnSize method might want to allocate an off-screen buffer that matches the new size of the screen, for later use when painting. At the start of this method, it would be wise to assert that the window's new width and height are greater than zero. Be anal about this. Check the details that couldn't possibly go wrong, because it you don't, they will, undetected. Bitmaps are not the same in X. In Windows, there is the concept of the "bitmap", which is a block of memory that holds a graphic. The Win32 API provides drawing primitives, such as lines and rectangles, that can be applied to bitmaps, but you may also manipulate them on the byte level. In practice, this works well for a system that has no facilities for remote display. X and GDK separate their graphics into "drawables" and "images". Drawables are for high-level primitives, and images are for low-level byte manipulation. You may draw an image's contents to a drawable, or dump a drawable's contents to an image. With this ability to convert between formats, you might think this will be a convenient means to emulate win32 bitmaps. Wrong. Drawables are stored in the X server. Images are stored in the client. To swap between formats, the entirety of the data must be transferred. Depending on the size of your image, this can be a noticable delay, especially over remote and ssh connections. The solution is to choose one or the other; if you can use just drawables, then do so. If you need low-level byte manipulation, use only images, and rewrite the primitives. Functions like gdk_draw_rectangle() are actually very simple to rewrite for a GdkImage. Implement the tiny things, scrap the big things. There is a subconscious design to almost every program: the most frequently used routines are the simplest to reimplement. The goal is to sucessfully find the balance between what you can sucessfully fill in (CPoint, CRect), and what is best replaced in the source (CDC objects for GDK calls). The same is true for the C-callable win32 API; functions like SetTimer and GetClientRect are simple enough to rewrite in a matter of minutes with GTK+ equivalents, and tend to be used all over the place. The balance is important, though: if you want to reimplement all the pieces of the MFC that your program uses, then expect the effort to take weeks, not days, longer. This is only some basic advice to get you started. The only truth in porting MFC code to GTK+ is this: no matter how prepared you are, the design of the average MFC program is going to give you something you aren't expecting. Just remember to allow at least twice as much time for the project as you would initially expect to be reasonable. ------------------------------------------- Ryan C. Gordon is a coder from Loki Entertainment Software. He ported the Heroes of Might and Magic 3 editor from MFC to GTK+, was lead programmer on Loki's Descent 3 port, and is currently working on Sid Meier's Alpha Centauri for LinuxPPC and the upcoming port of Kohan. He can be found at icculus@lokigames.com [ return to games ] [ View past articles... ] About Linux.com - Link to Us! - Site Logos - Volunteer for Linux.com [Image] ©1999, 2000 Linux.com. Legal Find out about our hardworking staff statement