Direct3D 10/11 coming to Linux … What about games?

No, April 1st is still more than 6 months away, and yes you heard me right — Direct3D versions 10 and 11 are indeed coming to Linux. How is this even possible?  Well it is possible, since nouveau moved on to Gallium 3D which allows Direct3D API (actually any API) to be exposed via a front end called a state tracker. Interestingly (, and there seems to be a lot of confusion going about on public forums) Direct3D will be a Native API under Gallium, much like OpenGL is currently. It won’t be a something that emulates Direct3D by using wrappers around OpenGL — meaning you will be able to write and compile Direct3D code directly on Linux or BSD based systems that support the nouveau driver. Initially I was a bit skeptical of such an approach since Direct3D API is integrated with Win32 API, but the author seems to have solved this by using Wine headers. I don’t know the pitfalls (if any) of such an approach, but it seems to have worked for him and would seem a logical path to take (instead of breaking API compatibility). He clearly outlines the motivation behind doing the Direct3D port, and kudos to him for doing something that was but inevitable given a no show of Longs Peak.

Naturally a native Direct3D implementation will allow game developers to write code that is cross-platform and even allow existing engines/games that use Direct3D versions 10 and higher to be ported across to platforms that have a Gallium driver. W00t! This is amazing, almost too good to be true isn’t it? But before we gamers jump in joy, there are still a few things that have to fall in place before things can get up and running with regards to Direct3D on Linux. First and foremost is support. Hardware vendors like Nvidia and AMD must support Gallium in their drivers, or OSS drivers must be written (and are being written) to take their place. This is paramount since without such an interface, no front end API (Direct3D or OpenGL) will be able to use hardware acceleration via Gallium. Second, and more importantly, the guys at Redmond must allow such an implementation of their Direct3D API. An API itself can’t be copyrighted. The author seems to have steered clear of any Microsoft code, so theoretically this shouldn’t be a problem. But then again I am no legal eagle, so I can’t really say anything w.r.t. this. There have been rumors that there are patents on sections of Direct3D. I am not sure what that means, or for that matter if it is even possible to patent sections of an API/Library. But, things could get potentially messy if Microsoft were to place a cease and desist on this new development. I doubt this would happen, but you never know.

I have to agree, having Direct3D as a native API via Gallium does open up a lot of possibilities for OSS platforms that have severely lacked games. Accelerated graphics on most systems apart from Windows have had little choice up until now with OpenGL being the only real option. But does this really mean that all of the games that are developed and are being developed will be ported to Linux and other OSS platforms? That’s an interesting question and the answer isn’t quite that simple. Lets look at the macro picture of the industry. For AAA games the PC platform isn’t a priority. Most (maybe all) AAA games are today made with consoles in mind. Yes there maybe a PC port, but it’s the consoles that are the main priority. Most (if not all) gamers that play AAA games on the PC do spend a bang on their systems and most of them already have Windows as their main OS. Some do have *NIX systems but even these few have a Windows partition that they keep around specifically for games. Porting any software to a new platform isn’t a trivial task. Even with the best coding practices and methods, it requires a lot of resources — which aren’t free. Everything from coding, testing, maintaining build setups, writing install scripts and many other things requires time and money. For  a AAA game, or for that matter for any game or software, a port to a new platform should show a robust ROI (return on investment). That’s where the crux of the problem lies. There aren’t that many *NIX gamers out there, and if there are, the big studios aren’t seeing them!

Then there are the casual games, which also is a big market for games. Casual games represent a very different kind of audience. A typical casual gamer is a non technical person who doesn’t even understand what a hardware driver is, let alone jargons like Gallium, Direct3D, OpenGL or for that matter Linux. Most casual gamers will have nothing but a moderately powerful laptop with on-board Intel graphics chips — which came with Windows pre-installed. This is the kind of player that expects the game to install and run with a single click. They don’t understand driver updates or DirectX versions. For them it matters little which API is better or worse or which platform supports which API and which doesn’t. Apart form these two broad segments, there are a whole lot of players who will play radical indie games and this is probably where Linux ports has found some success. This gamer is the tech savvy computer geek who runs Linux as his/her primary system and isn’t afraid to fire up the console now and then. I must say, some radical indie games have found success in this area. But, these games are far from cutting edge. They maybe very good games, but you don’t expect Crysis like graphics from them, and it matters little what API is used or if the underlying API runs 5% slower when your game is not going below the 30FPS barrier.

There have been lots of debates about OpenGL vs Direct3D. I refrain to go into that. However, having a choice of accelerated graphics API for platforms other than Windows is definitely good all around. Direct3D versions 10 and 11 are well designed APIs, closely tied to current generation hardware. But will all this translate into more ports of games to Linux and BSDs is still an open question. The community as always will play a vital role and only time will tell how things pan out.

Designing user-friendly GUI.

What is good GUI? Or should I ask what make a GUI good or bad? Is it the snazzy looks, the cool effects, transparent windows, bright colors or is it really something else? Why do people hate some GUIs and love others? Or is it only just a matter of personal taste? Somethings to really think about I would say. GUI is actually a very broad term and can mean different things for different people. For a web-site a GUI could mean the web-page. For an application it could mean the application interface. For a everyday normal computer user it could very well mean his windowing system. A GUI is a graphical interface to a system, and the system can be, well, anything really. Though this entry is more about application GUIs, most points discussed here are also directly or indirectly valid for other GUIs.

Most novice developers working on GUIs never really understand, or for that matter appreciate the meaning of the phrase “good GUI”. It is often confused with “good-looking GUI”. That however, is not the case. Yes, it is true, good GUI must look good. You or the users of your application wouldn’t want to use bad-looking GUI. However, the single most important thing any GUI must accomplish is user-friendliness. How many times have you seen a good application get a bad reputation just because it was difficult to use? I would say too many times. Sometimes a GUI can make or break your application, but often times a bad GUI can give a bad reputation to applications that would otherwise have had much wider appeal. During my initial years as a developer I worked a lot with GUI libraries, everything from MFC, Qt, FLTK, wxWidgets and learned most of the GUI design principles the hard way, mostly by trial and error.

If you were to Google around for GUI design principles you will no doubt get a bunch of sites that give you some very good subject matter on the topic. However, GUI design is more about experience. Just saying, “You must know your user”, or , “Empower the user”, or , “Know the user’s perspective” doesn’t really cut it. True, most of the data is accurate and you are more than welcome to read it. However, these are very broad phrases and often lead to nothing conclusive. As any good engineer knows, data and facts are what matter. So lets looks at some of the hits and misses in GUI design.

a) Overly bugging a user. This is probably the worst mistake that can be done by any GUI. Remember those annoying pop-up dialogs in Vista! “Do you want to really move a file”, “Do you want to install this program”, and more. Nope, please don’t do that! It will make any UI interface extremely unpopular. The main culprits are Modal dialogs. Modal dialogs are one of the most overused GUI feature. I would go so far as to say, avoid Modal dialogs except for rarest of rare cases. Only use them to warn a user about data loss. Nowhere else! Even in situations where they are used, allow the user some way to turn off the warning message boxes.

b) Use tool-tips and modeless pop-ups, and use tool-tips judiciously. I can’t understand why so many UIs use modal dialogs to present information. Tool-tips are a great way to show information and they can be extremely useful in enhancing the GUI. Use tooltips instead of modal dialogs to convey simple bits of infromation. In one application I replaced information modal dialogs with tooltips that would fade away in about 10 secs or so. They were an instant hit. Azureus comes to mind, the program uses a similar feature to warn users. Also if possible try to replace modal dialogs with modeless ones. Again modal dialogs are not all that great even for user inputs. Compare the search (Ctrl+F) in Internet Explorer 6 and search in Firefox. Which do you think is more intuitive?

c) Another annoyance is leaving the GUI unresponsive. If there is a lengthy task, please delegate it to a worker thread. See to it there is always a way for the user to cancel a lengthy and intensive task. Never ever leave the user in a state where he/she can’t interact with the UI. It’s really annoying

d) Short-cut keys are such a help. I tend to always use them. A GUI application must have short-cut keys for the most commonly used tasks and must be consistent with shortcut keys. For example; never use Ctrl-Z for pasting something, Ctrl-Z is always an “Undo” command under all Windows applications, at least correctly designed ones. So stick to it. Not all tasks need to have shortcut keys. Actually it’s not always prudent to have short cut keys for commands that involve data loss. Also try to keep shortcut keys spaced apart. OK another example here; there was a friend of mine who was working on an application where he assigned Ctrl-S as save and Ctrl-D as delete. A few months later he got a nasty mail from a client asking him to remove that Ctrl-D since the client use to accidentally hit the delete key during save. Also overly complex shortcut keys and key combos like “Ctrl+Alt+F10” are not well appreciated.

e) “Empowering” GUIs are very very popular. GUIs that allow the use of both hands can quickly become a hit. Consider the copy-paste command. Initially the combo used to be Ctrl-Insert and Shift-Insert. However for a right handed person that would mean lifting his hand from the mouse to operate the shortcut keys. So two new short-cuts were introduced Ctrl-C, Ctrl-V. Now the user can select content with a mouse and copy-paste with shortcuts using his left hand. For those who don’t know, Ctrl-Insert and Shift-Insert still work with the Windows Notepad and most other GUI editors under X. Left handed people can still take good advantage of that. Such design can really go a long way because they empower the user to work rapidly.

f) Good GUI applications strive for “Undo” and “Redo”. This is easier said than done. It requires a lot of thought and pre-planning in the design stage of an application to have a full functioning Undo-Redo functionality. However this is a “must” in today’s GUI design. Can’t escape it. Hint: If you want to use Undo\Redo in your application, apply the Command and Memento design patterns to your designs.

g) Tool-bars are friends. Tool-bars are also a must for all but the most trivial applications. True some applications are too small to have toolbars. But the rule of the thumb is if an application has menus, it should also have tool-bars.

h) Another thing I hate is, deeply nested menus. If an application has to have them, then it must have a separate tool-bar for those menus. Deeply nested menu-items can be difficult for the user to locate. I have seen this, maybe not too often, but sometimes applications do have some commonly used functionality deeply embedded in the menu hierarchy. Not too well appreciated I must say.

i) Applications that fail to set the tab order on dialogs can quickly become unpopular, especially with laptop and notebook users. Same is the case with accelerator keys for input widgets. I have seen really good and professional applications miss out on this point.

j) Good GUI designers try to conserve space, but never go overboard. A GUI should not cram widgets, however intelligent choices while selecting widgets can go a long way. For example; often times a combo-box/choice-box will require far less space than a list box and provide equivalent functionality.

k) Readability is another factor. Sometimes snazzy looking applications with all those “skinnable” interfaces can make a mess of it. I generally try to avoid skins, custom fonts or custom colors. It is best to use system default colors and fonts since such GUI scales across systems that may have different settings and hardware setups. It is also best to go for flow layouts or sizer based GUIs. This allows for full compatibility even across platforms and with different windowing systems.

These are probably only some of the things that can go wrong with GUI design. There maybe more, but maybe I got a little bit tired with typing, and maybe you have too (, after reading such a long post). I will just leave you with this link. I think some very good points are addressed there. Have a peek if you are interested.

The GUI of choice for cross-platfrom development – wxPython.

I just finished off a small project in wxPython and I must say I am pretty impressed with the library. A couple of weeks back I had to do a small assignment (, not relating to the game or the engine I am currently working on) which required a fairly amount of GUI. The specification of the project demanded that the software be able to run on Linux, Win32 and Solaris. Solaris support however, was later dropped due to time constraints. It was a pretty small project (, considering of course I am working on the engine and the game for well over 2 years now). About a sum total of 5 days of work in the end. I was a bit hesitant to take on the work initially but changed my mind once it was decided that Python and wxPython was OK.

I’ve been meaning to take wxPython for a ride for a while now and this seemed like the perfect opportunity. If you have read my Selecting a scripting language articles (1 & 2) you will know I have a secondary interest in working on Python. I am looking to integrate Python into the engine. This just gave me an opportunity to have a look at the wxPython code and bindings in detail. That actually is a totally different topic in itself and I will go in to further details in the third part of the series (whenever I get around to writing it, probably soon). Coming back to wxPython, it’s been about 2 years since I worked on wxPython and I liked it then and I like it now.

Today wxPython is probably the best python GUI according to me. I haven’t worked with PyQt but I had tried messing around with PyGTK. PyGTK to be fair is kinda OK, but is less supported than wxPython. Also the fact that wxPython is far more extensive in widget and framework support than PyGTK, makes the former a more attractive choice. PyQt was just out of the contention for me because of 2 things, a) It has a very shady license, I think it is not LGPL compatible. You can’t trust it enough to use it in commercial product without breaking some license somewhere, too controversial! AND b) Qt is just such a horrible framework! I know people are going to disagree with me on this one, but Qt’s moc compiler thing just makes me cringe. I have worked on a large project involving Qt and C++, and those moc_* files can be a nightmare at compile times. Besides Qt uses archaic and redundant C++ practices to maintain compiler compatibility. So I generally tend to “run away” from Qt and Qt projects.

Continue reading